Re: optional build components

Gary Granger <[email protected]> Fri, 4 Jan 2019 11:16:03 -0700
Newsgroups	gmane.comp.programming.tools.scons.user
Message-ID	<[email protected]>
Hi Mats,

You may not have to specify each and every executable as a Default(),
since Default() can be any target you might name on the command line,
including directories.  In some projects we name a subdirectory as a
Default() if we know we want every target under that directory to be
built by default.  It could even be an Install location, if you install
default targets to a specific directory.  Maybe in your case that
doesn't help much, if every default target also has example
subdirectories which should not be the default.  In the long run I think
you'll benefit more from naming defaults explicitly, rather than trying
to exclude certain targets from defaults, since then you're being
explicit about the main products of your build.  And obviously you don't
need to name any dependencies like libraries as defaults, unless of
course they are a necessary product which nothing else uses.  Finally,
you could name all the Default() targets in one place, such as the
top-level SConstruct, if you'd rather consolidate that information in
one place instead of modifying all the subdirectories.  For example, as
a first cut, write a script to list all executables that are not in a
'example' directory, and add those to Default().

It is very useful to be able to list the default targets, so I added
that capability to one of our tools using DEFAULT_TARGETS.  However, it
seems like a natural extension to add that to the SCons project help,
and to list the default targets even when DEFAULT_TARGETS is empty.  (I
use something similar for aliases too.)  I should volunteer to do that...

gary

On 1/4/19 9:55 AM, Mats Wichmann wrote:
> 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?
>
>
> _______________________________________________
> Scons-users mailing list
> [email protected]
> https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users
pEpkey.asc (application/pgp-keys, 1.7 KB)