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

Vasily just.one.man at yandex.ru
Sat Mar 12 04:51:18 EST 2016


Now responding from proper email...

Thanks,
Vasily
12 марта 2016 г. 12:50 пользователь "Vasily" <vassnlit at gmail.com> написал:

> Hi Jakob,
> Looks like you're describing Parts :-) See bitbucket.org/sconsparts for
> more.
>
> Thanks,
> Vasily
> 11 марта 2016 г. 19:13 пользователь "Javier Llopis" <javier at correo.com>
> написал:
>
>> 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 <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/20160312/19962e5c/attachment.html>


More information about the Scons-users mailing list