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

[Bill Deegan]

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/20160309/c445a52f/attachment.html>