The DUB package manager

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Feb 16 11:37:00 PST 2013


On Sat, Feb 16, 2013 at 08:15:13PM +0100, Jacob Carlborg wrote:
> On 2013-02-16 19:39, Sönke Ludwig wrote:
> 
> >Not at all, the idea is to have a number of "build script" generators
> >so everyone can choose whatever fits best, otherwise a generic
> >rdmd/dmd based build works out of the box with no need to install an
> >additional tool. Invoking a generic external tool is easy enough to
> >add and already planned, so this should not be a limiting factor in
> >any way.
> 
> Ok, I see. But it feels wrong to me that it should generate a build
> script. I think the package should already contain a build script.
[...]

I think Sönke's idea is actually very good. I know we all have our own
preferences for build systems (I know I do -- for example, I abhor
anything to do with makefiles), but having a standardized way to specify
a build has many advantages. Imagine the user-unfriendliness of
downloading a bunch of packages from the D package manager, only to
discover that one requires make, another requires cmake, another
requires SCons, another requires Ant, pretty soon, what should be just a
simple automatic download turns into a nightmare of installing 20
different build systems just so you can use a bunch of packages from the
standard D package manager.

Having a standardized way of generating build scripts is good, because
then the D package manager can target the *end user*'s preferred build
system, rather than whatever build system the package writers chose. The
package writers can just specify how to build the stuff, then let the D
packager generate makefiles for one user, Ant files for another user,
etc.. This makes it much more friendly to use, and therefore, more
likely people will actually use it.


T

-- 
Guns don't kill people. Bullets do.


More information about the Digitalmars-d mailing list