[Scons-dev] VariantDir() and #paths to files

[Jason Kenny]

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

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.

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 <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20160310/b5666bca/attachment.html>
-------------- next part --------------
_______________________________________________
Scons-dev mailing list
Scons-dev at scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev