On 4/26/11 11:56 AM, Russel Winder wrote:
On Tue, 2011-04-26 at 10:09 -0500, Andrei Alexandrescu wrote:
On 4/26/11 7:50 AM, Russel Winder wrote:
On Tue, 2011-04-26 at 08:32 -0400, dsimcha wrote:
[ . . . ]
Soon. I'm praying that I can figure out makefiles in that time to check
std.parallelism in, since I think they're harder to work with than
multithreading. (Ok, I'm exaggerating.) Among the other major
improvements in this release:
Isn't Make 1970s technology, I'd have thought D would use more
up-to-date build technology than that -- even though Go uses it and
refuses to look at other options.
The debate about make being inadequate is almost as old as make itself
Hardly. In 1978 Make was a revelation and a revolution. Well at least
on Unix. And that is the problem, Make is all very well if you are on
Unix and can rely on /bin/sh and various other tools. As soon as you
try to create platform independent builds, Make fails to be sensible
except for trivial builds.
This has been a common complaint about make... until gmake came about.
Targeting gmake newer than a specific version seldom causes
platform-related issues.
:o). Our gnu makefile for Posix isn't in any way difficult or scary,
although it did take a few iterations to get it right. It has 312 lines
to control a build of 143KLOC, which is a good ratio. The only
If the build for DMD and Phobos is a single Makefile of 312 lines then
it almost certainly needs refactoring. Ratio of source code lines to
Makefile lines is almost certainly a spurious metric.
It is a great metric because they are in a ratio determined by the tools
used. 312 lines to build 143K lines seems a good ratio to me - probably
some of the best I've seen.
The 312 lines make is only for Phobos. If you could reduce and simplify
it, we'd all appreciate it.
difficulty David would have to modify that makefile is to find the one
place where all modules are enumerated, and insert his module's name
there, so I have no idea why he finds that task daunting. (The Windows
makefile is crappier and repeats itself a lot of times so that's more
annoying to deal with.)
Why is there a separate Windows Makefile? Oh of course you actually
have to have separate build systems for Windows, Mac OS X, Linux,
Solaris, etc., etc. because Make is not a platform independent system,
it relies on /bin/sh and other tools.
Sorry, you are wrong here. Please take a look!
The simple fact is that if someone wants to improve our build system
they'd have to define it and argue successfully for its superiority. The
issues I'm seeing as a build-systems-outsider who doesn't pay much
attention are: (a) there are TONS of them; (b) each has issues that
prevents it from becoming a new de facto standard; (c) the "best" one
depends a lot on who you ask.
Wrong approach I think. If anyone cares enough then they write a Waf,
SCons or CMake (or whatever marginal build system people can find) build
in parallel to the Make one using a fork of the D project source. They
then announce it. Then people use it. Then the Make system dies off.
Exactly!
Make has issues that stops it being a modern build system, but it hangs
on because people are scared of change and so do anything and everything
to stay with using it even though it is an outdated system and there are
now far superior ones.
The general considerations are most appreciated. I don't think scare of
change is an issue for us.
There are indeed zillions of build frameworks. Every new programming
language ends up having someone write a new build system in it -- Go
appears to have created a record by having about six all written in the
last year. It is a knee-jerk reaction. What is relevant is what are
the de facto standards as opposed to de jure standards. Make and
Autotools are still there because they have been there for 30 years.
Waf, SCons, CMake and Rake are the only tools with traction off the JVM.
Gradle, Maven, Gant, Ant, are the market leaders on the JVM with SBT and
Leiningen have some cult following. Any other build framework is
currently marginal -- no matter how good it actually is.
There are metrics to decide which is best for a given project. Fashion
and prejudice do also, sadly, take their place in most projects
decisions. :-(
What also matters is that stuff that stays is stuff that gets done. You
seem to have a good amount of expertise, but at the same time choose to
firmly plant your figurative self in the proverbial armchair. If you
know how to do it, do it, don't attempt to beat others into doing it.
Andrei
