VisualD : generate all build modes

[Flamaros]

Hi,

This changes make the VisualD solution always generated with debug, release and unittest modes.
Any Visual Studio should expect that as every c++ projects comes with debug and release modes by default. This improve Windows user productivity by reducing the usage of terminal.

[coveralls]

Coverage decreased (-0.2%) to 61.358% when pulling 97d5845 on Flamaros:master into 038fc1b on dlang:master.

[Flamaros]

I may found a little issue, all builds use the same output file path. So a manual clean is needed to generate the proper target.

Need I fix that? I think to fix it by adding the build mode as directory in the output path (eg. bin/debug/prog.exe)

[coveralls]

Coverage decreased (-0.2%) to 61.358% when pulling b27a73b on Flamaros:master into 038fc1b on dlang:master.

[Flamaros]

Need I improve test coverage to have a review?

[s-ludwig]

Sorry for the review delay, we have a little shortage of regular reviewers currently. I think this is generally a viable solution for the time being, being able to specify different target names/paths is an orthogonal issue and can be solved later.

The only issue is that just changing the build options may be somewhat surprising if more than that is defined in the package recipe, such as a custom build mode. Instead of hard-coding the build options, addBuildTypeSettings would have to be used here. However, since ProjectGenerator already does that, we'd need another field in TargetInfo, let's call it baseBuildSettings, which includes everything except for the build type specific settings.

Then, VisualDGenerator would just have to duplicate that object and replicate

dub/source/dub/generators/generator.d

Lines 104 to 105 in 28a1c02

	addBuildTypeSettings(targets, settings);
	foreach (ref t; targets.byValue) enforceBuildRequirements(t.buildSettings);

for each build type.

In the long term, I'd like to implement something akin to dub generate visuald --build=debug,release --arch=x86,x86_64 for defining the build matrix, but until then implementing it just within the VisualD generator is the most practical solution.

[Flamaros]

No problem.

I'll try to do modifications that you suggest.

My first try was to manage command line exactly like you see it for the futur, but I am not enough familiar with dub code (and confortable with D) to manage changes with this kind of impact. It will be a major refactor that impacts all generators.

[Pombal]

Any updates on this?

I'm trying to find a way to generate a visuald solution with x86, x86-64, debug, and release configurations, and I can't find any way to do it.

[rikkimax]

Also looking for an update. Would be willing to take over if required.

Looks like they are doing their own thing and this isn't important to them. So yeah go ahead and take it over if you want to continue it!