On Saturday, 16 February 2013 at 19:35:47 UTC, Russel Winder
wrote:
On Sat, 2013-02-16 at 20:15 +0100, Jacob Carlborg wrote:
[…]
I'm thinking that there should be a build tool that drives
everything. The build script contains package dependencies.
The build tool will ask the package manager to get
linker/import paths and libraries for the dependencies.
[…]
First a plug for people to think of SCons and Waf, not to
mention
Gradle, when starting to rattle of build tools.
The SBT folks are using Scala in quite interesting ways to
enable Scala
to define project specifications with all the non-inferable
dependencies.
The Gradle folks have already done almost everything the SBT
folks are
doing, but using Groovy rather than Scala.
The Go folk have done something interesting in that they have
merged the
whole concept of configuration and build by doing everything
over DVCS.
You put your sources in Git, Mercurial, Bazaar (they really
should
include Fossil as well but…) and these can be Got and the
modules
created within the standard structure local hierarchy. The
have a
single command that performs all activity. D has rdmd but
compared to
Go's go command it cannot do a lot.
I would suggest now is the time to think outside the box,
analogous to
the ways the Gradle and SBT folk have on the JVM and the way
the Go folk
have for native builds of statically linked code.
Instead of thinking in terms of compile, link, modules,
dependencies,
what is the workflow that makes D the compelling language for
building
Fortran/C/C++/D systems. This is suggesting that the milieu to
attack is
the one currently being won by Python in the computationally
intensive
areas of bioinformatics and scientific computing.
Can D be the project specification language using convention
over
configuration. Project directories are in a standard form (with
exceptions describable) with dependencies either inferred by
scanning
the project sources or specified in a trivial way in the project
specification file.
Thus I suggest that it is not that the build tool is embedded
in the
package manager but that package and dependency management is
part of
the build system.
I'm having good success using D itself as the build tool
language, and I'm at the point now where I'm getting much better
results than what I was getting out of using external build
tools, so for me there's no looking back.
I run rdmd on a .d "script" that I wrote that's setup to do
exactly what I want.
What is missing from D is a good library of functions that are
generally useful for writing build scripts. Phobos already
supplies a great deal of what is needed that can be used to
construct what is missing.
The benefit of using D is that I do not have to install and learn
a secondary language or conform to a specific build format, or
follow any weird restrictions. What I want to do is build my D
code, not learn something new and perform acrobatics to get the
job done. I can even use the same D process to build C/C++ code
if I wanted to expand on it.
What I'm saying here is that I see no reason to use a language
other than D itself as the build tool. What D can use is an
addition to Phobos that supplies the necessary generalized
functions that all build tools should supply, and I don't think
there's all that much that's missing.
For a package manager, some standards may be required, but it too
can be done completely with D.
Why use json (which is a subset of javascript), or ruby, or
python, etc? Is there something fundamentally wrong with D that
makes it unsuitable for this role?
--rt
