Re: [Scons-dev] proposed change to _SConscript

[Jason Kenny]

Let me put something together.

I currently trying to make a test to help show this working in Parts at the 
moment, and making sure such as change does not break something else.

Jason

From: Scons-dev  On Behalf Of Bill Deegan
Sent: Monday, January 28, 2019 6:07 PM
To: SCons developer list 
Subject: Re: [Scons-dev] proposed change to _SConscript

Do you have a simple sample script (Without parts) to demonstrate glob not 
working as you describe?
Seems like if that wasn't working you might've brought it to our attention? ;)

Also simple (non parts) script to demonstrate how you were trying to do this 
with sconscript and repository?

On Mon, Jan 28, 2019 at 2:00 PM Jason Kenny 
mailto:dragon...@live.com>> wrote:
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 
mailto:scons-dev-boun...@scons.org>> On Behalf Of 
Bill Deegan
Sent: Monday, January 28, 2019 1:03 PM
To: SCons developer list mailto: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 
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
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] proposed change to _SConscript

[Bill Deegan]

Do you have a simple sample script (Without parts) to demonstrate glob not
working as you describe?
Seems like if that wasn't working you might've brought it to our attention?
;)

Also simple (non parts) script to demonstrate how you were trying to do
this with sconscript and repository?

On Mon, Jan 28, 2019 at 2:00 PM Jason Kenny  wrote:

> 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  *On Behalf Of *Bill Deegan
> *Sent:* Monday, January 28, 2019 1:03 PM
> *To:* SCons developer list 
> *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  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
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> 
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___

Re: [Scons-dev] proposed change to _SConscript

[Jason Kenny]

Ya.. I mentioned that the code I was using is a feature that was removed from 
documentation. I think now the reason it was removed was because people got 
confused on what was going on..

The original sconscript ( and  a feature I have used in Parts since day 1) 
looks like this:
https://scons.org/doc/1.0.0/HTML/scons-man.html

The text below:

SConscript(scripts, [exports, variant_dir, src_dir, duplicate])
env.SConscript(scripts, [exports, variant_dir, src_dir, duplicate])
SConscript(dirs=subdirs, [name=script, exports, variant_dir, src_dir, 
duplicate])
env.SConscript(dirs=subdirs, [name=script, exports, variant_dir, src_dir, 
duplicate])
This tells scons to execute one or more subsidiary SConscript (configuration) 
files. There are two ways to call the SConscript() function.
The first way you can call SConscript() is to explicitly specify one or more 
scripts as the first argument. A single script may be specified as a string; 
multiple scripts must be specified as a list (either explicitly or as created 
by a function like Split()).

The second way you can call SConscript() is to specify a list of (sub)directory 
names as a dirs=subdirs keyword argument. In this case, scons will, by default, 
execute a subsidiary configuration file named SConscript in each of the 
specified directories. You may specify a name other than SConscript by 
supplying an optional name=script keyword argument.

The optional exports argument provides a list of variable names or a dictionary 
of named values to export to the script(s). These variables are locally 
exported only to the specified script(s), and do not affect the global pool of 
variables used by the Export() function. The subsidiary script(s) must use the 
Import() function to import the variables.

If the optional variant_dir argument is present, it causes an effect equivalent 
to VariantDir( variant_dir, src_dir, duplicate) to be executed prior to reading 
the script(s). (If variant_dir is not present, the src_dir and duplicate 
arguments are ignored.) The variant_dir and src_dir arguments are interpreted 
relative to the directory of the calling SConscript file. If src_dir is not 
specified, the directory of the calling SConscript file is assumed. See the 
description of the VariantDir() function below for additional details and 
restrictions.

Any variables returned by script using Return() will be returned by the call to 
SConscript().
...
---

This code basically allowed one to control the src_dir that was used when 
SConscript() was used. The core code is the base for repository(). However the 
src_dir was removed as it was broken with the logic to change the directory to 
the location of the "sconscript". This gets worse with the idea that the src 
directory has to be under the sconscript. The reality is that it does not. 

Jason

-Original Message-
From: Mats Wichmann  
Sent: Monday, January 28, 2019 5:06 PM
To: SCons developer list ; Jason Kenny 
Subject: Re: [Scons-dev] proposed change to _SConscript

So at least vaguely confused:

>> are you using Repository to achieve this?

> No,

any yet, the comments at the code snippet suggests strongly Repository is 
involved:

> except OSError:
> # There was no local directory, so we should be
> # able to chdir to the Repository directory.
> # Note that we do this directly,
...


___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] proposed change to _SConscript

[Mats Wichmann]

So at least vaguely confused:

>> are you using Repository to achieve this?

> No,

any yet, the comments at the code snippet suggests strongly Repository
is involved:

> except OSError:
> # There was no local directory, so we should be
> # able to chdir to the Repository directory.
> # Note that we do this directly, 
...


___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] proposed change to _SConscript

[Jason Kenny]

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  On Behalf Of Bill Deegan
Sent: Monday, January 28, 2019 1:03 PM
To: SCons developer list 
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 
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
https://pairlist2.pair.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] proposed change to _SConscript

[Bill Deegan]

are you using Repository to achieve this?

On Mon, Jan 28, 2019 at 11:01 AM Jason Kenny  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
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] proposed change to _SConscript

[Jason Kenny]

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
https://pairlist2.pair.net/mailman/listinfo/scons-dev