Re: [Scons-dev] Your advice wanted on issue #1742: TryLink() is too successful sometimes...
On 21.05.2014 00:53, Gary Oberbrunner wrote: That's an insidious combination of problems there. I don't think much is expected to work if only g++ is defined and not gcc, but it would be nice if it didn't fail this badly. Of course the mythical toolchain revamp will prevent this kind of thing or at least make it harder. But I don't know how much can be done for this particular case. I'm more worried about the general case...this can happen in other contexts too. The basic problem is that we use - to signal a command to be ignored, and it's the option char at the same time. This makes the underlying grammar for the current command string ambiguous. One option would be to do the check on leading - and @ on the unexpanded string only (before the subst). But then a user couldn't switch on/off these via a leading variable anymore...like in ($IGNORE$LINK ...). It would always have to get hardcoded into the Action command, or you'd have to use a generator function. Maybe that's a way out, without sacrificing too much flexibility. Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
[Scons-dev] Your advice wanted on issue #1742: TryLink() is too successful sometimes...
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@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Your advice wanted on issue #1742: TryLink() is too successful sometimes...
On 20.05.2014 23:58, Dirk Bächle wrote: [...] I'm currently debugging issue #1742 and found out why the TryLink() sometimes returns successful, although this shouldn't happen. In Sorry, just noticed this right now (better late than never ;) )...it should be either ...sometimes returns success or ...sometimes returns successfully or ...sometimes is successful. Correct? Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Your advice wanted on issue #1742: TryLink() is too successful sometimes...
That's an insidious combination of problems there. I don't think much is
expected to work if only g++ is defined and not gcc, but it would be nice
if it didn't fail this badly. Of course the mythical toolchain revamp will
prevent this kind of thing or at least make it harder. But I don't know how
much can be done for this particular case.
--
Gary Oberbrunner
(sent from my Android)
On May 20, 2014 5:58 PM, Dirk Bächle tshor...@gmx.de wrote:
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@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
