08:11
Unless the "reserved" areas in the structures are used to send extra information to the JVM itself. Otherwise how would it be known what the boot strap class path is?
08:26
No, so then how is the bootstrap classpath actually sent to the JVM? Is it built into the binary, are there any symbols which are linkable that give this information, is it magically passed into the JVM?
08:29
JAVA_HOME is not set at all.
08:45
JamVM to set the Java home directory just uses dladdr which is non-POSIX
specific to find the location of the Java home directory.
10:59
I installed an old version of OpenJDK 8 with JamVM so that I can use it in development of SquirrelJME so I do not have to wait 5-10 minutes for Zero to run when JamVM takes up to 3 minutes.
14:51
I believe I will unify directory handling, sort of. Or perhaps just make it
more checked. For each binary JAR there has to be "X-SquirrelJME-BinaryName"
for it to be considered a binary project. Otherwise it will be considered
source and the other property must not exist. If neither property is set then
it will be treated as an "imported" JAR (if it has a manifest that is).
Another thing I can do is split off ProjectInfo to have a binary form and
another with a source form, then extend a base class. This way there is no
two state sharing between binaries and sources.
14:59
Then I can also have a BinaryProjectManifest which provides higher level
access to the binary information. This manifest could be generated by source
projects (i.e. a generateBinaryProjectManifest()). The manifest would have a
representation of which kind of project it is (API, MIDlet, or LIBlet). Having
the source project generate one could simplify things. Also the
auto-interpreter could use it for determining which non-compiled source
projects would be if they were binary projects. This way, it would not be
required to compile every source project just to see if it is to be included
in the default API set. Currently this is more efficient than before because
before I would have had to compile the source project just to see the manifest
that would be used.
15:24
This means that ProjectList and ProjectGroup become deprecated. The
compile portions of ProjectGroup will be moved into SourceProject.
Generally one would just request binary projects and/or source projects.
15:47
Should I have virtual binary project representations for all source projects that may exist. It might not be needed at all.
15:49
So now that I am changing around the project manager, I believe I will remove
the internal and external dependency types. I would just treat all
dependencies as internal for the most part. When it comes to implementations
of APIs in other projects (such as for OpenGL ES) they would not be
depended on at all and not even optionally as it currently is. The target
builder and the auto-interpreter could determine which implementation of an
API to include. I may in the future need a wildcard selection, a kind of
inexpensive regex, where I can do for example mips-*,*+*.(bsd|macosx).*.