[Scons-users] optional build components

[Bill Deegan]

Have you tried.

Ignore('.',target_I_dont_want_to_build_by_Default)
?


On Fri, Jan 4, 2019 at 1:16 PM Gary Granger <granger at ucar.edu> wrote:

> 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
> > Scons-users at scons.org
> > https://pairlist4.pair.net/mailman/listinfo/scons-users
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20190104/0bde54c9/attachment.html>