Closed Bug 467583 Opened 11 years ago Closed 11 years ago

js/src should share dist directory with rest of Mozilla when built in-tree --- or should it?

Categories

(Firefox Build System :: General, defect)

x86
Linux
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jimb, Assigned: jimb)

References

Details

(Keywords: fixed1.9.1)

Attachments

(2 files, 1 obsolete file)

Since landing bug 97954, the js/src tree has built in its own dist directory, $obj/js/src/dist.  But I'm not aware of any clear benefit to having in-tree js/src builds use a separate 'dist' from stand-alone builds.  And one could argue that bug 467271 and bug 463339 are fallout from using separate dist dirs.

One impact would be that js/src builds would be somewhat less isolated from the behavior of other parts of the build system.  There's more of an opportunity for js/src to find files or overwrite files that shouldn't affect it.
This would probably take the form of a --with-dist-dir option to js/src/configure.
I approve this message.
Work-in-progress, submitted to Try server.
I'll give this patch a whirl tonight to see if it fixes bug 467271 too.
Attachment #353706 - Flags: review? → review?(ted.mielczarek)
Comment on attachment 353706 [details] [diff] [review]
Bug 467583: Make js/src share the 'dist' tree with the enclosing build.

+[  --with-dist-dir=DIR     Use DIR as 'dist' staging area.  DIR must be
+                          relative to the top of SpiderMonkey build tree.
+                          It may use '..', if necessary.],

Should say (or an absolute path).
Attachment #353706 - Flags: review?(ted.mielczarek) → review+
(In reply to comment #6)
> Should say (or an absolute path).

Good catch --- thanks!
Pushed to Mozilla Central:
http://hg.mozilla.org/mozilla-central/rev/ce93ff4c5f0c
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
This patch is responsible for the following warnings going away, but I don't know why:
http://office.smedbergs.us:8080/build?id=695
Assignee: nobody → jim
After ce93ff4c5f0c has been pushed, build is failed on my machine like the following.

dist/include/system_wrapper is now linked to js/src/config/system_wrappers and the contents are something different from config/system_wrappers.

I have tried to build sources both ce93ff4c5f0 and 2e386b2375e0 which is the previous changeset of ce93ff4c5f0. I can build successfully from 2e386b2375e0 and cannot build from ce93ff4c5f0.


gmake[8]: Entering directory `/home/foo/mozilla-central/toolkit/mozapps/update/src/updater'
(snip)
c++ -o archivereader.o -c -I../../../../../dist/include/system_wrappers -include ../../../../../config/gcc_hidden.h -DOSTYPE=\"Linux2.6.27.9-159.fc10\" -DOSARCH=Linux -DNS_NO_XPCOM  -I. -I. -I../../../../../dist/include/libmar -I../../../../../dist/include   -I../../../../../dist/include -I/home/foo/mozilla-central/dist/include/nspr     -I/home/foo/mozilla-central/dist/sdk/include    -fPIC   -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing -fshort-wchar -pthread -pipe -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/gtk-unix-print-2.0    -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions     -DMOZILLA_CLIENT -include ../../../../../mozilla-config.h -Wp,-MD,.deps/archivereader.pp archivereader.cpp
(snip)
c++ -o updater  -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing -fshort-wchar -pthread -pipe -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/gtk-unix-print-2.0    -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions    updater.o bspatch.o archivereader.o progressui_gtk.o readstrings.o    -lpthread -Wl,-rpath,/usr/lib64/xulrunner-1.9.2a1pre  -Wl,-rpath-link,/home/foo/mozilla-central/dist/bin -Wl,-rpath-link,/usr/lib  -L../../../../../dist/bin -L../../../../../dist/lib ../../../../../modules/libmar/src/libmar.a -lbz2  -lasound -ldl -lm  -lgtk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lfreetype -lfontconfig -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
archivereader.o: In function `ArchiveReader::ExtractItemToStream(MarItem_ const*, _IO_FILE*)':
/home/foo/mozilla-central/toolkit/mozapps/update/src/updater/archivereader.cpp:126: undefined reference to `BZ2_bzDecompressInit'
/home/foo/mozilla-central/toolkit/mozapps/update/src/updater/archivereader.cpp:148: undefined reference to `BZ2_bzDecompress'
/home/foo/mozilla-central/toolkit/mozapps/update/src/updater/archivereader.cpp:167: undefined reference to `BZ2_bzDecompressEnd'
/usr/bin/ld: updater: hidden symbol `BZ2_bzDecompress' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
gmake[8]: *** [updater] Error 1
gmake[8]: Leaving directory `/home/foo/mozilla-central/toolkit/mozapps/update/src/updater'
(In reply to comment #11)
Thanks.
The problem here is that js/src/config/Makefile's export step is regenerating the wrapped system headers, overwriting the work done by config/Makefile.in.  This would be okay, as config/system-headers and js/src/config/system-headers are checked to make sure they are the same --- except that system-headers includes stuff in #if conditionals, and the two are generated with different #definitions in scope (as determined by the two configure scripts).

It seems to me that js/src shouldn't be doing its 'config' stuff at all when it's being used as part of the Mozilla tree.
Depends on: 472881
Comment on attachment 353706 [details] [diff] [review]
Bug 467583: Make js/src share the 'dist' tree with the enclosing build.

This is needed to fix bug 467271, which is blocking1.9.1+
Attachment #353706 - Flags: approval1.9.1?
Attachment #353706 - Flags: approval1.9.1? → approval1.9.1+
Comment on attachment 353706 [details] [diff] [review]
Bug 467583: Make js/src share the 'dist' tree with the enclosing build.

a191=beltzner
No longer depends on: 472881
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.