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

Fri Mar 11 11:13:16 EST 2016

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.

Thanks

J
On Fri, Mar 11, 2016 at 14:57, Bill Deegan  wrote: Javier,
On Fri, Mar 11, 2016 at 8:58 AM, Javier Llopis  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  wrote:
On Fri, Mar 11, 2016 at 7:02 AM, Javier Llopis  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 (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 (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 (mailto:Scons-users at scons.org)
https://pairlist4.pair.net/mailman/listinfo/scons-users (https://pairlist4.pair.net/mailman/listinfo/scons-users)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160311/0cde791c/attachment.html>