In package.json, Ability to disable all default compiler flags

[Abscissa]

DUB always adds its own set of compiler flags to the compiler invocation, such as -debug, -release, etc. (which ones, of course, depend on the type of build being performed). I realize this may be convenient behavior for some projects, but package.json needs a way to disable that behavior and say "The flags I'm listing here are the entire set of flags to be passed to the compiler (plus, of course any additional ones specifically requested by the user)."

[s-ludwig]

Hm, do you have a concrete problematic/inconvenient example? I think using --build=plain + "dflags": [...] almost achieves this (modulo the warnings that other means should be used instead and that "buildRequirements" may need to be used to tune -w and -property). But the urging the developer to use the abstract facilities has the gread advantage that it is highly likely that other compilers and platforms are supported automatically.

I realize though that the possibility to customize different --build types is still not solved. But this is mainly because I'm still unsure about the actual problem (need samples to get a better feel for it).

[Abscissa]

The way I see it, it's an issue of control and certainty. Many developers have their own ideas of what exactly they want the different build types to involve. So that means they'll first set the flags they want but then feel they need to check what else DUB does by default for each build type and then potentially have to figure out how to circumvent anything that, for whatever reason, might not be what they wanted. It's much easier, and more appealing for prospective users, to be able to say "I want exactly this..." and feel confident you know about exactly what you're getting, than it is to keep tabs on what the system is doing implicitly and feel like you're working against it.

Even if it can be safely argued, and even agreed on by everybody, that all of DUB's default choices for each build type are 100% correct for everyone and should never need to be altered (which I don't believe is possible anyway), or that all possible technical needs have workarounds via "buildRequirements" or whatever else - Even then the lack of a "what you explicitly state is exactly what you get" still implies a certain amount of behind-the-scenes "magic" that not everyone is going to be comfortable with.

[s-ludwig]

So would something like {"buildRequirements": ["noDefaultFlags"]} be sufficient? Things like --version flags, import directories and possibly build requirements of the dependencies would still (need to) add cause flags to be automatically added, but the default "-w -property" and build type flags ("-g -debug") would not be used. Then either the "dflags" field, or the DFLAGS environment variable could be used to specify a list of custom flags.

[Abscissa]

On Mon, 22 Apr 2013 01:13:25 -0700
Sönke Ludwig [email protected] wrote:

So would something like {"buildRequirements": ["noDefaultFlags"]}
be sufficient?

Yes.

Things like --version flags, import directories and
possibly build requirements of the dependencies would still (need to)
add cause flags to be automatically added, but the default "-w
-property" and build type flags ("-g -debug") would not be used. Then
either the "dflags" field, or the DFLAGS environment variable could
be used to specify a list of custom flags.

I agree.

[Abscissa]

Geez, GitHub's email response parser seems to be thoroughly hosed. Let me try that again:

So would something like {"buildRequirements": ["noDefaultFlags"]} be sufficient?

Yes.

Things like --version flags, import directories and possibly build requirements of the dependencies would still (need to) add cause flags to be automatically added, but the default "-w -property" and build type flags ("-g -debug") would not be used. Then either the "dflags" field, or the DFLAGS environment variable could be used to specify a list of custom flags.

I agree.