On 2011-12-07 15:06, Russel Winder wrote:
On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote:
[...]
What I see as the advantage of a new build system is that it can be
developed specifically for D which could make the tool very easy to use.
Example:
$ tool build main.d
Go has gone to the extreme with this, they have a project structure
which is mandated. This makes build completely convention driven so
there are no build specifications at all, their build tool can deduce
all the data needed to complete a build.
There are still cases when special flags are needed and how is the
library dependencies resolved?
This is the logical extension of the "convention over configuration"
approach developed by Maven and Gradle to such great effect.
I think that makes sense. It should be the default but it should still
be possible to use a custom project structure.
That's all that should be needed to build an executable. You could have
the same in a build script:
// buildfile
main.d
Too much data ;-)
Hehe. It's the same amount of data, just moved from the command line
into a build script. The comment was to make it clear it was in a build
script.
$ tool build
For a library it should be similar:
$ tool build foo
Where "foo" is a directory. I don't know if that's possible to have in a
build tool not specifically developed for D.
I still worry about a language specific tool. Language plugins to
general tools make far more sense to me.
Well, can the above be simplicity be achieved if an existing tool is used?
--
/Jacob Carlborg
