[Scons-dev] Scons 2.3.2 regression, D tool...

[Russel Winder]

On Sat, 2014-08-09 at 15:28 +0200, Dirk Bächle wrote:
[…]
> Can you do the following test please:
> 
> - In the D tools of your local installation, change the names of the 
> executables that get detected...such that they can't possibly be found 
> in the system (in exists() rename dmd -> foodmd, ...).

Given everything is Debian package installed this means removing the
package, I do not tinker with files in /usr/bin! :-)

I think I am going to have to find a way of using Docker or equivalent
to create new Linux systems without having a full virtual machine.

> - Then create a simple SConstruct:
> 
>    env = Environment()
>    print env.Dump()
> 
> - Run through SCons, and observe that the Environment has D variables (= 
> dmd.py Tool got loaded anyway)

I'll take OPs and your word for it.  Actually I just tried it on my
server and yes this is true. But… all the Fortran symbols are brought in
as well and I have no Fortran compiler on that machine. So everything
being said about D is true for Fortran as well.
 
> This happens, because the line
> 
>       d_compiler = FindTool(d_compilers, env) or d_compilers[0]
> 
> adds "dmd" to the tool list anyway. In the "default" Tool's generate() 
> method, the returned list is simply loaded without checking the 
> existence of tools again.

Indeed as OP said. However all the Fortran tools are being brought in as
well even though I have no Fortran compiler, why is this happening and
should it be fixed?


> It is okay, and wanted, for as many Tools to get loaded by default...as 
> long as their variables don't clash. The "STATIC_AND_SHARED" variable is 
> only set by:
> 
> - C/C++ compilers (where only the first match gets selected, based on 
> the current platform) and
> - masm (only under Windows, where it sets the same value as a Windows 
> C/C++ compiler -> no clash)
> 
> Only the D tools are forcing it back to "0", and this is not compatible 
> with the setting that the "msvc" and "mingw" Tool make. This is the main 
> culprit, and we either have to remove the explicit setting of 
> "STATIC_AND_SHARED" from the D tools (relying on the C/C++ tools to do 
> the right thing, or, if they really need the setting under Windows, we 
> have to remove the D tools from the "default" toolchain.
> 
> So, is "STATIC_AND_SHARED=0" *required* for the D tools to work properly 
> under Windows?

OK, this seems to be the real point here, the rest is, forgive me,
flummery. The D tool should behave in the same way the Fortran tool does
regarding this sort of thing and it seems Fortran does not touch this.

Given that SCons is a C/C++ build framework with other stuff bolted on,
then clearly the C/C++ stuff is special and has priority. I can see it
was an error of mine to force a change of this symbol in what appears to
be a "by default" situation.

So I suggest the way forward is to remove the setting of this from the D
tools and forget it for now — the reason I original set this a couple of
years ago was due to a (mis-)feature of D that is changing very rapidly
just now. How this is treated for D needs reviewing in a few months time
when the next GDC and LDC compilers get formally released.

Then what we need is a test for this that shows a fail on Windows
without a D compiler as well as with — and the usual battery of tests on
Linux and OSX with and without. It appears only to be a Windows problem
and I cannot do anything requiring Windows.

I have made the "remove the six lines" change in my Mercurial repository
and the D tests all run as expected (*), I am just running the full of
tests set now. I can make a pull request but without running a test
highlighting the problem (which we don't actually have just now) run on
a Windows machine (which I don't have) this doesn't mean very much. :-(


(*) It still worries me that the tool for checking the presence of an
executable for use in a SCons test uses the user PATH but the execution
of the test uses the default PATH only. Thus there are test fails which
can never pass on my machine even though everything works fine.


-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140809/4aa237aa/attachment-0001.pgp>