Dub generating incorrect VisualD configurations with "-b=release-debug" switch

shadolight commented 5 years ago

System information

dub version: v1.15.0

Bug Description

"Dub generate visuald" generates incorrect configurations when passed the "-b=release-debug" switch (with the intention to build both the Release and Debug configurations in a VisualD project with a single dub invocation):

When also passed "-a=x86_mscoff" switch, 2 configurations are indeed generated in <prj>.visualdproj, but they are in fact identical release versions (and even share the same name). The <additionalOptions> flag is correct:

<Config name="release-debug" platform="Win32">
..
<release>1</release>
<additionalOptions>-m32mscoff</additionalOptions>
..
</Config>
<Config name="release-debug" platform="Win32">
..
<release>1</release>
<additionalOptions>-m32mscoff</additionalOptions>```
..
</Config>

When instead passed "-a=x86 switch", only the 32 bit Release version is produced. The <additionalOptions> flag is correct

<Config name="release-debug" platform="Win32">
..
<release>1</release>
<additionalOptions>-m32</additionalOptions>
..
</Config>

When instead passed "-a=x64 switch", only the 64 bit Release version is produced. The <additionalOptions> flag is correct.
```
<Config name="release-debug" platform="x64">
..
<release>1</release>
<additionalOptions>-m64</additionalOptions>
..
</Config>
```
Note there is a related bug present in "dub build", for which this issue has been opened.

How to reproduce?

dub generate visuald -b=release-debug -a=x86_mscoff
dub generate visuald -b=release-debug -a=x86
dub generate visuald -b=release-debug -a=x86_64

Expected Behavior

1; 2 x 32 bit Configurations (1 x Debug and 1 x Release version) should be generated targeting COFF format:

 <Config name="debug" platform="Win32">
..
   <release>0</release>
   <additionalOptions>-m32mscoff</additionalOptions>
..
 </Config>
 <Config name="release" platform="Win32">
..
   <release>1</release>
   <additionalOptions>-m32mscoff</additionalOptions>
..
 </Config>

2; 2 x 32 bit Configurations (1 x Debug and 1 x Release version) should be generated targeting OMF format:

 <Config name="debug" platform="Win32">
..
   <release>0</release>
   <additionalOptions>-m32</additionalOptions>
..
 </Config>
 <Config name="release" platform="Win32">
..
   <release>1</release>
   <additionalOptions>-m32</additionalOptions>
..
 </Config>

3; 2 x 64 bit Configurations (1 x Debug and 1 x Release version) should be generated targeting COFF format:

 <Config name="debug" platform="x64">
..
   <release>0</release>
   <additionalOptions>-m64</additionalOptions>
..
 </Config>
 <Config name="release" platform="x64">
..
   <release>1</release>
   <additionalOptions>-m64</additionalOptions>
..
 </Config>

p0nce commented 4 years ago

release-debug is not "release + debug", it means "like release but with debug info".

This is a build type meant for profiling, and debugging an optimized binary.

shadolight commented 3 years ago

Interesting... I did not realize that! Thanks for the clarification.

The misleading part (at least for me) is that, if you use visuald itself to create a project, it creates by default both a debug and a release configuration - obviously the .sln and .visualdproj then contain both configurations. (And this is standard for VS when you create a project irrespective of the language).

It would have been nice if dub did that too - at the moment dub overwrites any previously generated sln/visualdproj files, so if you want both you have to rename + merge the 2 configurations yourself.

I guess the issue is that dub generate and dub build is actually pretty similar in how you call it (i.e. pretty much the same API) and, since you only build a single configuration at a time, dubgenerate has the same behavior.

p0nce commented 3 years ago

It is how it's done in C++; but it doesn't fit DUB very much. You can just generate a visuald project everytime.

dub generate -a <arch> -b debug -c <configuration>
dub generate -a <arch> -b release -c <configuration>

You want to prefer those two particular build types, but:

there are more useful build types: release-nobounds, release-debug
Some projects will have several configurations (software features)

In the end it's easier to regenerate the .visuald with a script. You can use --combined to have a .sln with a single project too.

shadolight commented 3 years ago

Sure, it is not the way dub is designed to work, and sure, you can generate the visuald project of your choice each time.

In fact, generating the release version for visuald with dub is actually a bit useless - for the same dub commandline "effort" to generate it you might as well just just build it! The only really useful configurations to build for visuald would be the 'debug'-related ones, although I can imagine it could be useful for some people to have all configurations added to the solution from a single 'dun generate visuald' invocation - maybe there are people that will prefer to get & fetch all the dependencies with dub (for which it is very good), but then to generate a VS solution once with all configurations included - and from there on switch to visuald 100% without needing dub again.

Personally I'm fine to switch between the 2, so not a high priority for me at all. So, yeah, probably not much of an issue if nobody else is asking for this - maybe someone (not sure who?) can close it.

dlang / dub