[Scons-users] Silent rules for SCons

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14.07.2012 9:25, William Deegan wrote:

> On Jul 13, 2012, at 2:30 PM, Kenny, Jason L wrote:

>> On Jul 13, 2012, at 4:20 PM, William Deegan wrote:

>>> On Jul 13, 2012, at 1:54 PM, LRN wrote:

>>>> Does anyone have the intention to implement something like

>>>> "silent rules" (as in autotools) or "shave" (previously used

>>>> in GStreamer, and probably kbuild?) for SCons?

>>>> 

>>>> AFAIU, it requires all tools (or things that print output for

>>>> tools, if tools aren't printing output themselves) to have

>>>> alternative mode of operation, in which they dramatically

>>>> alter their output.

>>> All you need to do is walk all the *COMSTR's in the env to

>>> alter what SCONS outputs, and then all the *COM to redirect

>>> somewhere other than stdout ?

>> I think I know what LRN is talking about. As I have more complex

>> redirection rules in Parts and LRN was asking me to clean up some

>> stuff in Parts related to this.

>> 

>> The issue is that a tools can define an action string like: 

>> "Doing this work" Or if nothing is defined SCons takes the

>> command it is going to run and makes it the string. What is being

>> asked for is that -s is not really silent, but less chatty. Allow

>> Actions to define a long string and a short string to be

>> displayed so when an options like -s ( or similar) is used it

>> would output stuff like:

>> 

>> [cxx] foo.cpp

>> 

>> Instead of the

>> 

>> G++ -02 -I... <lots of stuff>

>> 

>> That it currently does. I have a some code that can go into SCons

>> to do this.. but I am redoing it to make it better ( after the

>> last few year of experience.. I found a few way to make this

>> better) The main thing is making a setup to allow different

>> strings for actions to be used depending on how chatty we want

>> the system to be.

> 

> 

> Is that different than changing the *COMSTR's ?

1) I grepped SCons source, and i can't find where COMSTRs are defined
(only where they are used).
2) Walking through COMs of an environment after they've been defined
is perilous. Only the tool itself knows certain things that are needed
for silent rules, user-defined SConscript should not mess with that,
only be able switch the mode on and off.
3) (not your problem, but still) I'm using Parts, which means that i
can't change the environment in SConstruct (because it doesn't exist,
and if i create it, it won't be used by parts), and can't change the
environment in a part, because that would only affect that environment
in that part.

As for mechanics, here's what i know about autotools silent-rules:
1) automake knows (it's hardcoded) that it can silence libtool by
giving it "--silent" argument when silent mode is enabled
2) Other commands are actually silent by default (gcc only outputs
warnings and errors to the console; ld only outputs one line in normal
mode, and that has been fixed)
3) in silent mode makefile commands are prefixed by an at-sign ('@')
to prevent them from echoing themselves (there's a variable that
expands to '@' or empty string depending on the mode).
4) in silent mode each command is preceded by an @echo that outputs
the action label ("CC", "GEN", "CXX", "CCLD" etc) and the $@ (target
being built). This, again, is done via variable that expands to @echo
"  FOO  " $@; in silent mode and to nothing in normal mode.

And there are some trivialities not worth a mention (adding
- --enable/disable-silent-rules, the V variable etc).

The incantations of using '@' to silence echo and commands are
definitely unneeded with Python, you just print either the command
itself, or its placeholder (an action label and the target).

There's no need to redirect output, but there might be a need to
prepare arguments that shut up some verbose tools if their default
mode of operation is incompatible with silent-rules mode (which is
"don't speak unless you have something to say).

And builders should generally know which action labels to use, not the
user. Knowing the target, again, does not require special variables,
since builders are naturally aware of their target(s).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQAUlmAAoJEOs4Jb6SI2Cw9EUIAKDtOxK2C4ewTbyxn9RsHYz9
BiQ9C3hM0+jlUSyxmLmt60Ay7muH0y47oRCajfV9ttF+Yy26WkS3tqkuXsu8XkpF
wXKf80yWldHy/JA+Ko1DNaSj6mYw7IGtOWaPBaWr8Dh8ggxK8HMQWxSFaL7YcvTF
dSByDuBah4x/SiZb771b4kXwSSZN73zYwu1k3/ZvZEVdhs4awHa1wLg/YZ5GfIX4
IaIajdQmMmHtMxu4zvPT6U58hHXU0UEI5LRB3ZfkB/niUhlo+1uvl1weSSMHG1Ci
ZH+VAgPl1LM1mq/amuOsUhorbBWinDPNzp3HdKPaIuUU4YszbEIz94v+Wp9mrBA=
=tSk9
-----END PGP SIGNATURE-----