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

Sat Aug 9 08:23:12 EDT 2014

On Sat, 2014-08-09 at 01:12 +0300, anatoly techtonik wrote:
[…]
> There is an explicit check on "dmd" binary. What is "dmd" binary then?
> https://bitbucket.org/scons/scons/commits/b757fe34f9fe#Lsrc/engine/SCons/Tool/dmd.pyF233T135

DMD is one of the three D compilers, the one that is actually the
mainline one. GDC is D in the GCC system, LDC is D on LLVM.

> > In general, the D tools use their own set of variables starting with "D*"
> > (or "_D*") so they shouldn't create much of a problem. But the D tools also
> > set "STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME" to 0, independent of any
> > setting that a tool like msvs.py made before. :(
> 
> Why D uses global keyword that is reserved for C stuff?

Either because it was necessary or because I made an error. If an error
(likely I suspect) we should find the right solution and put it in
place.

> > I'm open for a discussion and would like to hear other ideas. My way to fix
> > this would be:
> >
> > - D tools shouldn't be loaded by default, but get an optional tool ( ->
> > tools=['default', 'dmd'] is mandatory). It's not enough to say "Let's try to
> > detect them, and load them automatically.", as long as the "STATIC_SHARED"
> > flag gets set to a fixed value. An option would be to use env.Default() to
> > set this flag, but I don't know if D can then cope with a possible setting
> > of "1" (Russel?).
> 
> +1 on disabling it by default for the performance reasons listed here
> https://bitbucket.org/scons/scons/commits/b757fe34f9fe#chg-src/engine/SCons/Tool/__init__.py

Which is an argument for getting rid of Fortran, C++ and C, and also
LaTeX, actually all the tools, from begin loaded by default.

> > - Docs should get amended, to warn the user about the overwrite of the
> > "STATIC_AND_SHARED" flag.
> > - Then push out a new patch release as soon as possible.
> 
> The problems are caused by this commit:
> https://bitbucket.org/scons/scons/commits/b757fe34f9fe
> which is huge (which is bad), which is also a source of this bug

As we know Gary and I are Git people who like transient feature branches
that can be packaged for merge and are not Mercurial experts. The D
changes extended over a very long period in a Mercurial feature fork
with me keeping the fork up to date with the mainline. On merge
Mercurial was unable to cope with this, creating zillions of spurious
crap. Really we do not have a good workflow and that is at the heart of
the "big commit". I just made a single commit of all the D changes from
over a two year period because it was the only way to not have a huge
internal Mercurial mess.

If there is a workflow that works with Mercurial for SCons then we need
education and a document explaining what to do.

> http://scons.tigris.org/issues/show_bug.cgi?id=2966

I think this and the current problem may be related since the word def
appears in both problems.

> in which Gary accepts that the commit is large, but since he is the one
> who merged it, I guess it didn't pass proper review
> https://bitbucket.org/scons/scons/commits/40fa954282a3893b809eb4782efe231a95ded10f
> and the worse part that was already reverted once
> https://bitbucket.org/scons/scons/commits/8764000345e06e326ef68fd0acf9366c1f3eb885
> which raises a question about our review process and debt
> of competence.

I feel quite competent actually. Most of the blame for this can be laid
squarely at the door of Mercurial not being a good fit for managing the
SCons repository with the people and tools we have.

If on the other hand people think Gary and I acted improperly, then
there is always pistols at dawn?

> I made a quick review too, and noticed a new default tool, but the fact
> that D tool became new default tool that *changes default behavior* is
> something that I didn't think might happen. But what it is not reflected
> in CHANGES.txt I think is a major ommision.

It doesn't change the default behaviour, or at least shouldn't. What is
being changed that you notice?

> Now a big thing. CHANGES.txt explicitly says  "Tools for DMD, GDC
> and LDC provided and integrated with the C and C++ linking." That should
> say something for people who now C/C++ (i.e. not to me). Looking at pull
> request,  I don't see tests that cover this integration on C and C++ side.
> The tests need to be updated in any case.

This is a very sensible suggestion and one well worth following up. Feel
free to create some and do pull requests or send me suggestions and I
will do some. I will see what I can do, but it will be a couple of weeks
tie yet.

> About solving regressions with documentation - I am not a C/C++ coder,
> but I am not a fan of dealing with things this way.

Nor am I. This is not a regression, but the bugs need to be fixed.

As noted elsewhere the bugs come from Windows people not Linux or OSX
people highlighting that no-on bothered to test 2.3.2 on Windows before
it was released. I cannot since I don't have Windows, something I
repeatedly brought to people's notice about this long ago.

-- 
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/7fd83531/attachment.pgp>