Closed Bug 101408 Opened 18 years ago Closed 10 years ago

Adds REQUIRES= for makefile.win's, fixes code rot

Categories

(Core Graveyard :: Java APIs to WebShell, defect)

x86
Other
defect
Not set

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: jonsmirl, Assigned: edburns)

References

Details

(Keywords: topembed-)

Attachments

(1 file)

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.
Depends on: 101379, 101410
Blocks: 100107
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.
Keywords: topembed
minusing for topembed.
Keywords: topembedtopembed-
No longer blocks: 100107
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.