Override more compiler-related environment variables if Sage's GCC is used

[leif]

Currently only CC and CXX get modified (in spkg/bin/sage-env) if Sage's GCC spkg is installed (more precisely, if $SAGE_LOCAL/bin/{gcc,g++} are present).

We should also set / override CPP and (at least) also various commonly-used Fortran compiler variables to make sure the versions from Sage's GCC installation get used, since the user may have specified these, and the build might break (due to mixing different compiler versions). (As an example, building ECL currently fails if $CPP finds ffi.h although it is not really installed system-wide, but rather only in e.g. /usr/lib/<ARCH>/<$CPP's version>/include/; see ticket:13150:5 ff.)

---

Apply

• trac_13287-set_CPP_FC_etal_if_GCC_spkg_is_installed.patch​

to the Sage root repository.

[leif]

Not sure whether we have to (or should) handle OBJC, OBJCXX etc. as well.

Although compilers for further languages may get built and installed by the GCC spkg, these aren't used by Sage or its components, at least -- AFAIK -- not currently (with the exception of R using an Objective C compiler, but on MacOS X only).

[leif]

Dave, thoughts w.r.t. Fortran compiler variables (FC, F77, F95, what else?) and maybe ones for other languages (Java etc.)?

(IIRC, like me you're keen of getting rid of the odd sage_fortran script, and probably SAGE_FORTRAN, which is slightly related.)

[leif]

(Tentative inline patch to sage-env is currently here.)

[leif]

Patch to sage-env to also override CPP, FC, F77 and F95 settings when appropriate. Based on Sage 5.2.rc0. Apply to the Sage root repository.

[leif]

Initial patch now attached here.

[leif]

P.S.: Is this at all documented in the Sage Installation Guide? (I.e., that setting CC etc. later has no effect if Sage's GCC is installed, or likewise e.g. some wrapper scripts in $SAGE_LOCAL/bin/.)

[jdemeyer]

The patch looks good on first sight, but I haven't tested it properly.

[jdemeyer]

exporting CPP when it's not necessarily defined doesn't look like a good idea.

[leif]

Replying to jdemeyer:

exporting CPP when it's not necessarily defined doesn't look like a good idea.

Hmmm. If it's not already defined, exporting it has no effect. It may be (defined and) empty, but in that case it originates from the "global" environment, i.e., has been set to "" (and already exported) by the user, which is certainly wrong.

Any reason it doesn't get a default value if it's not already set in sage-env (like CC, but also AR, RANLIB etc.)?

I could either add the latter, or maybe only export CPP if we set it there (if [ -x ... ]).

The whole thing looks a bit inconsistent, but spkgs may rely on the other variables being defined, so I'd prefer to also let CPP always have a value.

[leif]

P.S.: I can't imagine a situation where some script sources sage-env, sets CPP, but does not want it to get exported.

[jdemeyer]

I don't fully agree with all of the patch, but at least it's an improvement.

[leif]

Replying to jdemeyer:

I don't fully agree with all of the patch, but at least it's an improvement.

Well, I'm open to further changes (although I don't mind merging it as is either)...