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 <[email protected]> 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 > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
