Details
-
Type:
RFC
-
Status: Adopted
-
Resolution: Done
-
Component/s: DM
-
Labels:None
-
Location:this issue page
Description
Many users current set the environment variable SCONSFLAGS to automatically include certain command-line arguments when running SCons. This environment variable affects all SCons scripts, however, not just those written with our sconsUtils package, and most users who set SCONSFLAGS typically include sconsUtils-specific options. This causes problems when building packages that use SCons without sconsUtils (such as GalSim, or, at least until DM-3749, psfex).
Instead, sconsUtils read a new environment variable for sconsUtils-specific options; I'm proposing we call that SCONSUTILSFLAGS (though the lack of word separators is annoying, that seems most analogous with SCONSFLAGS). When this is available, users should use this new environment variable for sconsUtils-specific options like "opt=3", while continuing to use SCONSFLAGS for generic options like "-j4".
Attachments
Issue Links
Activity
How about including namespace so our environment variables can be identified easily, e.g., LSST_SCONSFLAGS?
Paul Price
added a comment - How about including namespace so our environment variables can be identified easily, e.g., LSST_SCONSFLAGS ? I think we have to do this, but I fear it will be confusing having to divide our settings between this new env variable and SCONSFLAGS. Please document this carefully so users know what settings belong where.
What will sconsUtils do with scons-specific options in this env variable? Warn or error? Ignore them? Pass them along to scons? I think a warning or error would be best. Passing them along to scons would work, but could lead to problems for non-sconsUtils-based builds.
As to names: I agree with Paul Price's that it is useful to prefix the name with "LSST_", but I also think it crucial to have "SCONSUTILS" in the name because these options drive sconsUtils, not scons itself. LSST_SCONSUTILS_FLAGS is rather long (with or without "_" before FLAGS) but is probably worth the verbosity.
My proposal for the behavior is quite simple: sconsUtils would concatenate the new variable with SCONSFLAGS and simply not care about where a particular argument came from. There'd be no warnings or errors if you put a generic SCons option in the sconsUtils-specific variable, and I think that's desirable.
I don't really have much of an opinion about the actual name of the new variable, so I'll leave it to others to chime in here on their preference.
+1 on the concatenation. Slight preference for LSST_SCONSUTILSFLAGS for the name.
Given it's relatively generic, if there's a chance for sconsUtils to have a future beyond LSST (e.g., like Jim's ndarray) it may be better not to hardcode LSST in the controlling variable name. If LSST_ is preferred, then +1 for Paul Price's proposal (LSST_SCONSFLAGS).
PS: That said, I don't feel at all strongly about the names. +1 for the overall proposal to separate sconsUtils from scons flags, w. simple concat.
Okay, the proposer has asked me to break the naming gordian knot as the implementer. I agree with Mario Juric that there seems to be no reason to bake LSST into the name, to avoid confusion in the situation where someone is using the system but not caring about LSST. I agree with Russell Owen that SCONSUTILS should be in the name for the reasons given. I agree with Jim Bosch on the concatenation if that does the job.
For largely arbitrary reasons (like confusing dyslexic and dyslexic-when-tired people by making them too similar) I pick SCONSUTILS_FLAGS.
+1
However, I think you meant "augment", rather "replace". SCONSFLAGS would still take -Q, -u, -j, ...; it's the extra flags (cc=clang --filter) that would go to SCONSUTILSFLAGS