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

Fri Mar 11 07:02:59 EST 2016

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 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.

Thanks

J
On Thu, Mar 10, 2016 at 18:38, Bill Deegan  wrote:
Jason,
On Thu, Mar 10, 2016 at 12:23 PM, Jason Kenny  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 (mailto:bill at baddogconsulting.com)
Sent: Wednesday, March 9, 2016 9:29 PM
To: SCons developer list (mailto: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   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 (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 (mailto:Scons-dev at scons.org)
https://pairlist2.pair.net/mailman/listinfo/scons-dev (https://pairlist2.pair.net/mailman/listinfo/scons-dev)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160311/5011f7d2/attachment.html>