Closed Bug 472050 Opened 15 years ago Closed 15 years ago

[Regression] Standard configure optdir way does not work anymore

Categories

(Firefox Build System :: General, defect)

1.9.1 Branch
x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 464053

People

(Reporter: BenB, Unassigned)

Details

(Keywords: regression)

I can't use the standard configure way of creating an optdir build anymore.
It used to be fairly trivial: Just create a directory anywhere, e.g. outside the source tree, "cd" there, and run the configure in the source dir from there. configure detects the current directory, and creates the build files in that directory, not the source dir.

Reproduction:
(This should work for *any* autoconf-based build)
1. Unpack or check out source in ./source/
2. cd source; autoconf2.13; e3em .mozconfig;
3. cd ..; mkdir opt/; cd opt/
4. ../source/configure
5. make

Actual result:
When in js/src/ (first Mozilla source being built, apart from NSS and NSPR):
"../source/build/autoconf/configure not found"

Expected result:
Build runs through to end.

Additional comments:
This is a regression, because it has always worked in the last 10 years, even if it was not documented like that.


Advantages:
You don't need to mess with config files, explicit paths from source to opt dir, commandline flags or anything - just cd somewhere and run the relevant configure from there, and it all works.

Another advantage is that I am more confident that the builddir is really active: A lot of times, I did something wrong. E.g. I used the wrong commandline flag or .mozconfig param name, or I just ran configure (assuming it would pick up my .mozconfig) instead of "make -f client.mk build". In all these cases, it simply creates a source build (because that's what it usually does when I'm in the source dir while executing these build commands). An attempted source dir build means that my source is now messed up, with makefiles etc.. I need to clean it up, sometimes in part manually, and I had cases where I accidently destroyed some source or even deleted parts my changes, i.e. lost work. These things *do* happen in practice. I never had these problems when I "cd"ed in the build dir before starting the build (unless the buildsystem had a bug), because all tools write in the current dir only, and the failure scenario
is not being able to do anything rather than writing in my source.

Importance:
This has always worked, since 10 years. It also still worked after the hg transition, IIRC, so it's not due to that.
Keywords: regression
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
VERIFIED.
If I "cd source/js/src/; autoconf-2.13;" before attempting the build, it works.

That's new, though: Before, even with hg, running autoconf in the main source dir was sufficient. Also, the error message is not pointing to the real problem (otherwise I could have solved it myself).
Status: RESOLVED → VERIFIED
It's technically a regression from bug 97954, which introduced a configure script for Spidermonkey in js/src. If you were using client.mk, it would take care of running autoconf for you in js/src. The bug I duped to is the other half of this, which is that we didn't commit the generated configure files to mozilla-central when we moved from CVS. That bug aims to revert that decision, which should make this no longer a problem.
luser, thanks for the explanation and bug reference.
Yes, having configure back in the source would be a good tradeoff IMHO.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.