[Scons-users] optional build components
Mats Wichmann
mats at wichmann.us
Fri Jan 4 11:55:59 EST 2019
every time I think I've got a handle on scons I find another way to
prove I really don't :(
anyway: here's the scenario. in a large project, a lot of components of
the code had local examples developed while the code was building up.
So now foo/bar/frobnicator has subdirectories named 'include', 'src',
'unitttest' and 'example'. The examples give you hints on using the
APIs of frobnicator, so there's some historical interest in keeping them
around. But as things have evolved, they often don't really work right
any more. In particular as the security situation has evolved, they
often are okay for the useful-for-some-debugging "unsecured" build, but
not for the default-for-doing-anything-real "secured" build.
project leadership is interested in making the unmaintained examples
less prominent, so there will be fewer cases of newcomers going down a
rathole with unmaintained code; but they don't want the stuff removed
entirely (yes, it could still be retrieved from git, but that's not
really an ideal solution).
So now I'm looking at ways to make certain targets optional, but still
accessible if someone really wants to pursue building one of those
pieces. Probably also moving those down a level so filesystem naming
reinforces the idea these are special cases, not supported.
We have a top-level boolean option BUILD_SAMPLE which controls building
all of the exsamples, but we don't want all of them demoted, just some
(and naturally, this option has not been used consistently in the
codebase, but that is not a problem for this question).
I see I can go into a particular SConscript and set up the default
targets for it by using Default(), and I'll probably experiment with
that, but that seems a bit painful: if the default isn't "everything
declared here", then you have to manually add Default() calls for each
one which is part of the default. In this case it would actually be more
convenient to do the inverse - mark a target as not-default. That, I
don't see any option for.
Also struggling with how to see what the default vs. optional targets
are at a high level, or even the defaults... the material in the SCons
User Guide on COMMAND_LINE_TARGETS, DEFAULT_TARGETS and BUILD_TARGETS
looks interesting but seems to not expose anything unless something has
already happened to set them up - that is, if there have been no
Default() calls, DEFAULT_TARGETS seems to be empty. This is not
intuitive to me - there are still defaults, no? At some point someone
added code to our build to store those targets which are the subject of
installation, such that our help message can dump out those targets,
essentially a custom internal-install method which includes the line
env.AppendUnique(TS=[name])
that seems kind of awkward but I guess it was done for a reason, since I
can't currently see a way to extract that info.
Any hints where I can learn more on how to work with this scenario?
More information about the Scons-users
mailing list