RejectedSoftware Forums

Sign up

Configuring build types?

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.

Re: Configuring build types?

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

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

Re: Configuring build types?

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<br>present, aybe "Mainxyz", "Projectxyz" or something? And then wrap<br>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.

Re: Configuring build types?

Hmmm, if we go for proper libraries, most flags could be made to only affect the particular package and I think they should.

The following scheme should work: The user can decide globally via configuration about stuff like -g/debug -inline -O -noboundscheck, ...

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.

The default flags for a package could even be extracted from the developer's global settings at release time to make sure that the best tested settings are the default.

Re: Configuring build types?

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

Re: Configuring build types?

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

Absolutely, the idea was just to have something available, so the developer can prevent flags to be used, he knows won't work. Naming it "forceBuildFlags" or something and issuing a warning is definitely a good thing. Something like CSS's !important sounds reasonable.

Re: Configuring build types?

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

Re: Configuring build types?

On Tue, 09 Apr 2013 08:38:20 GMT, Sönke Ludwig wrote:

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

BTW I implemented an abstract solution in contrast to someting like "forceBuildFlags" to make it compiler-agnostic and to allow for other kinds of requirements (e.g. force single file compilation). The requirements are always additive when multiple packages are compiled in one go (the only problem here is the "disallowDeprecations" requirement, which could break foreign source code...).