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

Fri Mar 11 08:32:20 EST 2016

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

>
> Thanks
>
> J
>
>
> On Thu, Mar 10, 2016 at 18:38, Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
> Jason,
>
>
>
>
> On Thu, Mar 10, 2016 at 12:23 PM, Jason Kenny <dragon512 at live.com> wrote:
>
> Bill,
>
> First, let me add this to user group.
>
> So maybe I am doing something wrong, but..
>
> I think the core issue here is that SCons only allows one active
> VariantDir at a time to be actively translated.
>
>
> SCons only allows one variantdir processed per target dir, but not per
> Environment().
> So src/a -> output/a, src/b -> output_b/b, etc is fine
>
> src/a -> output/a
> src/bin -> output/b # Fails..
>
>
>
> When a user does a
>
> Env.VariantDir(“debug”,”src”)
> Env.Sconscript(“debug/Sconscript”)
>
> The user has to refer to files in the Sconscript as “file1” or
> “sub1/file2” and these value get changed into “debug/file1” or
> “debug/sub1/file2”.
>
> If I was to refer to a file outside the src directory such as a
> “src2/file3”. This requires active translation by the user for file not
> under the source directory of the sconscript.
>
> I can do one of two things.
>
> 1.       add a another VariantDir(“#debug/outoftree”,”.”) and then monkey
> path env.File() to auto translate any string that is not under the current
> source directory. This way a #src2/file3 would be translated to a
> “#debug/outoftree/src2/file3”, much like the file “sub1/file2” is turned in
> to “debug/sub1/file2” inside the Sconscript with out user intervention.
> 2.       Try to setup funny relative path, however if this tends to fail
> if the Variant directory and source directory don’t have the same level of
> subdirectories.
>
> I think what would be useful for SCons is to have the logic in the Nodes
> to allow for 1) to work. While one can argue about what the current way
> Variant Directory works is correct, I believe it is clear that users need
> the translation to work for usability. In complex builds it is not always
> obvious what the Variant Directory is.
>
>
> How would this work when there are N variants (and thus N variant
> directory trees)?
>
>
>
> I think I going to have to setup some form of 1) to address this problem
> in Parts. This means I setup a set of 1 or 2 more active directory’s that I
> would look for when the File, Dir, etc node is made and translate the path
> if it start with correct source path. This will allow different parts such
> as PartA and PartB refer to a common file out these parts subtree and built
> it correctly for each Part case.
>
> Or I could add a new variable like $ROOTNODE_BUILD_DIR and change the
> Parts AbsFile() api to translate these files to correct Variant Directory
> based on it being under the Sconstruct directory or outside it.
>
> I think making a way to do this more directly without a monkey patch would
> be useful. I need to look at the second option with modifying the Part
> AbsFile API to see if this could work. This might be an easy addition that
> could be moved to SCons.
>
>
> You might be better to use Repository pointing targets into the variantdir?
>
> -Bill
>
>
> Jason
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
> *From: *Bill Deegan <bill at baddogconsulting.com>
> *Sent: *Wednesday, March 9, 2016 9:29 PM
> *To: *SCons developer list <scons-dev at scons.org>
> *Subject: *Re: [Scons-dev] VariantDir() and #paths to files
>
> Jason,
>
> The problem you are seeing ( believe) is that calling SConscript() with a
> variant_dir argument performs the function
>
> VariantDir(whatever the variant dir was specified, directory of the
> SConscript file).
>
> Where you'd likely need also
>
> VariantDir(whatever the variant dir was specified, "#/myprog/test/unit")
> And then to have the source file referenced via the variant dir and not
> the source dir #/myprog/test/unit.
>
> So then the question would be is it correct to automatically apply the
> variantdir behavior to any source file specified in the SConscript being
> read when it is specified with variant_dir?
> One thing for sure, doing so would be a break with current functionality
> and would trigger a deprecation cycle.
>
> Would it make sense to provide (an)other flag(s) to tell SConscript to do
> this?
>
> These are just some items to consider from a quick look at the issue.
>
> Also, I'd say this would be safe/better for users mailing list since this
> is about how to use/proper functioning of user visible SCons logic.
> -Bill
>
> On Wed, Mar 9, 2016 at 10:15 PM, Jason Kenny <dragon512 at live.com> wrote:
>
>
> Hi guys,
>
> There has been a constant issue I have had with using SCons with
> VariantDir logic. I was wondering if I am missing something.
>
> The issue shows up a number of time when people use Parts. The issue is
> when the user wants to use a file outside the directory containing the part
> file ( From a pure Scons point of view a part file is what would be called
> a SConscript). I believe this is a known issue with SCons, however it seems
> this is a common problem I have seen many times, enough for me to think
> there should be some better solution.
>
> I have a example of this with an issue in Parts just opened.
> https://bitbucket.org/sconsparts/parts/issues/1/unit-test-object-build-files-can-appear-in
>
> The easy answer for me is to say move the parts file up to the root. And
> tweak a few paths in a part file, to allow all files to be at the same
> level or below the location of the parts file. While this will solve the
> problem, I know it will be seen again as users have a reason they want to
> locate the “build” files in different locations from the all or some of the
> source. In this example they seem to have a pattern in which they have some
> “common” test helpers files that they want other Parts to use when creating
> there unit test. It makes sense, I would like to find a way to allow this
> functionality to the user in a painless way ( ie I do something under the
> covers ). There is an attached example of the issue.
>
> Does anyone have any thought on this?
>
>
> Jason
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
>
> _______________________________________________
> 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/20160311/16970813/attachment-0001.html>