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

Sat Aug 9 12:01:18 EDT 2014

>
> 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.

+1, I'm new, so my voice counts less, but my past experiences with revision
management tools is that GIT > Mercurial in every way;  Mercurial is more
like distributed CVS (and CVS was a lifetime/nightmare ago).

I could make a long rant here, but my primary point is that maybe a motion
should be made for moving SCons to GIT?  We could at least take a vote and
see if anyone is adamantly opposed.  I'm against using a hammer to do the
job of a screwdriver.

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
> http://scons.tigris.org/issues/show_bug.cgi?id=2966
> 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.

Not too long ago, we had a 30+ email chain for a small 20-line patch, which
you basically through a tantrum over.  Ironically, it was reviewed for
nearly two weeks and you hadn't bothered to care until it was merged.  You
jumped to conclusions and that mail chain turned out to be a weeks worth of
effort just explaining that you were confused about what the patch was
doing!  I tried to be professional about it even though you were being
pretty venomous.

If you want to help, then help, but your comments are unwarranted.

-William

On Sat, Aug 9, 2014 at 8:23 AM, Russel Winder <russel at winder.org.uk> wrote:

> 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
>
> _______________________________________________
> 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/20140809/e2d4be5d/attachment-0001.html>