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

[Bill Deegan]

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20160310/5201d366/attachment-0001.html>