[Scons-users] separation of behavior between building objects for shared libs and for executables

[Bill Deegan]

There are some reasonable examples in the users guide and in the wiki.

Generally, a top level SConstruct, and then per source dir SConscript.
The top level may set up the Environment()(s) which you use and then pass
them to the SConscripts.
Also using variant_dir arg in SConscript() will allow you to create
different variants (release/debug/other) and keep the built files (objects,
libraries,programs,etc) in different directories than the source files.

Does that help answer your questions?

-Bill

On Thu, Jun 15, 2017 at 4:50 PM, Mats Wichmann <mats at wichmann.us> wrote:

> On 06/15/2017 02:18 PM, Bill Deegan wrote:
> > You can create several Environment()'s with different settings, or you
> can
> > specify the flags on env.Program(), or env.SharedObject(), or
> > env.Object(),etc...
> >
> >
> > What is your goal? (1000 foot view)
> > Start with that, rather than if I do this thing will it do this other
> thing?
>
> Goal? at this point, understanding (I'm learning by way of a project
> which has grown organically with lots of essentially drive-by
> contributions, as opposed to learning by building something from scratch)
>
> I guess to see if it makes sense to build shared libraries and
> executables (and other things which need "special treatment", like unit
> tests, which might need linking with a testing library) from the same
> sconscript, or if they should be separated into directories which have
> their own scripts. I know "lump it together or separate things into
> directories" is more philosophy than requirements.  And it sounds like
> existing facilities such as different-environments-for-different-things
> are probably sufficient to adapt either way.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20170615/4106be45/attachment.html>