On Wed, 07 Dec 2011 14:03:02 +0000 Russel Winder <[email protected]> wrote:
> On Wed, 2011-12-07 at 22:00 +1100, Andrew Gough wrote: > [...] > > I'm suggesting that the current multi-pronged approach to providing > > a workable build system is hampered by the multitude of directions > > and could benefit from some initial discussion, consensus and > > design. > > OK. It is a valid point, effort is being diluted. On the other hand > various people prefer different systems, so I am not sure there is any > constructive point in dictating the "one true build system". If there > were one that gained a majority support votes then it could > concentrate available effort. > > [...] > > I agree that it would be good to use a tool with support for > > multiple languages & platforms. I was trying to point out that the > > multitude of options is potentially harmful. > > Or an opportunity? > Maybe. > D is trying to supplant C, C++, Fortran and Python. D should > therefore be buildable with the same tools that people use with these > languages in order to provide the lowest possible barrier to entry to > D of C, C++, Fortran and Python programmers. Not having to change > build system but simply to add to their current build system makes > transition easier. > Agreed. > [...] > > Simple Ant scripts are easy, but XML is a very bad choice for a > > build system IMO > > XML was an interesting choice originally, but has been perverted > beyond sanity in the Ant context. This is why I wrote Gant -- use > all the Ant tasks but not from the XML interpreter but from Groovy > scripts. The idea cannot have been all bad as it inspired Hans > Dockter to create Gradle, and the Apache folk forked Gant to create > the Groovy frontend to Ant. > > [...] > > > > Not really what I was suggesting - I was hoping to discuss > > consolidating effort around a small set of tools, rather than the > > current state. > > I fully appreciate the idea is to focus effort so as to avoid > dilution. With the effort available it is a good idea. I am just not > convinced creating new tools from scratch is the right approach. > > [...] > > > Do we work with a build framework that exists and already allows > > > serious build using D; or > > > > Possibly. > > > > > do we start from scratch with a new build framework that no-one > > > can use till something is ready? > > > > Possibly (if necessary) > > > > I thought it important to have a discussion first to determine the > > requirements and use cases, and concentrate effort rather than > > disperse it. > > Having a full and frank exchange of views is an excellent move. As > long as everyone stays friends! > > Having watched what happened with Gant, Gradle, Buildr, sbt, > Leiningen, Rake, Bake, Rant, Ant, Maven, make, Cmake, Autotools, etc. > I fear the overall effect of a "focused on D" build tool, whether > build from scratch or over another framework. Specialist per > language build tools lead to a ghettoization. Even 5 mins looking at > the Rake, sbt and Leiningen situations make this abundantly clear. > Which is sad as there are many good things about all of them. > > If there effort to start from scratch with D to create the replacement > for Make, CMake, Autotools, as a general build framework, that is a > different issue. But this is a big undertaking requiring DAGs, C > scanners, C++ scanners, Fortran scanners, LaTeX scanners, etc., not to > mention tool finders and toolchain builders. I actually think its unnecessary to start from scratch, but am interested in other's opinions. > > My current prejudice is that SCons, Waf and CMake already have almost > all of this stuff already in place, so it is an incremental step to > make sure they work well with D (*). > I agree - my preference is for a build configuration tool like CMake or premake. They already do a lot of the heavy lifting and can potentially support polyglot builds. I think that may be important in D's future considering Deimos. -- Andrew Gough M: 0408 596 656 [email protected]
signature.asc
Description: PGP signature
