No, I was trying to see if I could achieve this via Repository(), however I discovered it failed because Glob() does not seem to work correctly with the Repostory() and VariantDir() logic when I recurse search file Files ( As I do with Pattern() api in Parts… it goes in to a death loop of variant directory recursion on itself ☹ ). So instead I am looking having Parts detect that a “vcs” object was used and if the checkout directory and the .part file directory are different then pass the checkout directory via src_dir to the SConscript() call.
I should note that the _SConscript code still needs a fix to handle more than one Repository(). It looks like that a loop has to be added. However this seems like a non-trival change. Jason From: Scons-dev <scons-dev-boun...@scons.org> On Behalf Of Bill Deegan Sent: Monday, January 28, 2019 1:03 PM To: SCons developer list <scons-dev@scons.org> Subject: Re: [Scons-dev] proposed change to _SConscript are you using Repository to achieve this? On Mon, Jan 28, 2019 at 11:01 AM Jason Kenny <dragon...@live.com<mailto:dragon...@live.com>> wrote: Hi, I would like to make a proposal to for a small change to _SConscript function. The change is related to code around line 260. ie this section of code: try: fs.chdir(ldir, change_os_dir=sconscript_chdir) except OSError: # There was no local directory, so we should be # able to chdir to the Repository directory. # Note that we do this directly, not through # fs.chdir(), because we still need to # interpret the stuff within the SConscript file # relative to where we are logically. fs.chdir(ldir, change_os_dir=0) os.chdir(actual.dir.get_abspath()) I would like to change the os.chdir(actual.dir.get_abspath()) to os.chdir(ldir.srcnode().abspath) I believe this code is more correct and solve an issue I would like to correct when calling scons on "out of source" builds. What this changes as documented, should be nothing. What it changes/fixes is use of the src_dir keyword in the SConscript() call ( which was documented a long time ago). What this fixes for me is the ability define a build file that is not in a source tree, as if it was in the source tree. In the case Parts I can define a Parts that would checkout or used some code checked out via another means as if the build file was part of the source tree. The value of this is: 1) may not have the ability to add new builds files to an existing project 2) may want to show how a new build system ( as Scons) would add value to an existing setup, without having to get build files checked in. 3) want to build an external project as if the build file was part of the project. 4) other logic related to the above... This is basically like an CMake external project for me in Parts as I can tell Parts to checkout some code and build it via having a Part file that can build it directly or via having it call the native build system via Command() or some custom builder. This line change would allow for build file to pretend that it exists in the source location. It would also allow me to define three basic concepts in Parts: 1) build/Variant directory ( where we do the build actions) 2) build file/part_dir directory ( ie the directory in which the build file exists) 3) Source/src_dir directory ( ie where the source exists) most of this time the src_dir==part_dir except of out of source cases. I wanted to ask about this to make sure there is nothing I might be missing that would cause concerns If this is fine I would like to make a patch for this for Scons ( vs me monkey patching it in Parts) Jason _______________________________________________ Scons-dev mailing list Scons-dev@scons.org<mailto:Scons-dev@scons.org> https://pairlist2.pair.net/mailman/listinfo/scons-dev<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist2.pair.net%2Fmailman%2Flistinfo%2Fscons-dev&data=02%7C01%7C%7C6b0a5875d5084ea75e3408d68554274d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636842993811578067&sdata=N1Vvh3n2Vd81F2qLBEIfMgts4VuScR57a8K4zU9Fp8k%3D&reserved=0>
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
