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/ -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder