Closed Bug 462451 Opened 16 years ago Closed 16 years ago

Restore secondary SpiderMonkey build system

Categories

(Core :: JavaScript Engine, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jimb, Assigned: jimb)

Details

Attachments

(3 files)

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.)
Assignee: general → jim
Here's a patch.  Will r? once the Try server has vetted.
Try server disliked this on Windows and Mac, but the errors look unrelated.  Will look into this further.
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.
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
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).
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.
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.
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 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.
Attachment #346419 - Flags: review?(benjamin) → review+
On the same principle, it seems like this would be a good idea (and would fix Brendan's complaint #1 in comment #4.
Attachment #346551 - Flags: review?(benjamin)
(I actually found out about CURDIR by looking through 'make -qp' output for something that seemed plausible.)
(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
Attachment #346551 - Flags: review?(benjamin) → review+
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
Flags: in-litmus-
You need to log in before you can comment on or make changes to this bug.