[Scons-dev] Your advice wanted on issue #1742: TryLink() is too successful sometimes...

[Tom Tanner (BLOOMBERG/ LONDON)]

I intensely dislike the 'make compatibility' of @ and - at the start of a command line causing it to do strange things.

It only applies to command line builds (and offhand I'm not sure without looking if these apply to arrays or just single strings), and if you're calling a python function you have to do something different. 

It's not entirely clear what happens if you have both - and @.

I'd really like a better way of specifying an action object either doesn't echo or ignores the error return (i think you could use the exitsatfunc for the latter, and maybe supply a documented 'always succeed as per the man page, but it's very well hidden), then we could deprecate this doozy.

That is to say, firstly is this:
Action([['-', 'cc', '-c', '-DWHITE SPACE', '-o', '$TARGET', '$SOURCES']])
equivalent to this:
Action('-cc -c -DWHITE SPACE -o $TARGET $SOURCES')

And in any case, it should be replaced by this:
Action('cc -c -DWHITE SPACE -o $TARGET $SOURCES', exitsatfunc = IgnoreError)
or even
Action('cc -c -DWHITE SPACE -o $TARGET $SOURCES', ignoreErrors = True) cos that is a lot more intuitive


Similarly, there should be a supressOutput flag (False if not specified, obviously).

Me, I'm waiting for someone to decide they should have a program whose name starts with @. 

The only way I know of catching it for sure is to use anv.AllowSubstExceptions(), but I'm paranoid.

But if you really want to fix that issue, deprecate '-' and '@' at the start of a command line, issue warnings, have a build option to (a) make the warnigns errors and/or (b)  suppress the special treatment, and make it easier and more intuitive to set up the required behaviour in the action function.

----- Original Message -----
From: dl9obn at darc.de
To: scons-dev at scons.org
At: May 20 2014 22:58:57

Hi there,

I'd like to get a second opinion (and third, and...) on the following 
problem:

I'm currently debugging issue #1742 and found out why the TryLink() 
sometimes returns successful, although this shouldn't happen. In the 
given example

   env = Environment(tools = ['g++', 'gnulink'])
   printCC(env)
   config = env.Configure()
   print 'C++ toolchain', config.TryLink('int foo() {}', '.c')
   config.Finish()

the variable $CC is empty, since the gcc tool doesn't get loaded. But a 
"*.c" file gets compiled, so the smart_link() function returns "$CC" for 
"$SMARTLINK", which is also the definition of "$LINK".
Finally, the command

   $LINK -o $TARGET $LINKFLAGS $__RPATH $SOURCES $_LIBDIRFLAGS $_LIBFLAGS

evaluates to

   -o ....

, and the leading "-" suppresses the actual return value of the spawn().


So we know what happens, but should we do something about it? Does this 
need to get documented somewhere, or would it be good to catch it 
somehow? I don't have a clear idea for the latter option...your comments 
are welcome.

Best regards,

Dirk

_______________________________________________
Scons-dev mailing list
Scons-dev at scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140521/47ff993c/attachment.html>