DUB - call to arms

[H. S. Teoh]

On Wed, Apr 17, 2019 at 06:17:25PM +0000, Julian via Digitalmars-d wrote:
> On Wednesday, 17 April 2019 at 17:53:35 UTC, H. S. Teoh wrote:
> > In other words, we hide the complexity of the build system
> > under one or more canned invocation commands (e.g., 'make',
> > 'make clean', 'make docs', 'make test', for a standard set of
> > actions you might commonly want to do), and have the wrapper
> > package tell us what the build artifacts are.
> 
> What you lose with this is dub's current platform independence.
> That's not always present anyway, for example a project could rely
> on specific cPanel or macOS features, but it would be nice to
> retain it as the default.
[...]

Actually, this is precisely why I said that build systems would have
their own wrapper packages.  The wrapper packages would specify
potentially different commands to run, depending on the current
platform.  Since the wrapper package would have specific knowledge about
the build system it's wrapping, it could craft the build command such
that it sets up the appropriate platform-dependent settings.

E.g., the 'make' wrapper would specify a command that sets up INCPATH to
/usr/include on Linux, for example, and C:\blah\blah\include on Windows.

In fact, we could even use this as a mechanism to support cross
compilation.  E.g., given the current platform and the target platform
as parameters, the wrapper package would craft a build command that sets
up the appropriate path(s) and environment variables for cross
compilation.  This is an optional bonus feature, of course.

The point is that the build system wrapper packages would hide away
these details from dub, so dub doesn't have to know about how to set up
the build for Windows vs. Linux. It just installs the wrapper package
and queries it for the right command to use.


T

-- 
Frank disagreement binds closer than feigned agreement.