Environment for sub-configures

RESOLVED INCOMPLETE

Status

RESOLVED INCOMPLETE
17 years ago
6 months ago

People

(Reporter: wtc, Unassigned)

Tracking

Trunk

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
Right now mozilla/configure.in sets up a clean environment for the 
sub-configures by restoring key variables (CC, CXX, CFLAGS, CXXFLAGS,
etc.) to their initial values (the values that were passed in in the
environment).  This has two problems.

1. Unless these variables are passed in in the environment, they
   are not automatically exported to the environment for the
   sub-configures.  So it may be necessary to 'export' these
   variables.

2. If we want to ensure that the toplevel and all sub-modules use
   the same compilers, we need to pass the final values (rather than
   the initial values) of CC and CXX to the sub-configures.  This
   is because if the initial values of CC and CXX are empty strings
   (that is, CC and CXX are not set in the environment), the toplevel
   and sub-module configures may use different algorithms to determine
   the compilers to use.

   For example, in mozilla/nsprpub/configure.in on the tip, I make CC
   and CXX default to the OS vendor's compilers if they are unset in the
   environment.  This choice is different from the choice made by the
   configure scripts that merely use the AC_PROG_CC and AC_PROG_CXX
   macros, which default to the GNU compilers (gcc and c++).

   This problem only affects us when we pass --cache-file=/dev/null
   to the toplevel configure.  (By default the sub-configures use
   the toplevel config.cache and thereby use the same compilers as
   the toplevel.)  This problem has a simple workaround -- one just
   needs to specify CC and CXX in the environment when invoking the
   toplevel configure.

Comment 1

17 years ago
I think CC & CXX *may* be the only variables that are safe to pass the final
values right now.  We do far too much tinkering with the other variables
(CFLAGS, ASFLAGS, etc) to pass those to sub-configures.  They contain far too
many mozilla specific features (like the -Wp,.deps stuff).  And if we can't pass
 the supporting variables properly, then passing in CC & CXX may have unexpected
results.  
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Target Milestone: mozilla1.0 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.2

Comment 2

16 years ago
Changing target milestone to 'Future' since these seem to have missed the 1.2
alpha.  If you are still considering a fix for 1.2 please re-target accordingly.
Target Milestone: mozilla1.2alpha → Future

Comment 3

16 years ago
Mass reassign to default build config owner
Assignee: cls → mozbugs-build
Priority: P3 → --
Mass reassign of Build/Config bugs to Leaf.
Assignee: mozbugs-build → leaf
Target Milestone: Future → ---

Updated

14 years ago
Assignee: leaf → cmp
Product: Browser → Seamonkey

Comment 5

13 years ago
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build

Comment 6

12 years ago
Mass re-assign of bugs that aren't on the build team radar, so bugs assigned to build@mozilla-org.bugs reflects reality.

If there is a bug you really think we need to be looking at, please *email* build@mozilla.org with a bug number and explanation.
Assignee: build → nobody

Comment 7

10 years ago
Forwarding over to Core::Build Config as this bug existed before SeaMonkey had a seperate Build Config (on our Hg).

If this is adopted on Core's end, we'll be sure to get a comperable patch to SeaMonkey's side.
Component: Build Config → Build Config
Product: SeaMonkey → Core
QA Contact: granrosebugs → build-config
I'm going to call this one incomplete and say it is being addressed by moz.configure.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE

Updated

6 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.