462451 - Restore secondary SpiderMonkey build system

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jim Blandy :jimb]

The changes for bug 97954 deleted js/src/Makefile.ref and its supporting files.  We should restore these until the standard build system has matched all of Makefile.ref's features.  In particular:

- The shell should support command-line editing with the 'editline' library, and with readline.

- The shell should support the Intel C compiler, especially with PGO.  (We believe the standard build system supports this now, but we're verifying.)

Comment 1

[Jim Blandy :jimb]

Attachment: Bug 462451: Restore js/src/Makefile.ref and supporting files.

Here's a patch.  Will r? once the Try server has vetted.

Comment 2

[Jim Blandy :jimb]

Try server disliked this on Windows and Mac, but the errors look unrelated.  Will look into this further.

Comment 3

[Jim Blandy :jimb]

This patch is wrong: it's meaningless to #define HAVE_JS_CONFIG_H in mozilla-config.h and test it in jsapi.h, because mozilla-config.h isn't #included by everyone who might want to use jsapi.h.

It would probably make more sense for Makefile.ref to generate a js-config.h file, too.

Comment 4

[Brendan Eich [:brendan]]

Hi Jim, a couple of things to report from my switch-over to the new build system (which went really well, considering all the angles --, thanks for all your hard work):

1. I had to rm a stale js/src/jsautooplen.h by hand, as it was found in preference to the local one in my (sub-directory) objdir for the standalone build. But a make using my MOZ_OBJDIR=@TOPSRCDIR@/../obj-firefox configured js/src/Makefile then recreated js/src/jsautooplen.h, so this problem looks likely to repeat.

2. The .deps subdir was not autocreated for me. I had to mkdir it by hand, then the standalone build succeeded. I'm on Mac OS X 10.5, standard-issue gcc etc.

Real bugs here?

/be

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

After talking to brendan, it appeared that he had convinced the full browser build to do a srcdir build instead of an objdir build, causing problem 1.

I got the impression from jimb on IRC that problem 2 is known and needs to be looked into (though I'd be interested to know if it reproduces for brendan after resolving his srcdir build problems).

Comment 6

[Jim Blandy :jimb]

Thanks, Blake!  Re: Brendan's point 2, I've certainly done fresh Mac builds with this patch without problems, so I assume it's creating the .deps directory as it does on Linux.  Looking into it.

Comment 7

[Jim Blandy :jimb]

Hmm, the .deps problem is mysterious:

make in a js/src objdir
-> default  (js/src/config/rules.mk:616)
   -> make export
      -> export (js/src/config/rules.mk:707)
         -> $(MAKE_DIRS) (js/src/config/rules.mk:404)
            -> $(MDDEPDIR) (js/src/config/rules.mk:2048)

This makes me suspect the recent change for building parallel dirs, which did add an export:: target above the one on line 707.

Comment 8

[Jim Blandy :jimb]

bsmedmerg and jorendorff have explained the .deps problem: if the source directory has a .deps subdirectory (probably from a previous source directory build), but none of the other files that the configure script knows to check for to detect source builds, and then one does a separate tree configure and build, the .deps directory never gets built --- probably because make finds the source tree's .deps via VPATH.

$ cd $src/js/src
$ autoconf-2.13
$ ./configure
$ make
$ hg status -un0 . | xargs -0 rm    # note: not rm -r, so .deps remains
$ mkdir obj
$ cd obj
$ ../configure
$ make
...
../jsapi.cpp:6029: fatal error: opening dependency file .deps/jsapi.pp: No such file or directory

Comment 9

[Jim Blandy :jimb]

Attachment: Bug 462451: Don't be confused by .deps dirs in the source tree.

Comment 10

[Benjamin Smedberg]

Comment on attachment 346419 [details] [diff] [review]
Bug 462451: Don't be confused by .deps dirs in the source tree.

Interesting, I didn't know about CURDIR... it's not documented but does exist in make 3.80, and is documented in 3.81. I haven't tested with 3.79 but I don't really care about that version any more.

Comment 11

[Jim Blandy :jimb]

Attachment: Bug 462451: Don't find generated SpiderMonkey headers via VPATH.

On the same principle, it seems like this would be a good idea (and would fix Brendan's complaint #1 in comment #4.

Comment 12

[Jim Blandy :jimb]

(I actually found out about CURDIR by looking through 'make -qp' output for something that seemed plausible.)

Comment 13

[Brendan Eich [:brendan]]

(In reply to comment #12)
> (I actually found out about CURDIR by looking through 'make -qp' output for
> something that seemed plausible.)

Brilliant! I've done that myself.

The VPATH avoidance is good, I've been burned by wrong jsautooplen.h too.

/be