RejectedSoftware Forums

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
flags.

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
line.

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
package.json.

But for this specific problem - what about a standard version
identifier similar to the "Havexyz" identifiers that are already
present, aybe "Mainxyz", "Projectxyz" or something? And then wrap
the code in "version(Mainxyz) 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.

On Wed, 20 Mar 2013 14:09:38 GMT
"Robert" jfanatiker@gmx.at wrote:

Packages can blacklist or force certain (compiler abstracted) flags
if needed:

E.g.:

"buildFlags" : [ "noinline", "boundscheck" ]

Meaning:

• Even if the user specified -inline, don't use it for this package,

because of some bug.

• Use boundscheck even if user disabled it, because our code really

sucks, so this should really not be disabled.

If needed, a package could also specify default flags for the case
that the user did not specify anything, but get overridden with user
data, instead of only providing the option to override user choices.

I think that should be flipped around. Anything the user specifies on
the command line should automatically override whatever is in the
package file, period. Anything else is confusing, inflexible and
problematic.

That said, I'm not entirely against the idea of having a way for the
package.json to override the user's command line choices (similar to
CSS's "!important" feature), but it needs to very explicit in
package.json (ex: "forceBuildFlags" instead of the usual "buildFlags"),
and then the user needs to be informed when their command-line argument
is being overridden by the package.json. And then they'd still need a
way to override that (again, much like CSS's !important).

On Mon, 18 Mar 2013 14:47:43 -0400, Nick Sabalausky wrote:

(...) Or
on other projects, there can be bugs that prevent them from working
right with certain flags like -inline. (...)

For this and similar cases there is now support for a "buildRequirements" field (git master).