On Tue, 19 Mar 2013 07:25:12 +0100
Sönke Ludwig sludwig@rejectedsoftware.com wrote:

Am 18.03.2013 19:47, schrieb Nick Sabalausky:

DUB has a "--build=release|unittest|profile|etc", but is there
currently any way to configure them? If not, there should be.

For example, on my projects, I typically wrap my unittest blocks in
a project-specific version identifier like
version(MyProj_Unittest). Or on other projects, there can be bugs
that prevent them from working right with certain flags like
-inline. Or a project's docs may be specifically designed/intended
to be built a certain way or with a certain particular other tool.
So there needs to be a way to add/remove options from those builds
if there isn't already a way.

What you can do is to set the DFLAGS variable to set completely custom

IIUC, I don't think that would really solve the problem since, AIUI,
you'd have to tell all users of your package "When you build XXXX
configuration and/or YYYY build-mode, make sure to ad -ZZZ to DFLAGS".
Plus, I don't think you can remove flags that way. Plus it doesn't work
if the package is being auto-built as a dependency of another package
(You'd be setting DFLAGS for all packages being built).

I've thought about customizing the build types, but the problem
is that customization may be desirable per package or globally and
that it may cause problems if different customizations contradict
(e.g. those of two packages in the same dependency tree). That's why
I couldn't really decide yet if and how to to that. But maybe it
makes sense to allow to specify DMD flags directly on the dub command

Hmm, yea, that would need to be worked out.

For starters, I do think any "add/remove argument XXXX" given on DUB's
command line should override anything in the main package's

But for this specific problem - what about a standard version
identifier similar to the "Havexyz" identifiers that are already
present, aybe "Main
xyz", "Projectxyz" or something? And then wrap
the code in "version(Main
xyz) version(unittest) {}"?

While that would work for that particular issue, and I wouldn't object
to such versions being added by DUB (they could be nice to have):

  1. As you indicated, it still doesn't solve the general case.

  2. I'm convinced that it's best for a package manager to impose the
    absolute least-possible restrictions on the package's structure
    and source. Many such things may very well be trivial matters, but
    people (especially programmers) can be very particular about such
    things, or may have some specific reason for doing things a particular
    way. Forcing things to be done a certain way can only create a
    barrier to entry (even if it's only a psychological barrier). And if we
    want DUB to be D's GEM/PIP/etc, then it's best to break down all such
    barriers and make DUB as enticing as possible to everyone.