Re: [Scons-dev] Requesting feedback on new website design

[Dirk Bächle]

Hey Bill,

On 08.08.2015 00:21, Bill Deegan wrote:

I made a bunch more changes.

http://scons.org/new/

The download page isn't quite right yet, but the navigation is pretty much done.

feedback?



this looks really great now! I like it a lot...and would switch this to "live", even though there might still be a few quirks or 
some material missing. Have you tried how the design looks with the default "SCons red" for the section headings and the old 
background color?

This would then better match our UserGuide/MAN page docs, I think...but I'm not 
a graphical designer.

Again, just awesome!

Dirk

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

Re: [Scons-dev] Patch for potential new debug option

[Roberto De Vecchi]

William,

from my experience using varname as a filter to limit the output will not help 
much in big trees where my cloned env are assigned to vars with the same name.

I would find very useful having the env dump limited to the target node 
specified on the command line: is this already supported by your proposal?

Roberto

--- Messaggio Originale ---
Da: William Blevins 
Data:   08 Agosto 2015 07:22:12
Oggetto:[Scons-dev] Patch for potential new debug option
A:  SCons developer list 

Here is a patch for dumping build environments via the command-line.

I couldn't ever figure out a good way to get only explicitly lister targets 
(non-default commandline targets).  It will essentially print the 
node.get_env().Dump() for all targets with a build_env defined.

I could potentially change it from "--debug=envdump" to something like 
"--envdump=" so that it could print a particular variable rather than 
the whole env.

Does this interest anyone or waste of chars?

diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
--- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
+++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
@@ -391,6 +391,21 @@
 def prepare(self):
 pass

+class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
+"""SCons task for --debug=envdump.  Prints env dump for BUILD_TARGETS."""
+def prepare(self):
+pass
+
+def execute(self):
+for target in self.targets:
+if target.get_build_env():
+print 'Environment dump for target: ' + str(target)
+print target.get_env().Dump()
+
+def executed(self):
+pass
+
+
 class QuestionTask(SCons.Taskmaster.AlwaysTask):
 """An SCons task for the -q (question) option."""
 def prepare(self):
@@ -657,6 +672,7 @@
 if "memory" in debug_values:
 memory_stats.enable(sys.stdout)
 print_objects = ("objects" in debug_values)
+options.debug_envdump = ( "envdump" in debug_values )
 if print_objects:
 SCons.Debug.track_instances = True
 if "presub" in debug_values:
@@ -1210,8 +1226,13 @@
 failure_message = "done building targets (errors occurred during 
build)."
 else:
 failure_message = "building terminated because of errors."
+
+if options.debug_envdump:
+task_class = EnvDumpTask
+
 if options.question:
 task_class = QuestionTask
+
 try:
 if options.clean:
 task_class = CleanTask
diff -r 682b8a7a51fb src/engine/SCons/Script/SConsOptions.py
--- a/src/engine/SCons/Script/SConsOptions.pyMon Jun 29 15:37:44 2015 -0400
+++ b/src/engine/SCons/Script/SConsOptions.pyThu Aug 06 23:44:50 2015 -0400
@@ -673,7 +673,7 @@
 "tree"  : '; please use --tree=all instead',
 }

-debug_options = ["count", "duplicate", "explain", "findlibs",
+debug_options = ["count", "duplicate", "explain", "envdump", "findlibs",
  "includes", "memoizer", "memory", "objects",
  "pdb", "prepare", "presub", "stacktrace",
  "time"]



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

Re: [Scons-dev] Patch for potential new debug option

[William Blevins]

I guess I should be a bit more explicit about what I am trying to do.

Example:
A.cpp
SConstruct -> "Program( 'exe', Glob( '*.cpp' ) )"

My goal original goal was to be able to print environment objects from the
command-line without having to modify code:
1. As written: [Example: "scons --debug=envdump A.o" would print the build
environment object assigned to "A.o" ].
2. Afterthought on usability: [Example: "scons --envdump=LIBS A.o" would
print the variable LIBS from the build environment assigned to "A.o"].
2.1 Since environment objects are rather large, maybe printing just a
single value from the environment object would be more readable and/or
desired on a regular basis.

The supplied patch works for Case 1, but I am having a hard time getting
only the targets on the command-line.  Currently, the patch prints the
environment for all targets on the command-line, plus all their
dependencies (as long as they have build environments) and I am hoping to
not print their dependencies.

[Example: "scons --debug=envdump A.o" would print the environment for
target "A.o" but not "A.cpp" or "/usr/bin/g++" because they don't have a
build environment.]

[Example: "scons --debug=envdump exe" would print the environment for
target "exe" plus "A.o" because it's in the target list (as a dependency of
"exe")]

If I can figure out a clean way to get only the targets on the
command-line, then that makes the most sense.  The real question is do we
want Case 1, Case 2,or both capabilities?

V/R,
William





On Sat, Aug 8, 2015 at 3:42 AM, Roberto De Vecchi <
roberto.devec...@vi-grade.com> wrote:

> William,
>
> from my experience using varname as a filter to limit the output will not
> help much in big trees where my cloned env are assigned to vars with the
> same name.
>
> I would find very useful having the env dump limited to the target node
> specified on the command line: is this already supported by your proposal?
>
> Roberto
> --- Messaggio Originale --- *Da: * William Blevins 
> *Data: * 08 Agosto 2015 07:22:12 *Oggetto: * [Scons-dev] Patch for
> potential new debug option *A: * SCons developer list  >
>
> Here is a patch for dumping build environments via the command-line.
>>
>> I couldn't ever figure out a good way to get only explicitly lister
>> targets (non-default commandline targets).  It will essentially print the
>> node.get_env().Dump() for all targets with a build_env defined.
>>
>> I could potentially change it from "--debug=envdump" to something like
>> "--envdump=" so that it could print a particular variable rather
>> than the whole env.
>>
>> Does this interest anyone or waste of chars?
>>
>> diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
>>> --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
>>> +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
>>> @@ -391,6 +391,21 @@
>>>  def prepare(self):
>>>  pass
>>>
>>> +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
>>> +"""SCons task for --debug=envdump.  Prints env dump for
>>> BUILD_TARGETS."""
>>> +def prepare(self):
>>> +pass
>>> +
>>> +def execute(self):
>>> +for target in self.targets:
>>> +if target.get_build_env():
>>> +print 'Environment dump for target: ' + str(target)
>>> +print target.get_env().Dump()
>>> +
>>> +def executed(self):
>>> +pass
>>> +
>>> +
>>>  class QuestionTask(SCons.Taskmaster.AlwaysTask):
>>>  """An SCons task for the -q (question) option."""
>>>  def prepare(self):
>>> @@ -657,6 +672,7 @@
>>>  if "memory" in debug_values:
>>>  memory_stats.enable(sys.stdout)
>>>  print_objects = ("objects" in debug_values)
>>> +options.debug_envdump = ( "envdump" in debug_values )
>>>  if print_objects:
>>>  SCons.Debug.track_instances = True
>>>  if "presub" in debug_values:
>>> @@ -1210,8 +1226,13 @@
>>>  failure_message = "done building targets (errors occurred
>>> during build)."
>>>  else:
>>>  failure_message = "building terminated because of errors."
>>> +
>>> +if options.debug_envdump:
>>> +task_class = EnvDumpTask
>>> +
>>>  if options.question:
>>>  task_class = QuestionTask
>>> +
>>>  try:
>>>  if options.clean:
>>>  task_class = CleanTask
>>> diff -r 682b8a7a51fb src/engine/SCons/Script/SConsOptions.py
>>> --- a/src/engine/SCons/Script/SConsOptions.pyMon Jun 29 15:37:44
>>> 2015 -0400
>>> +++ b/src/engine/SCons/Script/SConsOptions.pyThu Aug 06 23:44:50
>>> 2015 -0400
>>> @@ -673,7 +673,7 @@
>>>  "tree"  : '; please use --tree=all instead',
>>>  }
>>>
>>> -debug_options = ["count", "duplicate", "explain", "findlibs",
>>> +debug_options = ["count", "duplicate", "explain", "envdump",
>>> "findlibs",
>>>   "includes", "memoizer", "memory", "objects",
>>>   "pdb", "prepare", "presub", "stacktrace",
>>>   

Re: [Scons-dev] Patch for potential new debug option

[Alexandre Feblot]

Hi,
would have this been available, I indeed would already have used scons 
--envdump=CXXFLAGS,CFLAGS,ENV.PATH A.o

--
Alexandre Feblot

> Le 8 août 2015 à 15:04, William Blevins  a écrit :
> 
> I guess I should be a bit more explicit about what I am trying to do.
> 
> Example:
> A.cpp
> SConstruct -> "Program( 'exe', Glob( '*.cpp' ) )"
> 
> My goal original goal was to be able to print environment objects from the 
> command-line without having to modify code:
> 1. As written: [Example: "scons --debug=envdump A.o" would print the build 
> environment object assigned to "A.o" ].
> 2. Afterthought on usability: [Example: "scons --envdump=LIBS A.o" would 
> print the variable LIBS from the build environment assigned to "A.o"].
> 2.1 Since environment objects are rather large, maybe printing just a single 
> value from the environment object would be more readable and/or desired on a 
> regular basis.
> 
> The supplied patch works for Case 1, but I am having a hard time getting only 
> the targets on the command-line.  Currently, the patch prints the environment 
> for all targets on the command-line, plus all their dependencies (as long as 
> they have build environments) and I am hoping to not print their dependencies.
> 
> [Example: "scons --debug=envdump A.o" would print the environment for target 
> "A.o" but not "A.cpp" or "/usr/bin/g++" because they don't have a build 
> environment.]
> 
> [Example: "scons --debug=envdump exe" would print the environment for target 
> "exe" plus "A.o" because it's in the target list (as a dependency of "exe")]
> 
> If I can figure out a clean way to get only the targets on the command-line, 
> then that makes the most sense.  The real question is do we want Case 1, Case 
> 2,or both capabilities?
> 
> V/R,
> William
> 
> 
> 
> 
> 
> On Sat, Aug 8, 2015 at 3:42 AM, Roberto De Vecchi 
> mailto:roberto.devec...@vi-grade.com>> wrote:
> William,
> 
> from my experience using varname as a filter to limit the output will not 
> help much in big trees where my cloned env are assigned to vars with the same 
> name.
> 
> I would find very useful having the env dump limited to the target node 
> specified on the command line: is this already supported by your proposal?
> 
> Roberto
> 
> --- Messaggio Originale ---
> Da:   William Blevins mailto:wblevins...@gmail.com>>
> Data: 08 Agosto 2015 07:22:12
> Oggetto:  [Scons-dev] Patch for potential new debug option
> A:SCons developer list mailto:scons-dev@scons.org>>
> 
>> Here is a patch for dumping build environments via the command-line.
>> 
>> I couldn't ever figure out a good way to get only explicitly lister targets 
>> (non-default commandline targets).  It will essentially print the 
>> node.get_env().Dump() for all targets with a build_env defined.
>> 
>> I could potentially change it from "--debug=envdump" to something like 
>> "--envdump=" so that it could print a particular variable rather 
>> than the whole env.
>> 
>> Does this interest anyone or waste of chars?
>> 
>> diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
>> --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
>> +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
>> @@ -391,6 +391,21 @@
>>  def prepare(self):
>>  pass
>>  
>> +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
>> +"""SCons task for --debug=envdump.  Prints env dump for 
>> BUILD_TARGETS."""
>> +def prepare(self):
>> +pass
>> +
>> +def execute(self):
>> +for target in self.targets:
>> +if target.get_build_env():
>> +print 'Environment dump for target: ' + str(target)
>> +print target.get_env().Dump()
>> +
>> +def executed(self):
>> +pass
>> +
>> +
>>  class QuestionTask(SCons.Taskmaster.AlwaysTask):
>>  """An SCons task for the -q (question) option."""
>>  def prepare(self):
>> @@ -657,6 +672,7 @@
>>  if "memory" in debug_values:
>>  memory_stats.enable(sys.stdout)
>>  print_objects = ("objects" in debug_values)
>> +options.debug_envdump = ( "envdump" in debug_values )
>>  if print_objects:
>>  SCons.Debug.track_instances = True
>>  if "presub" in debug_values:
>> @@ -1210,8 +1226,13 @@
>>  failure_message = "done building targets (errors occurred during 
>> build)."
>>  else:
>>  failure_message = "building terminated because of errors."
>> +
>> +if options.debug_envdump:
>> +task_class = EnvDumpTask
>> +
>>  if options.question:
>>  task_class = QuestionTask
>> +
>>  try:
>>  if options.clean:
>>  task_class = CleanTask
>> diff -r 682b8a7a51fb src/engine/SCons/Script/SConsOptions.py
>> --- a/src/engine/SCons/Script/SConsOptions.pyMon Jun 29 15:37:44 2015 
>> -0400
>> +++ b/src/engine/SCons/Script/SConsOptions.pyThu Aug 06 23:44:50 2015 
>> -0400
>> @@ -673,7 +673,7 @@
>>  "tree"  : '; please use 

Re: [Scons-dev] Patch for potential new debug option

[William Blevins]

On Sat, Aug 8, 2015 at 9:14 AM, Alexandre Feblot 
wrote:

> Hi,
> would have this been available, I indeed would already have used scons
> --envdump=CXXFLAGS,CFLAGS,ENV.PATH A.o
>
>
When I thought about the feature, I also thought the case 2 was more
useful, thank you for your feedback.  I can do both if we decided that
printing the whole environment object is ever useful, but lean code bases
make for maintainable code bases :)


> *--*
> Alexandre Feblot
>
> Le 8 août 2015 à 15:04, William Blevins  a écrit :
>
> I guess I should be a bit more explicit about what I am trying to do.
>
> Example:
> A.cpp
> SConstruct -> "Program( 'exe', Glob( '*.cpp' ) )"
>
> My goal original goal was to be able to print environment objects from the
> command-line without having to modify code:
> 1. As written: [Example: "scons --debug=envdump A.o" would print the build
> environment object assigned to "A.o" ].
> 2. Afterthought on usability: [Example: "scons --envdump=LIBS A.o" would
> print the variable LIBS from the build environment assigned to "A.o"].
> 2.1 Since environment objects are rather large, maybe printing just a
> single value from the environment object would be more readable and/or
> desired on a regular basis.
>
> The supplied patch works for Case 1, but I am having a hard time getting
> only the targets on the command-line.  Currently, the patch prints the
> environment for all targets on the command-line, plus all their
> dependencies (as long as they have build environments) and I am hoping to
> not print their dependencies.
>
> [Example: "scons --debug=envdump A.o" would print the environment for
> target "A.o" but not "A.cpp" or "/usr/bin/g++" because they don't have a
> build environment.]
>
> [Example: "scons --debug=envdump exe" would print the environment for
> target "exe" plus "A.o" because it's in the target list (as a dependency of
> "exe")]
>
> If I can figure out a clean way to get only the targets on the
> command-line, then that makes the most sense.  The real question is do we
> want Case 1, Case 2,or both capabilities?
>
> V/R,
> William
>
>
>
>
>
> On Sat, Aug 8, 2015 at 3:42 AM, Roberto De Vecchi <
> roberto.devec...@vi-grade.com> wrote:
>
>> William,
>>
>> from my experience using varname as a filter to limit the output will not
>> help much in big trees where my cloned env are assigned to vars with the
>> same name.
>>
>> I would find very useful having the env dump limited to the target node
>> specified on the command line: is this already supported by your proposal?
>>
>> Roberto
>> --- Messaggio Originale --- *Da: * William Blevins > > *Data: * 08 Agosto 2015 07:22:12 *Oggetto: * [Scons-dev] Patch for
>> potential new debug option *A: * SCons developer list <
>> scons-dev@scons.org>
>>
>> Here is a patch for dumping build environments via the command-line.
>>>
>>> I couldn't ever figure out a good way to get only explicitly lister
>>> targets (non-default commandline targets).  It will essentially print the
>>> node.get_env().Dump() for all targets with a build_env defined.
>>>
>>> I could potentially change it from "--debug=envdump" to something like
>>> "--envdump=" so that it could print a particular variable rather
>>> than the whole env.
>>>
>>> Does this interest anyone or waste of chars?
>>>
>>> diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
 --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
 +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
 @@ -391,6 +391,21 @@
  def prepare(self):
  pass

 +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
 +"""SCons task for --debug=envdump.  Prints env dump for
 BUILD_TARGETS."""
 +def prepare(self):
 +pass
 +
 +def execute(self):
 +for target in self.targets:
 +if target.get_build_env():
 +print 'Environment dump for target: ' + str(target)
 +print target.get_env().Dump()
 +
 +def executed(self):
 +pass
 +
 +
  class QuestionTask(SCons.Taskmaster.AlwaysTask):
  """An SCons task for the -q (question) option."""
  def prepare(self):
 @@ -657,6 +672,7 @@
  if "memory" in debug_values:
  memory_stats.enable(sys.stdout)
  print_objects = ("objects" in debug_values)
 +options.debug_envdump = ( "envdump" in debug_values )
  if print_objects:
  SCons.Debug.track_instances = True
  if "presub" in debug_values:
 @@ -1210,8 +1226,13 @@
  failure_message = "done building targets (errors occurred
 during build)."
  else:
  failure_message = "building terminated because of errors."
 +
 +if options.debug_envdump:
 +task_class = EnvDumpTask
 +
  if options.question:
  task_class = QuestionTask
 +
  try:
  if options.clean:
>>>

Re: [Scons-dev] Patch for potential new debug option

[Bill Deegan]

Perhaps an option to direct this output to a file?

On Sat, Aug 8, 2015 at 6:31 AM, William Blevins 
wrote:

>
>
> On Sat, Aug 8, 2015 at 9:14 AM, Alexandre Feblot 
> wrote:
>
>> Hi,
>> would have this been available, I indeed would already have used scons
>> --envdump=CXXFLAGS,CFLAGS,ENV.PATH A.o
>>
>>
> When I thought about the feature, I also thought the case 2 was more
> useful, thank you for your feedback.  I can do both if we decided that
> printing the whole environment object is ever useful, but lean code bases
> make for maintainable code bases :)
>
>
>> *--*
>> Alexandre Feblot
>>
>> Le 8 août 2015 à 15:04, William Blevins  a écrit :
>>
>> I guess I should be a bit more explicit about what I am trying to do.
>>
>> Example:
>> A.cpp
>> SConstruct -> "Program( 'exe', Glob( '*.cpp' ) )"
>>
>> My goal original goal was to be able to print environment objects from
>> the command-line without having to modify code:
>> 1. As written: [Example: "scons --debug=envdump A.o" would print the
>> build environment object assigned to "A.o" ].
>> 2. Afterthought on usability: [Example: "scons --envdump=LIBS A.o" would
>> print the variable LIBS from the build environment assigned to "A.o"].
>> 2.1 Since environment objects are rather large, maybe printing just a
>> single value from the environment object would be more readable and/or
>> desired on a regular basis.
>>
>> The supplied patch works for Case 1, but I am having a hard time getting
>> only the targets on the command-line.  Currently, the patch prints the
>> environment for all targets on the command-line, plus all their
>> dependencies (as long as they have build environments) and I am hoping to
>> not print their dependencies.
>>
>> [Example: "scons --debug=envdump A.o" would print the environment for
>> target "A.o" but not "A.cpp" or "/usr/bin/g++" because they don't have a
>> build environment.]
>>
>> [Example: "scons --debug=envdump exe" would print the environment for
>> target "exe" plus "A.o" because it's in the target list (as a dependency of
>> "exe")]
>>
>> If I can figure out a clean way to get only the targets on the
>> command-line, then that makes the most sense.  The real question is do we
>> want Case 1, Case 2,or both capabilities?
>>
>> V/R,
>> William
>>
>>
>>
>>
>>
>> On Sat, Aug 8, 2015 at 3:42 AM, Roberto De Vecchi <
>> roberto.devec...@vi-grade.com> wrote:
>>
>>> William,
>>>
>>> from my experience using varname as a filter to limit the output will
>>> not help much in big trees where my cloned env are assigned to vars with
>>> the same name.
>>>
>>> I would find very useful having the env dump limited to the target node
>>> specified on the command line: is this already supported by your proposal?
>>>
>>> Roberto
>>> --- Messaggio Originale --- *Da: * William Blevins <
>>> wblevins...@gmail.com> *Data: * 08 Agosto 2015 07:22:12 *Oggetto: * 
>>> [Scons-dev]
>>> Patch for potential new debug option *A: * SCons developer list <
>>> scons-dev@scons.org>
>>>
>>> Here is a patch for dumping build environments via the command-line.

 I couldn't ever figure out a good way to get only explicitly lister
 targets (non-default commandline targets).  It will essentially print the
 node.get_env().Dump() for all targets with a build_env defined.

 I could potentially change it from "--debug=envdump" to something like
 "--envdump=" so that it could print a particular variable rather
 than the whole env.

 Does this interest anyone or waste of chars?

 diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
> --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
> +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
> @@ -391,6 +391,21 @@
>  def prepare(self):
>  pass
>
> +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
> +"""SCons task for --debug=envdump.  Prints env dump for
> BUILD_TARGETS."""
> +def prepare(self):
> +pass
> +
> +def execute(self):
> +for target in self.targets:
> +if target.get_build_env():
> +print 'Environment dump for target: ' + str(target)
> +print target.get_env().Dump()
> +
> +def executed(self):
> +pass
> +
> +
>  class QuestionTask(SCons.Taskmaster.AlwaysTask):
>  """An SCons task for the -q (question) option."""
>  def prepare(self):
> @@ -657,6 +672,7 @@
>  if "memory" in debug_values:
>  memory_stats.enable(sys.stdout)
>  print_objects = ("objects" in debug_values)
> +options.debug_envdump = ( "envdump" in debug_values )
>  if print_objects:
>  SCons.Debug.track_instances = True
>  if "presub" in debug_values:
> @@ -1210,8 +1226,13 @@
>  failure_message = "done building targets (errors occurred
> during build)."
>  else:
> 

Re: [Scons-dev] Patch for potential new debug option

[Alexandre Feblot]

Would a standard shell redirection not be enough?
--
Alexandre Feblot

> Le 8 août 2015 à 17:38, Bill Deegan  a écrit :
> 
> Perhaps an option to direct this output to a file?
> 
> On Sat, Aug 8, 2015 at 6:31 AM, William Blevins  > wrote:
> 
> 
> On Sat, Aug 8, 2015 at 9:14 AM, Alexandre Feblot  > wrote:
> Hi,
> would have this been available, I indeed would already have used scons 
> --envdump=CXXFLAGS,CFLAGS,ENV.PATH A.o
> 
> 
> When I thought about the feature, I also thought the case 2 was more useful, 
> thank you for your feedback.  I can do both if we decided that printing the 
> whole environment object is ever useful, but lean code bases make for 
> maintainable code bases :)
>  
> --
> Alexandre Feblot
> 
>> Le 8 août 2015 à 15:04, William Blevins > > a écrit :
>> 
>> I guess I should be a bit more explicit about what I am trying to do.
>> 
>> Example:
>> A.cpp
>> SConstruct -> "Program( 'exe', Glob( '*.cpp' ) )"
>> 
>> My goal original goal was to be able to print environment objects from the 
>> command-line without having to modify code:
>> 1. As written: [Example: "scons --debug=envdump A.o" would print the build 
>> environment object assigned to "A.o" ].
>> 2. Afterthought on usability: [Example: "scons --envdump=LIBS A.o" would 
>> print the variable LIBS from the build environment assigned to "A.o"].
>> 2.1 Since environment objects are rather large, maybe printing just a single 
>> value from the environment object would be more readable and/or desired on a 
>> regular basis.
>> 
>> The supplied patch works for Case 1, but I am having a hard time getting 
>> only the targets on the command-line.  Currently, the patch prints the 
>> environment for all targets on the command-line, plus all their dependencies 
>> (as long as they have build environments) and I am hoping to not print their 
>> dependencies.
>> 
>> [Example: "scons --debug=envdump A.o" would print the environment for target 
>> "A.o" but not "A.cpp" or "/usr/bin/g++" because they don't have a build 
>> environment.]
>> 
>> [Example: "scons --debug=envdump exe" would print the environment for target 
>> "exe" plus "A.o" because it's in the target list (as a dependency of "exe")]
>> 
>> If I can figure out a clean way to get only the targets on the command-line, 
>> then that makes the most sense.  The real question is do we want Case 1, 
>> Case 2,or both capabilities?
>> 
>> V/R,
>> William
>> 
>> 
>> 
>> 
>> 
>> On Sat, Aug 8, 2015 at 3:42 AM, Roberto De Vecchi 
>> mailto:roberto.devec...@vi-grade.com>> wrote:
>> William,
>> 
>> from my experience using varname as a filter to limit the output will not 
>> help much in big trees where my cloned env are assigned to vars with the 
>> same name.
>> 
>> I would find very useful having the env dump limited to the target node 
>> specified on the command line: is this already supported by your proposal?
>> 
>> Roberto
>> 
>> --- Messaggio Originale ---
>> Da:  William Blevins mailto:wblevins...@gmail.com>>
>> Data:08 Agosto 2015 07:22:12
>> Oggetto: [Scons-dev] Patch for potential new debug option
>> A:   SCons developer list mailto:scons-dev@scons.org>>
>> 
>>> Here is a patch for dumping build environments via the command-line.
>>> 
>>> I couldn't ever figure out a good way to get only explicitly lister targets 
>>> (non-default commandline targets).  It will essentially print the 
>>> node.get_env().Dump() for all targets with a build_env defined.
>>> 
>>> I could potentially change it from "--debug=envdump" to something like 
>>> "--envdump=" so that it could print a particular variable rather 
>>> than the whole env.
>>> 
>>> Does this interest anyone or waste of chars?
>>> 
>>> diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
>>> --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
>>> +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
>>> @@ -391,6 +391,21 @@
>>>  def prepare(self):
>>>  pass
>>>  
>>> +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
>>> +"""SCons task for --debug=envdump.  Prints env dump for 
>>> BUILD_TARGETS."""
>>> +def prepare(self):
>>> +pass
>>> +
>>> +def execute(self):
>>> +for target in self.targets:
>>> +if target.get_build_env():
>>> +print 'Environment dump for target: ' + str(target)
>>> +print target.get_env().Dump()
>>> +
>>> +def executed(self):
>>> +pass
>>> +
>>> +
>>>  class QuestionTask(SCons.Taskmaster.AlwaysTask):
>>>  """An SCons task for the -q (question) option."""
>>>  def prepare(self):
>>> @@ -657,6 +672,7 @@
>>>  if "memory" in debug_values:
>>>  memory_stats.enable(sys.stdout)
>>>  print_objects = ("objects" in debug_values)
>>> +options.debug_envdump = ( "envdump" in debug_values )
>>>  if print_objects:
>>>  SCons.Debug.track_instances = True
>>

Re: [Scons-dev] Patch for potential new debug option

[William Blevins]

On Sat, Aug 8, 2015 at 11:38 AM, Bill Deegan 
wrote:

> Perhaps an option to direct this output to a file?
>

I assume that it can just be piped to a file, but maybe I don't understand
your question.


>
> On Sat, Aug 8, 2015 at 6:31 AM, William Blevins 
> wrote:
>
>>
>>
>> On Sat, Aug 8, 2015 at 9:14 AM, Alexandre Feblot 
>> wrote:
>>
>>> Hi,
>>> would have this been available, I indeed would already have used scons
>>> --envdump=CXXFLAGS,CFLAGS,ENV.PATH A.o
>>>
>>>
>> When I thought about the feature, I also thought the case 2 was more
>> useful, thank you for your feedback.  I can do both if we decided that
>> printing the whole environment object is ever useful, but lean code bases
>> make for maintainable code bases :)
>>
>>
>>> *--*
>>> Alexandre Feblot
>>>
>>> Le 8 août 2015 à 15:04, William Blevins  a écrit
>>> :
>>>
>>> I guess I should be a bit more explicit about what I am trying to do.
>>>
>>> Example:
>>> A.cpp
>>> SConstruct -> "Program( 'exe', Glob( '*.cpp' ) )"
>>>
>>> My goal original goal was to be able to print environment objects from
>>> the command-line without having to modify code:
>>> 1. As written: [Example: "scons --debug=envdump A.o" would print the
>>> build environment object assigned to "A.o" ].
>>> 2. Afterthought on usability: [Example: "scons --envdump=LIBS A.o" would
>>> print the variable LIBS from the build environment assigned to "A.o"].
>>> 2.1 Since environment objects are rather large, maybe printing just a
>>> single value from the environment object would be more readable and/or
>>> desired on a regular basis.
>>>
>>> The supplied patch works for Case 1, but I am having a hard time getting
>>> only the targets on the command-line.  Currently, the patch prints the
>>> environment for all targets on the command-line, plus all their
>>> dependencies (as long as they have build environments) and I am hoping to
>>> not print their dependencies.
>>>
>>> [Example: "scons --debug=envdump A.o" would print the environment for
>>> target "A.o" but not "A.cpp" or "/usr/bin/g++" because they don't have a
>>> build environment.]
>>>
>>> [Example: "scons --debug=envdump exe" would print the environment for
>>> target "exe" plus "A.o" because it's in the target list (as a dependency of
>>> "exe")]
>>>
>>> If I can figure out a clean way to get only the targets on the
>>> command-line, then that makes the most sense.  The real question is do we
>>> want Case 1, Case 2,or both capabilities?
>>>
>>> V/R,
>>> William
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Aug 8, 2015 at 3:42 AM, Roberto De Vecchi <
>>> roberto.devec...@vi-grade.com> wrote:
>>>
 William,

 from my experience using varname as a filter to limit the output will
 not help much in big trees where my cloned env are assigned to vars with
 the same name.

 I would find very useful having the env dump limited to the target node
 specified on the command line: is this already supported by your proposal?

 Roberto
 --- Messaggio Originale --- *Da: * William Blevins <
 wblevins...@gmail.com> *Data: * 08 Agosto 2015 07:22:12 *Oggetto: * 
 [Scons-dev]
 Patch for potential new debug option *A: * SCons developer list <
 scons-dev@scons.org>

 Here is a patch for dumping build environments via the command-line.
>
> I couldn't ever figure out a good way to get only explicitly lister
> targets (non-default commandline targets).  It will essentially print the
> node.get_env().Dump() for all targets with a build_env defined.
>
> I could potentially change it from "--debug=envdump" to something like
> "--envdump=" so that it could print a particular variable rather
> than the whole env.
>
> Does this interest anyone or waste of chars?
>
> diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
>> --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015
>> -0400
>> +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015
>> -0400
>> @@ -391,6 +391,21 @@
>>  def prepare(self):
>>  pass
>>
>> +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
>> +"""SCons task for --debug=envdump.  Prints env dump for
>> BUILD_TARGETS."""
>> +def prepare(self):
>> +pass
>> +
>> +def execute(self):
>> +for target in self.targets:
>> +if target.get_build_env():
>> +print 'Environment dump for target: ' + str(target)
>> +print target.get_env().Dump()
>> +
>> +def executed(self):
>> +pass
>> +
>> +
>>  class QuestionTask(SCons.Taskmaster.AlwaysTask):
>>  """An SCons task for the -q (question) option."""
>>  def prepare(self):
>> @@ -657,6 +672,7 @@
>>  if "memory" in debug_values:
>>  memory_stats.enable(sys.stdout)
>>  print_objects = ("objects" in debug_values)
>> +options.debug_envdump = ( "en

Re: [Scons-dev] Patch for potential new debug option

[Alexandre Feblot]

Yes, that’s what I meant. I wouldn't feel the need for a specific option when I 
can just do
scons --envdump=xx > file.txt

--
Alexandre Feblot

> Le 8 août 2015 à 19:01, William Blevins  a écrit :
> 
> 
> 
> On Sat, Aug 8, 2015 at 11:38 AM, Bill Deegan  > wrote:
> Perhaps an option to direct this output to a file?
> 
> I assume that it can just be piped to a file, but maybe I don't understand 
> your question.
>  
> 
> On Sat, Aug 8, 2015 at 6:31 AM, William Blevins  > wrote:
> 
> 
> On Sat, Aug 8, 2015 at 9:14 AM, Alexandre Feblot  > wrote:
> Hi,
> would have this been available, I indeed would already have used scons 
> --envdump=CXXFLAGS,CFLAGS,ENV.PATH A.o
> 
> 
> When I thought about the feature, I also thought the case 2 was more useful, 
> thank you for your feedback.  I can do both if we decided that printing the 
> whole environment object is ever useful, but lean code bases make for 
> maintainable code bases :)
>  
> --
> Alexandre Feblot
> 
>> Le 8 août 2015 à 15:04, William Blevins > > a écrit :
>> 
>> I guess I should be a bit more explicit about what I am trying to do.
>> 
>> Example:
>> A.cpp
>> SConstruct -> "Program( 'exe', Glob( '*.cpp' ) )"
>> 
>> My goal original goal was to be able to print environment objects from the 
>> command-line without having to modify code:
>> 1. As written: [Example: "scons --debug=envdump A.o" would print the build 
>> environment object assigned to "A.o" ].
>> 2. Afterthought on usability: [Example: "scons --envdump=LIBS A.o" would 
>> print the variable LIBS from the build environment assigned to "A.o"].
>> 2.1 Since environment objects are rather large, maybe printing just a single 
>> value from the environment object would be more readable and/or desired on a 
>> regular basis.
>> 
>> The supplied patch works for Case 1, but I am having a hard time getting 
>> only the targets on the command-line.  Currently, the patch prints the 
>> environment for all targets on the command-line, plus all their dependencies 
>> (as long as they have build environments) and I am hoping to not print their 
>> dependencies.
>> 
>> [Example: "scons --debug=envdump A.o" would print the environment for target 
>> "A.o" but not "A.cpp" or "/usr/bin/g++" because they don't have a build 
>> environment.]
>> 
>> [Example: "scons --debug=envdump exe" would print the environment for target 
>> "exe" plus "A.o" because it's in the target list (as a dependency of "exe")]
>> 
>> If I can figure out a clean way to get only the targets on the command-line, 
>> then that makes the most sense.  The real question is do we want Case 1, 
>> Case 2,or both capabilities?
>> 
>> V/R,
>> William
>> 
>> 
>> 
>> 
>> 
>> On Sat, Aug 8, 2015 at 3:42 AM, Roberto De Vecchi 
>> mailto:roberto.devec...@vi-grade.com>> wrote:
>> William,
>> 
>> from my experience using varname as a filter to limit the output will not 
>> help much in big trees where my cloned env are assigned to vars with the 
>> same name.
>> 
>> I would find very useful having the env dump limited to the target node 
>> specified on the command line: is this already supported by your proposal?
>> 
>> Roberto 
>> 
>> --- Messaggio Originale ---
>> Da:  William Blevins mailto:wblevins...@gmail.com>>
>> Data:08 Agosto 2015 07:22:12
>> Oggetto: [Scons-dev] Patch for potential new debug option
>> A:   SCons developer list mailto:scons-dev@scons.org>>
>> 
>>> Here is a patch for dumping build environments via the command-line.
>>> 
>>> I couldn't ever figure out a good way to get only explicitly lister targets 
>>> (non-default commandline targets).  It will essentially print the 
>>> node.get_env().Dump() for all targets with a build_env defined.
>>> 
>>> I could potentially change it from "--debug=envdump" to something like 
>>> "--envdump=" so that it could print a particular variable rather 
>>> than the whole env.
>>> 
>>> Does this interest anyone or waste of chars?
>>> 
>>> diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
>>> --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
>>> +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
>>> @@ -391,6 +391,21 @@
>>>  def prepare(self):
>>>  pass
>>>  
>>> +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
>>> +"""SCons task for --debug=envdump.  Prints env dump for 
>>> BUILD_TARGETS."""
>>> +def prepare(self):
>>> +pass
>>> +
>>> +def execute(self):
>>> +for target in self.targets:
>>> +if target.get_build_env():
>>> +print 'Environment dump for target: ' + str(target)
>>> +print target.get_env().Dump()
>>> +
>>> +def executed(self):
>>> +pass
>>> +
>>> +
>>>  class QuestionTask(SCons.Taskmaster.AlwaysTask):
>>>  """An SCons task for the -q (question) option."""
>>>  def prepare(self):
>>> @@ -657,6 +672

Re: [Scons-dev] Patch for potential new debug option

[Roberto De Vecchi]

William

Now I got your idea! Printing a subset of the env is a nice to have option but 
I find more value in the env dump capability than in the reduced output ( I 
have several cystom builders that dumps the env they are called from with an 
option: having a standard capability for this would be very welcome)

Making the story short I would like to see the new debug option included, but I 
 don't strictly need the variable filtering.

About the node logic for  selecting the nodes for which printing the 
environment, looks like we aee on the same page

Cheers
Roberto

--- Messaggio Originale ---
Da: William Blevins 
Data:   08 Agosto 2015 15:31:37
Oggetto:Re: [Scons-dev] Patch for potential new debug option
A:  SCons developer list 



On Sat, Aug 8, 2015 at 9:14 AM, Alexandre Feblot 
mailto:alexan...@feblot.fr>> wrote:
Hi,
would have this been available, I indeed would already have used scons 
--envdump=CXXFLAGS,CFLAGS,ENV.PATH A.o


When I thought about the feature, I also thought the case 2 was more useful, 
thank you for your feedback.  I can do both if we decided that printing the 
whole environment object is ever useful, but lean code bases make for 
maintainable code bases :)

--
Alexandre Feblot

Le 8 août 2015 à 15:04, William Blevins 
mailto:wblevins...@gmail.com>> a écrit :

I guess I should be a bit more explicit about what I am trying to do.

Example:
A.cpp
SConstruct -> "Program( 'exe', Glob( '*.cpp' ) )"

My goal original goal was to be able to print environment objects from the 
command-line without having to modify code:
1. As written: [Example: "scons --debug=envdump A.o" would print the build 
environment object assigned to "A.o" ].
2. Afterthought on usability: [Example: "scons --envdump=LIBS A.o" would print 
the variable LIBS from the build environment assigned to "A.o"].
2.1 Since environment objects are rather large, maybe printing just a single 
value from the environment object would be more readable and/or desired on a 
regular basis.

The supplied patch works for Case 1, but I am having a hard time getting only 
the targets on the command-line.  Currently, the patch prints the environment 
for all targets on the command-line, plus all their dependencies (as long as 
they have build environments) and I am hoping to not print their dependencies.

[Example: "scons --debug=envdump A.o" would print the environment for target 
"A.o" but not "A.cpp" or "/usr/bin/g++" because they don't have a build 
environment.]

[Example: "scons --debug=envdump exe" would print the environment for target 
"exe" plus "A.o" because it's in the target list (as a dependency of "exe")]

If I can figure out a clean way to get only the targets on the command-line, 
then that makes the most sense.  The real question is do we want Case 1, Case 
2,or both capabilities?

V/R,
William





On Sat, Aug 8, 2015 at 3:42 AM, Roberto De Vecchi 
mailto:roberto.devec...@vi-grade.com>> wrote:

William,

from my experience using varname as a filter to limit the output will not help 
much in big trees where my cloned env are assigned to vars with the same name.

I would find very useful having the env dump limited to the target node 
specified on the command line: is this already supported by your proposal?

Roberto

--- Messaggio Originale ---
Da: William Blevins mailto:wblevins...@gmail.com>>
Data:   08 Agosto 2015 07:22:12
Oggetto:[Scons-dev] Patch for potential new debug option
A:  SCons developer list mailto:scons-dev@scons.org>>

Here is a patch for dumping build environments via the command-line.

I couldn't ever figure out a good way to get only explicitly lister targets 
(non-default commandline targets).  It will essentially print the 
node.get_env().Dump() for all targets with a build_env defined.

I could potentially change it from "--debug=envdump" to something like 
"--envdump=" so that it could print a particular variable rather than 
the whole env.

Does this interest anyone or waste of chars?

diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
--- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
+++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
@@ -391,6 +391,21 @@
 def prepare(self):
 pass

+class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
+"""SCons task for --debug=envdump.  Prints env dump for BUILD_TARGETS."""
+def prepare(self):
+pass
+
+def execute(self):
+for target in self.targets:
+if target.get_build_env():
+print 'Environment dump for target: ' + str(target)
+print target.get_env().Dump()
+
+def executed(self):
+pass
+
+
 class QuestionTask(SCons.Taskmaster.AlwaysTask):
 """An SCons task for the -q (question) option."""
 def prepare(self):
@@ -657,6 +672,7 @@
 if "memory" in debug_values:
 memory_stats.enable(sys.stdout)
 print_objects = ("objects" in debug_values)
+options.debug_envdump = ( "envdum

Re: [Scons-dev] Patch for potential new debug option

[Jason Kenny]

My only concern with this feature is that it can dump a lot of data. Given 
Parts for example I would have lots of environment that would be dumped. such 
information is generally only useful when you can map a given environment to 
the correct file ( or part file in my case) or build actions (such as this is 
the environment for link foo.so or this was the environment for making hello.o).

Jason

From: William Blevins 
Sent: Saturday, August 8, 2015 12:22 AM
To: SCons developer list 
Subject: [Scons-dev] Patch for potential new debug option

Here is a patch for dumping build environments via the command-line.


I couldn't ever figure out a good way to get only explicitly lister targets 
(non-default commandline targets).  It will essentially print the 
node.get_env().Dump() for all targets with a build_env defined.


I could potentially change it from "--debug=envdump" to something like 
"--envdump=" so that it could print a particular variable rather than 
the whole env.


Does this interest anyone or waste of chars?


  diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
  --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
  +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
  @@ -391,6 +391,21 @@
   def prepare(self):
   pass
   
  +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
  +"""SCons task for --debug=envdump.  Prints env dump for BUILD_TARGETS."""
  +def prepare(self):
  +pass
  +
  +def execute(self):
  +for target in self.targets:
  +if target.get_build_env():
  +print 'Environment dump for target: ' + str(target)
  +print target.get_env().Dump()
  +
  +def executed(self):
  +pass
  +
  +
  class QuestionTask(SCons.Taskmaster.AlwaysTask):
   """An SCons task for the -q (question) option."""
   def prepare(self):
  @@ -657,6 +672,7 @@
   if "memory" in debug_values:
   memory_stats.enable(sys.stdout)
   print_objects = ("objects" in debug_values)
  +options.debug_envdump = ( "envdump" in debug_values )
   if print_objects:
   SCons.Debug.track_instances = True
   if "presub" in debug_values:
  @@ -1210,8 +1226,13 @@
   failure_message = "done building targets (errors occurred during 
build)."
   else:
   failure_message = "building terminated because of errors."
  +
  +if options.debug_envdump:
  +task_class = EnvDumpTask
  +
   if options.question:
   task_class = QuestionTask
  +
   try:
   if options.clean:
   task_class = CleanTask
  diff -r 682b8a7a51fb src/engine/SCons/Script/SConsOptions.py
  --- a/src/engine/SCons/Script/SConsOptions.pyMon Jun 29 15:37:44 2015 
-0400
  +++ b/src/engine/SCons/Script/SConsOptions.pyThu Aug 06 23:44:50 2015 
-0400
  @@ -673,7 +673,7 @@
   "tree"  : '; please use --tree=all instead',
   }
   
  -debug_options = ["count", "duplicate", "explain", "findlibs",
  +debug_options = ["count", "duplicate", "explain", "envdump", "findlibs",
"includes", "memoizer", "memory", "objects",
"pdb", "prepare", "presub", "stacktrace",
"time"]





V/R,

William 




___
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] Patch for potential new debug option

[William Blevins]

On Aug 8, 2015 1:47 PM, "Jason Kenny"  wrote:
>
> My only concern with this feature is that it can dump a lot of data.
Given Parts for example I would have lots of environment that would be
dumped. such information is generally only useful when you can map a given
environment to the correct file ( or part file in my case) or build actions
(such as this is the environment for link foo.so or this was the
environment for making hello.o).

I am mapping a target to its build env and outputting the env data.  Just
like your example :)
>
> Jason
>
> From: William Blevins
> Sent: Saturday, August 8, 2015 12:22 AM
> To: SCons developer list
> Subject: [Scons-dev] Patch for potential new debug option
>
> Here is a patch for dumping build environments via the command-line.
>
> I couldn't ever figure out a good way to get only explicitly lister
targets (non-default commandline targets).  It will essentially print the
node.get_env().Dump() for all targets with a build_env defined.
>
> I could potentially change it from "--debug=envdump" to something like
"--envdump=" so that it could print a particular variable rather
than the whole env.
>
> Does this interest anyone or waste of chars?
>
>> diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
>> --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
>> +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
>> @@ -391,6 +391,21 @@
>>  def prepare(self):
>>  pass
>>
>> +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
>> +"""SCons task for --debug=envdump.  Prints env dump for
BUILD_TARGETS."""
>> +def prepare(self):
>> +pass
>> +
>> +def execute(self):
>> +for target in self.targets:
>> +if target.get_build_env():
>> +print 'Environment dump for target: ' + str(target)
>> +print target.get_env().Dump()
>> +
>> +def executed(self):
>> +pass
>> +
>> +
>> class QuestionTask(SCons.Taskmaster.AlwaysTask):
>>  """An SCons task for the -q (question) option."""
>>  def prepare(self):
>> @@ -657,6 +672,7 @@
>>  if "memory" in debug_values:
>>  memory_stats.enable(sys.stdout)
>>  print_objects = ("objects" in debug_values)
>> +options.debug_envdump = ( "envdump" in debug_values )
>>  if print_objects:
>>  SCons.Debug.track_instances = True
>>  if "presub" in debug_values:
>> @@ -1210,8 +1226,13 @@
>>  failure_message = "done building targets (errors occurred
during build)."
>>  else:
>>  failure_message = "building terminated because of errors."
>> +
>> +if options.debug_envdump:
>> +task_class = EnvDumpTask
>> +
>>  if options.question:
>>  task_class = QuestionTask
>> +
>>  try:
>>  if options.clean:
>>  task_class = CleanTask
>> diff -r 682b8a7a51fb src/engine/SCons/Script/SConsOptions.py
>> --- a/src/engine/SCons/Script/SConsOptions.pyMon Jun 29 15:37:44
2015 -0400
>> +++ b/src/engine/SCons/Script/SConsOptions.pyThu Aug 06 23:44:50
2015 -0400
>> @@ -673,7 +673,7 @@
>>  "tree"  : '; please use --tree=all instead',
>>  }
>>
>> -debug_options = ["count", "duplicate", "explain", "findlibs",
>> +debug_options = ["count", "duplicate", "explain", "envdump",
"findlibs",
>>   "includes", "memoizer", "memory", "objects",
>>   "pdb", "prepare", "presub", "stacktrace",
>>   "time"]
>>
>
>
> V/R,
> William
>
> 
> ___
> 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 mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Patch for potential new debug option

[Bill Deegan]

If I run "scons --debug=dumpenv", won't it still do a build?
So I could get a lot of extra output if I just redirect stdout.

Does the output go to stdout or stderr?

-Bill

On Sat, Aug 8, 2015 at 11:28 AM, William Blevins 
wrote:

>
> On Aug 8, 2015 1:47 PM, "Jason Kenny"  wrote:
> >
> > My only concern with this feature is that it can dump a lot of data.
> Given Parts for example I would have lots of environment that would be
> dumped. such information is generally only useful when you can map a given
> environment to the correct file ( or part file in my case) or build actions
> (such as this is the environment for link foo.so or this was the
> environment for making hello.o).
>
> I am mapping a target to its build env and outputting the env data.  Just
> like your example :)
> >
> > Jason
> >
> > From: William Blevins
> > Sent: Saturday, August 8, 2015 12:22 AM
> > To: SCons developer list
> > Subject: [Scons-dev] Patch for potential new debug option
> >
> > Here is a patch for dumping build environments via the command-line.
> >
> > I couldn't ever figure out a good way to get only explicitly lister
> targets (non-default commandline targets).  It will essentially print the
> node.get_env().Dump() for all targets with a build_env defined.
> >
> > I could potentially change it from "--debug=envdump" to something like
> "--envdump=" so that it could print a particular variable rather
> than the whole env.
> >
> > Does this interest anyone or waste of chars?
> >
> >> diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
> >> --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
> >> +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
> >> @@ -391,6 +391,21 @@
> >>  def prepare(self):
> >>  pass
> >>
> >> +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
> >> +"""SCons task for --debug=envdump.  Prints env dump for
> BUILD_TARGETS."""
> >> +def prepare(self):
> >> +pass
> >> +
> >> +def execute(self):
> >> +for target in self.targets:
> >> +if target.get_build_env():
> >> +print 'Environment dump for target: ' + str(target)
> >> +print target.get_env().Dump()
> >> +
> >> +def executed(self):
> >> +pass
> >> +
> >> +
> >> class QuestionTask(SCons.Taskmaster.AlwaysTask):
> >>  """An SCons task for the -q (question) option."""
> >>  def prepare(self):
> >> @@ -657,6 +672,7 @@
> >>  if "memory" in debug_values:
> >>  memory_stats.enable(sys.stdout)
> >>  print_objects = ("objects" in debug_values)
> >> +options.debug_envdump = ( "envdump" in debug_values )
> >>  if print_objects:
> >>  SCons.Debug.track_instances = True
> >>  if "presub" in debug_values:
> >> @@ -1210,8 +1226,13 @@
> >>  failure_message = "done building targets (errors occurred
> during build)."
> >>  else:
> >>  failure_message = "building terminated because of errors."
> >> +
> >> +if options.debug_envdump:
> >> +task_class = EnvDumpTask
> >> +
> >>  if options.question:
> >>  task_class = QuestionTask
> >> +
> >>  try:
> >>  if options.clean:
> >>  task_class = CleanTask
> >> diff -r 682b8a7a51fb src/engine/SCons/Script/SConsOptions.py
> >> --- a/src/engine/SCons/Script/SConsOptions.pyMon Jun 29 15:37:44
> 2015 -0400
> >> +++ b/src/engine/SCons/Script/SConsOptions.pyThu Aug 06 23:44:50
> 2015 -0400
> >> @@ -673,7 +673,7 @@
> >>  "tree"  : '; please use --tree=all instead',
> >>  }
> >>
> >> -debug_options = ["count", "duplicate", "explain", "findlibs",
> >> +debug_options = ["count", "duplicate", "explain", "envdump",
> "findlibs",
> >>   "includes", "memoizer", "memory", "objects",
> >>   "pdb", "prepare", "presub", "stacktrace",
> >>   "time"]
> >>
> >
> >
> > V/R,
> > William
> >
> > 
> > ___
> > 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 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] Patch for potential new debug option

[William Blevins]

On Sat, Aug 8, 2015 at 5:48 PM, Bill Deegan 
wrote:

> If I run "scons --debug=dumpenv", won't it still do a build?
> So I could get a lot of extra output if I just redirect stdout.
>
> Does the output go to stdout or stderr?
>

The way the patch is written no.  It replaces the BuildTask, but since the
build task is unique it sorta depends on the order in which they are
specified... so there should probably be a check in that code to make sure
only one build task has been selected.


>
> -Bill
>
> On Sat, Aug 8, 2015 at 11:28 AM, William Blevins 
> wrote:
>
>>
>> On Aug 8, 2015 1:47 PM, "Jason Kenny"  wrote:
>> >
>> > My only concern with this feature is that it can dump a lot of data.
>> Given Parts for example I would have lots of environment that would be
>> dumped. such information is generally only useful when you can map a given
>> environment to the correct file ( or part file in my case) or build actions
>> (such as this is the environment for link foo.so or this was the
>> environment for making hello.o).
>>
>> I am mapping a target to its build env and outputting the env data.  Just
>> like your example :)
>> >
>> > Jason
>> >
>> > From: William Blevins
>> > Sent: Saturday, August 8, 2015 12:22 AM
>> > To: SCons developer list
>> > Subject: [Scons-dev] Patch for potential new debug option
>> >
>> > Here is a patch for dumping build environments via the command-line.
>> >
>> > I couldn't ever figure out a good way to get only explicitly lister
>> targets (non-default commandline targets).  It will essentially print the
>> node.get_env().Dump() for all targets with a build_env defined.
>> >
>> > I could potentially change it from "--debug=envdump" to something like
>> "--envdump=" so that it could print a particular variable rather
>> than the whole env.
>> >
>> > Does this interest anyone or waste of chars?
>> >
>> >> diff -r 682b8a7a51fb src/engine/SCons/Script/Main.py
>> >> --- a/src/engine/SCons/Script/Main.pyMon Jun 29 15:37:44 2015 -0400
>> >> +++ b/src/engine/SCons/Script/Main.pyThu Aug 06 23:44:50 2015 -0400
>> >> @@ -391,6 +391,21 @@
>> >>  def prepare(self):
>> >>  pass
>> >>
>> >> +class EnvDumpTask(SCons.Taskmaster.AlwaysTask):
>> >> +"""SCons task for --debug=envdump.  Prints env dump for
>> BUILD_TARGETS."""
>> >> +def prepare(self):
>> >> +pass
>> >> +
>> >> +def execute(self):
>> >> +for target in self.targets:
>> >> +if target.get_build_env():
>> >> +print 'Environment dump for target: ' + str(target)
>> >> +print target.get_env().Dump()
>> >> +
>> >> +def executed(self):
>> >> +pass
>> >> +
>> >> +
>> >> class QuestionTask(SCons.Taskmaster.AlwaysTask):
>> >>  """An SCons task for the -q (question) option."""
>> >>  def prepare(self):
>> >> @@ -657,6 +672,7 @@
>> >>  if "memory" in debug_values:
>> >>  memory_stats.enable(sys.stdout)
>> >>  print_objects = ("objects" in debug_values)
>> >> +options.debug_envdump = ( "envdump" in debug_values )
>> >>  if print_objects:
>> >>  SCons.Debug.track_instances = True
>> >>  if "presub" in debug_values:
>> >> @@ -1210,8 +1226,13 @@
>> >>  failure_message = "done building targets (errors occurred
>> during build)."
>> >>  else:
>> >>  failure_message = "building terminated because of errors."
>> >> +
>> >> +if options.debug_envdump:
>> >> +task_class = EnvDumpTask
>> >> +
>> >>  if options.question:
>> >>  task_class = QuestionTask
>> >> +
>> >>  try:
>> >>  if options.clean:
>> >>  task_class = CleanTask
>> >> diff -r 682b8a7a51fb src/engine/SCons/Script/SConsOptions.py
>> >> --- a/src/engine/SCons/Script/SConsOptions.pyMon Jun 29 15:37:44
>> 2015 -0400
>> >> +++ b/src/engine/SCons/Script/SConsOptions.pyThu Aug 06 23:44:50
>> 2015 -0400
>> >> @@ -673,7 +673,7 @@
>> >>  "tree"  : '; please use --tree=all instead',
>> >>  }
>> >>
>> >> -debug_options = ["count", "duplicate", "explain", "findlibs",
>> >> +debug_options = ["count", "duplicate", "explain", "envdump",
>> "findlibs",
>> >>   "includes", "memoizer", "memory", "objects",
>> >>   "pdb", "prepare", "presub", "stacktrace",
>> >>   "time"]
>> >>
>> >
>> >
>> > V/R,
>> > William
>> >
>> > 
>> > ___
>> > 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 mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Sco

Re: [Scons-dev] Cross-language support

[William Blevins]

I was rethinking the whole SCANNER_HINIT concept, and realized that its
unnecessary because what we are trying to accomplish can already be done
via "env.add_scanner( ,  )", so unless someone
objects, I plan to remove that bit of functionality.

V/R,
William

On Wed, Aug 5, 2015 at 8:37 PM, William Blevins 
wrote:

> Jason,
>
> That test is indeed expecting the behavior we a trying to eliminate.  I am
> curious as to why this happened previously with IDL, but not with other
> languages, but perhaps it doesn't matter.
>
> With the change to make Install non-recursive, my tests failures look like
> https://bitbucket.org/scons/scons/pull-requests/237/issue-2264-cross-language-scanner-support/diff#comment-8529830
> with only 3 tests failing.  The other two expect to be able to compile c++
> code from installed targets.  I'm not sure if this is a documented
> functionality of SCons, but it's scary because of how include paths would
> work in those cases.
>
> On a related note, if we change the Install scanner, then we may also need
> to write a test for calling "scons install" and expecting all dependencies
> to be built.  This case may or may not be already covered within the SCons
> test cases.
>
> V/R,
> William
>
> On Wed, Aug 5, 2015 at 6:25 PM, Jason Kenny  wrote:
>
>> Hi william,
>>
>> Trying to take a little time to code. I am looking at the IDL case you
>> talked about. I applied the non-reclusive scanner and test/IDL/IDLSUFFIXES.py
>> test fails because it fails to copy over the idl file when the .h file
>> changed. However from what I can tell this is the opposite behavior we
>> would want and in this case I really think, given the patch to not be
>> recursive on install builder is the correct thing we want to do. I think
>> this test should be changed to not want the .h file to cause a recopy. This
>> would match the same logic we would have with the CPPSUFFIX test.
>>
>> However after I am unclear about the test as is. I would think given what
>> I have done with IDL files in the past, that one would not want the copy
>> logic as it in this test as the installed files would fail to work as the
>> “dependent” .h files is not copied as well. Given this I think this might
>> have been a mistake in the original test logic that was not intended to
>> show that it is working or not.
>>
>> as a note given the fix for the install as it is... I still have these
>> failures:
>>
>> Failed the following 15 tests:
>> test\Batch\action-changed.py
>> test\IDL\IDLSUFFIXES.py
>> test\MSVS\vs-9.0-exec.py
>> test\Win32\mingw.py
>> test\exitfns.py
>> test\explain\basic.py
>> test\explain\save-info.py
>> test\implicit\IMPLICIT_COMMAND_DEPENDENCIES.py
>> test\import.py
>> test\long-lines\signature.py
>> test\scons-time\run\config\python.py
>> test\scons-time\run\option\python.py
>> test\sconsign\script\SConsignFile.py
>> test\sconsign\script\Signatures.py
>> test\sconsign\script\no-SConsignFile.py
>>
>> which just says given what is here D and C Suffix test are now passing
>> and the other tests at the moment seem to fail most for me in the default
>> branch of SCons ie I have these failures with the latest tip
>>
>> Failed the following 12 tests:
>> test\Batch\action-changed.py
>> test\MSVS\vs-9.0-exec.py
>> test\Win32\mingw.py
>> test\exitfns.py
>> test\implicit\IMPLICIT_COMMAND_DEPENDENCIES.py
>> test\import.py
>> test\long-lines\signature.py
>> test\scons-time\run\config\python.py
>> test\scons-time\run\option\python.py
>> test\sconsign\script\SConsignFile.py
>> test\sconsign\script\Signatures.py
>> test\sconsign\script\no-SConsignFile.py
>>
>> I have to look into what is happening.
>>
>> Jason
>>
>>
>>
>> *From:* Jason Kenny 
>> *Sent:* Wednesday, July 29, 2015 9:56 PM
>> *To:* SCons developer list 
>> *Subject:* Re: [Scons-dev] Cross-language support
>>
>> OK
>>
>> I think we agree case 4 is best. Let me look at the idl test case. I am
>> not sure what this would be an issue with the installer builder at the
>> moment.
>>
>> Jason
>>
>> *From:* William Blevins 
>> *Sent:* Wednesday, July 29, 2015 9:50 PM
>> *To:* SCons developer list 
>> *Subject:* Re: [Scons-dev] Cross-language support
>>
>>
>>
>> On Wed, Jul 29, 2015 at 10:05 PM, Jason Kenny  wrote:
>>
>>> Ya I see this...
>>>
>>> So I trying to take a little time tonight and figure out what happens..
>>> Could use some help.
>>>
>>> I currently looking at test/CPPSUFFIXES.py
>>>
>>> This fails at line 107. From what I can tell the test expects output of
>>>
>>> C:\Python27\python.exe mycc.py test1.o test1.c
>>>
>>> but instead we get
>>>
>>> C:\Python27\python.exe mycc.py test1.o test1.c
>>> Install file: "test1.c" as "test1_c"
>>> Install file: "test1.h" as "test1_h"
>>>
>>> This happens because foo.h was changed causing these files to be copied
>>

Re: [Scons-dev] Cross-language support

[Bill Deegan]

William,

That's fine if you want to make an environment per file you're evaluating.
If you have the SCANNER_HINT, then you can add it to a builder (which
creates and OverrideEnvironment(If I remember correctly)) and simplifies
the SConstruct/script

-Bill

On Sat, Aug 8, 2015 at 7:29 PM, William Blevins 
wrote:

> I was rethinking the whole SCANNER_HINIT concept, and realized that its
> unnecessary because what we are trying to accomplish can already be done
> via "env.add_scanner( ,  )", so unless someone
> objects, I plan to remove that bit of functionality.
>
> V/R,
> William
>
> On Wed, Aug 5, 2015 at 8:37 PM, William Blevins 
> wrote:
>
>> Jason,
>>
>> That test is indeed expecting the behavior we a trying to eliminate.  I
>> am curious as to why this happened previously with IDL, but not with other
>> languages, but perhaps it doesn't matter.
>>
>> With the change to make Install non-recursive, my tests failures look
>> like
>> https://bitbucket.org/scons/scons/pull-requests/237/issue-2264-cross-language-scanner-support/diff#comment-8529830
>> with only 3 tests failing.  The other two expect to be able to compile c++
>> code from installed targets.  I'm not sure if this is a documented
>> functionality of SCons, but it's scary because of how include paths would
>> work in those cases.
>>
>> On a related note, if we change the Install scanner, then we may also
>> need to write a test for calling "scons install" and expecting all
>> dependencies to be built.  This case may or may not be already covered
>> within the SCons test cases.
>>
>> V/R,
>> William
>>
>> On Wed, Aug 5, 2015 at 6:25 PM, Jason Kenny  wrote:
>>
>>> Hi william,
>>>
>>> Trying to take a little time to code. I am looking at the IDL case you
>>> talked about. I applied the non-reclusive scanner and 
>>> test/IDL/IDLSUFFIXES.py
>>> test fails because it fails to copy over the idl file when the .h file
>>> changed. However from what I can tell this is the opposite behavior we
>>> would want and in this case I really think, given the patch to not be
>>> recursive on install builder is the correct thing we want to do. I think
>>> this test should be changed to not want the .h file to cause a recopy. This
>>> would match the same logic we would have with the CPPSUFFIX test.
>>>
>>> However after I am unclear about the test as is. I would think given
>>> what I have done with IDL files in the past, that one would not want the
>>> copy logic as it in this test as the installed files would fail to work as
>>> the “dependent” .h files is not copied as well. Given this I think this
>>> might have been a mistake in the original test logic that was not intended
>>> to show that it is working or not.
>>>
>>> as a note given the fix for the install as it is... I still have these
>>> failures:
>>>
>>> Failed the following 15 tests:
>>> test\Batch\action-changed.py
>>> test\IDL\IDLSUFFIXES.py
>>> test\MSVS\vs-9.0-exec.py
>>> test\Win32\mingw.py
>>> test\exitfns.py
>>> test\explain\basic.py
>>> test\explain\save-info.py
>>> test\implicit\IMPLICIT_COMMAND_DEPENDENCIES.py
>>> test\import.py
>>> test\long-lines\signature.py
>>> test\scons-time\run\config\python.py
>>> test\scons-time\run\option\python.py
>>> test\sconsign\script\SConsignFile.py
>>> test\sconsign\script\Signatures.py
>>> test\sconsign\script\no-SConsignFile.py
>>>
>>> which just says given what is here D and C Suffix test are now passing
>>> and the other tests at the moment seem to fail most for me in the default
>>> branch of SCons ie I have these failures with the latest tip
>>>
>>> Failed the following 12 tests:
>>> test\Batch\action-changed.py
>>> test\MSVS\vs-9.0-exec.py
>>> test\Win32\mingw.py
>>> test\exitfns.py
>>> test\implicit\IMPLICIT_COMMAND_DEPENDENCIES.py
>>> test\import.py
>>> test\long-lines\signature.py
>>> test\scons-time\run\config\python.py
>>> test\scons-time\run\option\python.py
>>> test\sconsign\script\SConsignFile.py
>>> test\sconsign\script\Signatures.py
>>> test\sconsign\script\no-SConsignFile.py
>>>
>>> I have to look into what is happening.
>>>
>>> Jason
>>>
>>>
>>>
>>> *From:* Jason Kenny 
>>> *Sent:* Wednesday, July 29, 2015 9:56 PM
>>> *To:* SCons developer list 
>>> *Subject:* Re: [Scons-dev] Cross-language support
>>>
>>> OK
>>>
>>> I think we agree case 4 is best. Let me look at the idl test case. I am
>>> not sure what this would be an issue with the installer builder at the
>>> moment.
>>>
>>> Jason
>>>
>>> *From:* William Blevins 
>>> *Sent:* Wednesday, July 29, 2015 9:50 PM
>>> *To:* SCons developer list 
>>> *Subject:* Re: [Scons-dev] Cross-language support
>>>
>>>
>>>
>>> On Wed, Jul 29, 2015 at 10:05 PM, Jason Kenny 
>>> wrote:
>>>
 Ya I see this...

 So I trying to take a little time tonight and figure out what happens..
>