This is really good feedback, thanks. Would you be interested in
discussing this further privately? I've already got some ideas
brewing in my head.
Atila
On Tuesday, 3 February 2015 at 18:00:31 UTC, Russel Winder wrote:
On Mon, 2015-02-02 at 16:50 +0000, Atila Neves via
Digitalmars-d wrote:
[…]
I have ideas that go beyond this, but this is useful input. I
wonder how to proceed now about gathering actual requirements
from D devs and seeing which ones are important.
Learn lessons from SBT vs. SCons/Gant/Gradle: SBT is a Scala
build
system using Scala programs as input.
Some Scala folk got religious about Scala being the only right
language
for Scala builds, and created what has become SBT. Because of
the way
statically typed Scala works as a domain specific languages
there are
performance and expression issues that means SBT is getting a
reputation
in the very companies that should be supporting it that it is
"the
enemy".
A D build system must trivially support C, C++(, and Fortran?).
Transitive dependency management needs careful consideration. I
haven't
investigated whether Dub does this right, it may well do. Maven
does
not, Gradle does.
Define package, artefact, dependency carefully. Go has a strong
model
(even if it is wrong). Ceylon improves on Java/Scal/etc. Python
got it
woefully wrong: eggs were a mess, and PyPI is not curated well
enough
(the vast majority of stuff on PyPI is unusable rubbish).
Worry about platform specific packagers: MacPorts, Homebrew,
Debian,
Fedora, FreeBSD, OpenBSD, etc. will (hopefully) want to
package. Java is
generally a disaster for them, and Python isn't that much
better. Go is
ignoring al this and creating a monoculture based on Git and
Mercurial
as packages are shipped as source. I see Debian and Fedora
trying to
package Go things and predict the same mess as Java and Python.
Support principally a declarative DSL, but with imperative
structure
possible. A build specification is a meta-program which when
executed
creates the program and hence the build process.
Have no clearly silly constraints, cf. the needs for SBT
specification
lines always to be separated by blank lines.
Be convention over configuration, but allow configuration.
Use BinTray and Artifactory as well as the current Dub
repository.
Do not be afraid to change the meta-data specification so that.
Dub may
well be a good start, but it may need work. Gradle has changed
it's
meta-data specifications many times despite being constrained by
compatibility with Maven POMs and Ivy specification.
Stand on the shoulders of giants, but do not assume they are
always
right, be prepared to change stuff for the better.
Get alpha testers in early and let them drive things – albeit
within the
boundaries of your vision for the system. Dub did well here if I
remember correctly and created a group of people who did and
emailed
rather than just emailing.
I better finish my essay at this point I have a London D User
Group
meeting to go to :-)
http://www.meetup.com/London-D-Programmers/
