bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.
The windows Mozilla build is being changed to track inter-module dependencies. To do this makefile.win needs a new variable REQUIRES = indicating which other modules are used. The features is enabled with: MOZ_TRACK_MODULE_DEPS=1 This has caused me to try and compile the mozilla/java directory. Right now this directory does not compile on Windows. There has been code rot from changes to strings, getservice, and various nested includes. I am adding the necessary REQUIRES= to all of the makefile files.
When building the plugin directory I was forced to rename my JDK/include directory so that the build would not find it. Leaving the JDK/include directory on the include path will cause compiler errors. Everything compiles ok with the directory renamed so this is probably an issue with the order directories are included. Also, the java directory will not build with OJI disabled. There is some conflict with the java include files again.
Comment on attachment 50574 [details] [diff] [review] makefile.win and code rot patch this is fine, but I'm confused as to why the other code (like the .GetUnicode() stuff) has bitrotted - are we sure that this stuff will ever be built? I'm wondering if this code should actually just be removed from the tree...
Attachment #50574 - Flags: superreview+
mozilla/java is not part of the tree One needs explicitly check out mozilla/java. Otherwise no mozilla/java files will be presented. I do not see relation between mozilla/java and "other code (like the .GetUnicode() stuff) has bitrotted" Can someone clarify that?
Bit rotting means that the HEAD of the java trunk is out of synch with the HEAD of the Mozilla trunk. The HEAD of the java trunk will not currently compile against the head of the Mozilla trunk due to API drift in Mozilla. The API drift is minor. A few issues with GetUnicode, do_GetService, a couple of NOP methods, etc. The bulk of this patch is form the REQUIRES= support in the makefile.win's. All necessary fixes are in the patch. If Mozilla is being build with dependency track enabled, all dependent modules including Blackwood have to also be built with dependency tracking. The patch enables dependency tracking for Blackwood.
is mozilla/java ever used? I mean, we use OJI to bring in sun's java library, which resides in mozilla/modules/oji to the best of my knowledge, nobody even uses mozilla/java...
Mozilla/java is definitely used. It contains the Java-XPCOM bridge and three other Java related deatures. It's just not part of the default build.
Also, the Sun development team doing this is only matching the Netscape commercial releases. They aren't tracking the Mozilla tree.
minusing for topembed.
Keywords: topembed → topembed-
Not sure what's left of this (patch) after bug 398573. http://mxr.mozilla.org/mozilla-central/find?text=&kind=text&string=%2Fmakefile.win
Depends on: 398573
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
Component: Java APIs to WebShell → Java APIs to WebShell
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.