70313 - build Blackwood in a separate objdir

Status: RESOLVED INVALID

(Firefox Build System :: General, defect)

Description

[Marcus Fellinger]

Currently, building mozilla/java only works if mozilla was built with
objdir=srcdir. Since I needed two different binary versions of mozilla, this was
not practical for me. So I created a set of patches which will create the
necessary Makefile's in the mozilla/java tree of the object-directory, and
update the Makefile.in's so that the source-code gets searched in the correct
directory. In order to build Blackwood that way, you specify --with-blackwood as
an option to ./configure. Using --with-blackwood disables
--with-java-supplement, as the directories built by the later are a subset of
the former ones. I've attached the patch to this bug report.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Marcus, did you forget to attach the patch?

Comment 2

[Marcus Fellinger]

Attachment: Patch for building Blackwood with srcdir!=objdir

Comment 3

[cls]

Since you're requiring additional bits of the mozilla/ tree, the option should
be --enable-blackwood .  Cc'ing edburns & leaf for additional input as I am
completely unfamiliar with the blackwood project nor who uses
--with-java-supplement.

Comment 4

[Marcus Fellinger]

Attachment: New version of the patch for configure.in which replaces --with-blackwood with --enable-blackwood

Comment 5

[edburns]

Marcus, does any other source code project in mozilla.org allow building the .o 
and .so files into another directory other than the one with the source files?  

This seems like a big change in behavior to me, but as long as --with-java-
supplement still works, I'm ok with it.

Comment 6

[edburns]

I'm going to ask Ashutosh Kulkarni to review this.  He's the nominal owner of 
building blackwood stuff.

Comment 7

[Marcus Fellinger]

Ed, the UNIX Build Configurator at http://webtools.mozilla.org/build/config.cgi
has an option to specify the object-directory. Also, if you check out mozilla
into say /usr/src/mozilla, cd to /usr/build/mozilla and enter
/usr/src/mozilla/configure, the .o, .so and Makefiles are created in
/usr/build/mozilla, while the source-code is read from /usr/src/mozilla.

This is handy if you want to build different versions from the same source (say
debug/non-debug).

Except for Blackwood all Makefile.in's used @srcdir@ as the directory where the
source files are located, and this variable is replaced by configure with the
actual path then the Makefile is generated.

So to me it's more a case of making Blackwood consistent with the rest of the
build process.

Comment 8

[Ashu Kulkarni]

Marcus,

- All changes to Java and C++ src files in /cvsroot/mozilla/java/xpcom need to 
be approved by the module owner for BlackConnect - Igor Kushnirskiy 
([e-mail])
- The changes to mozilla/java/webclient/src_moz/CBrowserContainer.cpp and 
NativeEventThread.cpp (nsIProfileInternal instead of nsIProfile) allows us to 
get away without linking xpfelocation.so. But this interface is not available 
in the Netscape 6.0 (RTM) branch that Webclient 1.0 currently works with. Pls 
post this patch to the Bug 68130 (filed by you as a matter of fact). Once 
Webclient 1.0 is release on all platforms, we will immediately check in this 
fix. thanks for this fix.
- Why have you made changes to Java src files in mozilla/java/plugins. Pls 
create a Bug identifying the reasons for the need for this and assign to Igor 
([e-mail]) who is the owner for Pluglets. Also post the fixes to this 
Bug.
- Could you pls post the modified files for your patch in tar.gz format to this 
Bug. I'd like to try them out on solaris and linux.

thnx

Comment 9

[edburns]

I feel this patch should not have any source files in it, only Makefile.in
files.  However, the following source files are present in the patch:


Index: java/plugins/examples/dom/DOMViewerFactory.java
Index: java/xpcom/xpcom/bcXPCOMStub.cpp
Index: java/webclient/src_moz/NativeEventThread.cpp
Index: java/webclient/src_moz/CBrowserContainer.cpp

It looks like your blackwood tree isn't current to our development tip,
which is on CVS tag JAVADEV_RTM_20001102.

Other than that, looks good to me, but I'm going to wait for Ashu to comment.

Comment 10

[cls]

marcus, in the configure.in patch, you should be using MOZ_ARG_ENABLE_BOOL
instead of AC_ARG_WITH.  With that change, you'll need to check for $enableval
instead of $withval.

Comment 11

[Marcus Fellinger]

Chris, thank you for the info. I already noticed the problem myself when I tried
to do a completed rebuilt. I've added a new version of the patch, which fixes
this problem, and contains no .cpp, .h or .java files.

Comment 12

[Marcus Fellinger]

Attachment: Updated patch with support for --enable-blackwood an no .cpp, .h or .java-files

Comment 13

[cls]

Attachment: objdir fixes for building java supplement

This patch doesn't attempt to build all of the blackwood project, just the dom
& webclient.  It still uses the --enable-java-supplement option.

Comment 14

[cls]

Btw, these are only the build changes.  The source code changes from bug 91552
are still needed.

Comment 15

[hacker formerly known as [e-mail]]

The --enable-java-supplement option has been removed from configure so I'm
WONTFIXing this.

Comment 16

[Jon Granrose]

verified wontfix.

Comment 17

[Marcus Fellinger]

This problem still exists with Blackwood's new Ant-based build-system, althoug
the patch will probably have to be redone.

Comment 18

[hacker formerly known as [e-mail]]

If it's not using the Mozilla build system, then this isn't a Mozilla (Browser)
bug.  This should be moved to a Blackwood product but since we don't have one....

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 24

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614