Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About David

  • Rank
  1. Found a really simple solution - use a ramdisk :-) I put a process monitor on the compiler as it was running, and it seems to be spending most of time on IO - I would have attached a picture of the procmon trace, but for some reason the forum isn't letting me upload any pictures. Basically the compiler appears to open, write to, and close sym.pdb, bod.pdb and rdf.pdb (plus others) over and over again. Each open and close results in an IO flush. On my conventional spinning-rust hard disk this results in a huge overhead just waiting for lots and lots of tiny synchronous IO operations to complete. So I created a small ramdisk, put the project files on there, and tried compiling... and instead of compilation taking hours or days, it now only takes minutes. Unbelievably quick compared to before -- compiling the whole project now takes around ~10 minutes.
  2. Hi -- thanks for the comment, but I'm confused as to how Jet would know to load a jar file that overrode class definitions provided in compiled code (even if it was dynamically linked). I can see how to set up a jar file classpath entry, but if I have the same class defined in two places (a jar file and a DLL) what would the Jet runtime do? I guess I could explicitly load the jar and the initial Hibernate configuration classes via a URL Classloader (if the jar was present), but would that cause all related classes to be also loaded from that jar? Or would the compiled classes take precedence (which is what I would expect from default Java classloader behaviour, to be honest)? I can't see anything in the documentation about this. Guess I need to do some experimenting...
  3. We are using the Hibernate ORM library in our project (plus the various libraries that Hibernate requires of course). Hibernate is published under the LGPL2.1. Now, the LGPL allows us to link to the Hibernate libraries, BUT it also requires that the end-user be able to REPLACE the library (maintaining interface compatibility) should they so wish. What this means is that if a user had a copy of our aplication, and wanted to run it using a patched version of Hibernate that he had built, he must be able to do so. (There is some discussion around this on this thread: https://opensource.stackexchange.com/questions/4624/dynamic-linking-lgpl-library-and-licensing-in-windows-store-app/4625#4625) Up to now, I had been assuming we would build our application + libraries into a single EXE. But that means replacing a library would be impossible (all the libraries are "baked in" to the EXE). So we need a mechanism for allowing replacement of classes once an application has been built. There are 2 ways we could comply with the LGPL here - 1) Provide our application as an "object file" - ie., the compiled output from Jet. We separate our project into "our application", and "libraries", and compile them separately as a multi-component application. The problem here is that the end-user would be unable to re-link, since they would need their own copy of Excelsior Jet to compile their patched version of Hibernate. OK, so the user can technically get a free-for-personal use version of Jet now, but I don't think that complies. The key bit of the license text is this: "... must include any data AND UTILITY PROGRAMS needed for reproducing the executable" (emphasis mine). To properly comply with the LGPL we would have to be able to redistribute Excelsior compiler and linker binaries ourselves (on demand from a user). So that's not really an option. Unless Excelsior want to be totally awesome and release a stripped-down command-line-only set of tools that can be re-distributed for this purpose. That would be immensely cool. or: 2) Load the Hibernate libraries dynamically at run-time from a plain JAR file, using the mixed compilation model. Performance would obviously not be as good, but I assume that would work OK. We may possibly be able to provide 2 builds - a normal build where the libraries are statically linked into a single exe, and an alternate build where we put library JAR files in a subdirectory under the main application and load then dynamically at application startup, allowing users to simply "drop in" a replacement library jar file should they so wish. Are there any other options I could consider? An "ideal" solution for building applications using LGPL libraries would actually be something like a very minimal compiler tool for Jet that could compile a Jar file and produce a standalone "object module" that could be loaded by a Jet-compiled application at run-time. The tool would need to be freely redistributable, but would only need to do the basic job of converting a jar file into a compiled module. The main application (built by the full Jet application) would load and dynamically link to those modules at startup (e.g., like a DLL).
  4. Looking for any suggestions on how to speed up project compilation, or how to compile jars individually and then link. The project isn't that big - around 30 library jars, then my main application jar. Total of around 14,500 classes. But this took over 2 hours to compile using the 64-bit compiler (on a reasonably modern Core i7 machine, with 8 GB of RAM). The 32-bit compiler didn't even manage it - it was still chugging along ~12 hours later when I left it overnight. I don't NEED a 64-bit final executable - my application would be fine as a 32-bit app. But it looks like that's a non-starter at the moment. So -- 1) Are multiple-hour compile times normal and expected for a project of this size? 2) Is there any way of splitting compilation up into smaller units? E.g., can I compile the library jars separately into object files that are kept on disk, then just compile my application sources and link when I change my main application? 3) Are there any compiler options that I should be looking at to try and speed things up? Thanks.