I'll be home in a few days. I have plenty of Windows machines and can do the required tests. As for not noticing that that change broke Windows def files, I should have checked that. (There was a new failure in the Windows buildbot but I didn't notice it.) As for the large change, Russel has it right. Git would have made that much simpler. And Anatoly, please be nice. We're all volunteers here, trying to do a good job with limited time available.
-- Gary Oberbrunner (sent from my Android) On Aug 9, 2014 2:23 PM, "Russel Winder" <[email protected]> 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:[email protected] > 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder > > _______________________________________________ > Scons-dev mailing list > [email protected] > http://two.pairlist.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
