[Scons-users] Maven Ideas with Scons -- File missing on wiki

[Bill Deegan]

Javier,




On Fri, Mar 11, 2016 at 11:13 AM, Javier Llopis <javier at correo.com> wrote:

> Hi Bill,
>
> Yes, at each step of the build, every component knows the bits it needs to
> compile and add (to a static library) or link (for a shared library). If I
> have a program P that links to libraries A and B, it will also need A and
> B's include paths, but it doesn't need nor want anything to do with library
> C that was needed by A, which had additional compiler options and include
> paths that P isn't concerned with.
>
> In the code provided, I see that Jakob Scheck is just attaching a
> dictionary variable, which he calls 'pom', to the environment and storing
> in it all sorts of interesting info which he then processes. I think I
> could go that way, creating an environment on SConstruct, and cloning it on
> the different SConscripts and returning just the info needed by anyone to
> use the library, from which the upper level SConstruct or SConscript can
> build the other modules by attaching to the environment the info they need.
> All I would need then is a function that builds an environment with the OS,
> Architecture, etc. for the main SConstruct.
>

Rarely is it actually necessary to clone the environment in each and every
SConscript.
Unless you are altering it in a way you don't want to propagate.
Usually adding LIBS,etc to the env.Program() is a better choice than
env['LIBS']...

=Bill


>
> Thanks
>
> J
>
>
>
> On Fri, Mar 11, 2016 at 14:57, Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
> Javier,
>
>
>
> On Fri, Mar 11, 2016 at 8:58 AM, Javier Llopis <javier at correo.com> wrote:
>
> Thank you so much for the file, Bill.
>
> Indeed, I have found in my design that the environment itself has most of
> what I need. When I create a library --and I create a bunch of those- I
> need to be Return()ing not only the library but also list of include
> directories, that means either that the project gets a longer and longer
> list of include paths (which is ugly but not dangerous) or that I need to
> add a little logic to handle what dependencies are needed by this bit and
> what dependencies are needed by the other bit. The wiki recipe seems to be
> doing that in a nice, declarative way. Other than that, I am thinking of
> either subclassing Environment or creating a class that mostly contains an
> environment plus a few other bits, or perhaps even nothing at all, as you
> say, and it's just a matter of always doing things the same way in a
> consistent manner. I don't yet have a clear idea at this point.
>
>
> Firstly, there are a number of ways to simplify what you are trying to do.
>
> You don't need to return the libraries and such, just add them to your
> Environment() and Export() it.
>
> Does each program know the libraries it needs to link against?
> Or are you adding each library to the list as you create the library and
> the program(s) link against all of them?
>
> To ask another way, how do you decide which libraries and/or include paths
> are needed for each program/library/source file compile?
>
> Subclassing Environment is likely not the best way to go and likely
> overkill.
>
> Can you explain what "other bits" you would need to add?
>
> -Bill
>
>
>
>
>
>
> J
>
> On Fri, Mar 11, 2016 at 13:33, Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
>
>
> On Fri, Mar 11, 2016 at 7:02 AM, Javier Llopis <javier at correo.com> wrote:
>
> Hello,
>
> TL;DR: There is a recipe on the wiki "Maven Ideas with Scons" by Jakob
> Scheck at https://bitbucket.org/scons/scons/wiki/MavenIdeasWithSCons that
> I have found inspiring. Unfortunately, the sources that come with it in a
> separate file seem to have been lost, possibly during some of the recent
> site moves. It would be great if someone could give me a pointer to that
> file, which I would put back to the wiki.
>
>
>
> The file is still there, but the link to it wasn't properly translated in
> the move.
>
> Here's the file:
> https://bitbucket.org/scons/scons/wiki/MavenIdeasWithSCons/sources.zip
>
> I'll get the link updated today.
>
>
>
> The broader issue is I need to cut down the boilerplate I find myself
> writing all the time. I have sources and dependencies that I need to build
> for windows or Linux, for x86 or x64, with or without debug symbols, and I
> need to be keeping track of include directories, libraries, library
> directories, preprocessor symbols and compiler switches, along with one or
> two custom builders that I have in use. There is a lot of information being
> passed back and forth and it becomes messy. I have been reading the wiki
> and earlier list messages for ideas on how to go about this issue and found
> some good ones here and there. I may need to implement my own 'boilerplate
> encapsulator class' and I think it could be something like described in the
> above article. Looking at the sources would save me some time, but I am
> open to other suggestions, as I don't think this problem is too uncommon.
>
>
> I'm not sure what couldn't be handled by adding variables to the
> Environment().
> All the items you mention "include directories, libraries, library
> directories, preprocessor symbols and compiler switches, along with one or
> two custom builders that I have in use."  are simple to add to the
> env['MY_INCLUDE']='#abc/def', and then use later.
> Just Export() and Import() the environment between your SConstruct and
> SConscript(s)
> Is there something more complicated that that?
>
> -Bill
>
>
>
> _______________________________________________
> 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/20160313/0a7ae9bc/attachment.html>