Add build option to package for specific config

[QAston]

For example, we have a config like this
https://gist.github.com/QAston/5670098

Intention of the config file is to add some specific version identifiers (could be dependencies, or maybe anything) for building testing executable for a library. Right now dub warns about enforcing a particular build type (using dflag unittest). My proposal is:
adding build="unittest" entry in "tests" config section could have same effect as using --config="tests" --build="unittest" in command line.

[s-ludwig]

Another suggestion was to make the different build types customizable. It could look similar to this:

{ /* package.json */
    ...
    "buildTypes": {
        "unittest": { /* override standard build type */
            /* dflags inherited by default */
            "versions": ["RunTests"]
        },
        "benchmark": { /* custom build type */
            ...
        }
    }
}

The reason I would prefer such an approach is that configurations are meant more for switching between different feature sets/target configurations of a package, mostly useful when used as a library/dependency. Debugging, testing, profiling etc. is meant to be orthogonal to avoid the combinatorial explosion that would otherwise arise. Of course, often the two concepts are not always easy to keep apart (more or less the same problem as the decision to use a configuration vs. making a separate package).

Would such a build type customizing approach work in your case?

PS: I realize that there is currently one issue with --build=unittest when a whole dependency tree of packages is involved. Currently all dependencies will also be built with unit testing enabled, although, depending on the use case, maybe only the tests of the root package should run. I think this will have to be configurable somehow as well, maybe using a command line switch.

[QAston]

I think your proposal is better, and yeah, it'd work in my case. Thanks!

[FeepingCreature]

Very late ping.

First of all, this contradicts the documentation: https://code.dlang.org/docs/commandline

Specifies the type of build to perform. Note that setting the DFLAGS environment variable will override the build type with custom flags.

Second, it means that it's impossible to inject DFLAGS into a dependency except via config overriding inside the project, so if a project has a version flag then this flag cannot be set when pulling in the project as a dependency.

This is a problem with Vibe.d for instance, which has the rather useful DisableCommandLineParsing version flag but no way to set it except DFLAGS.