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

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Jim Blandy :jimb]

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.

Comment 1

[Jim Blandy :jimb]

This would probably take the form of a --with-dist-dir option to js/src/configure.

Comment 2

[(not currently active) Ted Mielczarek]

I approve this message.

Comment 3

[Jim Blandy :jimb]

Attachment: Bug 467583: Make js/src share the 'dist' tree with the enclosing build

Work-in-progress, submitted to Try server.

Comment 4

[Jim Blandy :jimb]

Attachment: Bug 467583: Make js/src share the 'dist' tree with the enclosing build.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

I'll give this patch a whirl tonight to see if it fixes bug 467271 too.

Comment 6

[(not currently active) 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).

Comment 7

[Jim Blandy :jimb]

(In reply to comment #6)
> Should say (or an absolute path).

Good catch --- thanks!

Comment 8

[Jim Blandy :jimb]

Pushed to Mozilla Central:
http://hg.mozilla.org/mozilla-central/rev/ce93ff4c5f0c

Comment 9

[Jim Blandy :jimb]

This patch is responsible for the following warnings going away, but I don't know why:
http://office.smedbergs.us:8080/build?id=695

Comment 10

[Takanori MATSUURA]

Attachment: difference between config/system_wrappers and js/src/config/system_wrappers

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'

Comment 11

[(not currently active) Ted Mielczarek]

That's bug 471359.

Comment 12

[Takanori MATSUURA]

(In reply to comment #11)
Thanks.

Comment 13

[Jim Blandy :jimb]

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.

Comment 14

[(not currently active) Ted Mielczarek]

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+

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 353706 [details] [diff] [review]
Bug 467583: Make js/src share the 'dist' tree with the enclosing build.

a191=beltzner

Comment 16

[(not currently active) Ted Mielczarek]

Pushed to 1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1938c60f7335