Wrong VS2010 project settings when "Debugging enabled"

The Projucer
#1

When “Debugging enabled” is checked for a Release build, the only setting that should be changed is the “Generate debug info” option in Visual Studio. Perhaps we should change the IntroJucer label to “Generate debug info.”

As it stands, there is no way using IntroJucer to generate debug info for a Release build. Checking “Debugging enabled” in a Release target defines the macros DEBUG and DEBUG_ !!!

sigh

#2

If that wasn’t the case, then to create a normal debug config, people need to set a _DEBUG macro manually, and it’s not realistic to just expect people to somehow know that they have to do that…

#3

Then how do you build Release with debug info?

#4

That’s not a very common thing to do! Why not create a new config, set it to debug mode, but turn on optimisation?

#5
  1. Turning on “Debugging enabled” forces optimizations off regardless of what you have set for “Optimisation”
  2. Turning on “Debugging enabled” uses the Multi-threaded Debug runtime library.
  3. Turning on “Debugging enabled” sets the DEBUG and DEBUG_ macros.

I don’t want any of these things…I simply need a Release build that generates a .pdb file! Its hard to imagine that this is not a common use-case. Who on earth sends a Debug build to the testing department? A Debug version is like a completely different app…different runtime library, different behavior (because of DEBUG macro), and different run time performance characteristics.

Besides, are you saying that IntroJucer only supports “common” use cases and that anyone else is SOL?

#6

Bumping this because it never got fixed.

It is VITAL to be able to produce release builds (full optimization, with LTCG link time code generation OPTIONAL) that have debugging information / symbols / .pdb files.

Profilers need symbols to generate a report, and profiling a Debug version is…well, kinda pointless.

#7

I can’t see how this could be done without each config having two different debug switches, the normal one which selects all the appropriate macros and libraries, and another switch that only affects the flag to generate the pdb… That seems like it’d be very confusing to me. Any better ideas?

#8

Sure, do exactly what you described with the two separate checkboxes, but call one “Generate symbols.”

#9

It would be nice to be able to profile optimized IntroJucer targets.

#10

You could have these options in the exporter:

Dropdown “Debug mode”
“Debug”
“Release”
“Custom” <-- this will enable the following checkboxes:

If “Custom” is chosen then these checkbox become enabled:

(checkbox) “Debug build” (controls the NDEBUG macro, C runtime library)
(checkbox) “Generate symbols”
(checkbox) “Link Time Code Generation”
(dropdown) “Optimisation” (size/speed, maximum speed, none)

#11

I still can’t use the project that Introjucer generates to create a profile, since it doesn’t have debugging symbols turned on.

#12

I thought I added that after your last bout of nagging?

#13

Hmm…perhaps you set it for the C++ options but forgot to set “Generate Debug Info” in the Linker options?

#14

This is still a problem. How can I make this clear…we need to be able to Generate Debug Info in Release builds. That is to say, that there needs to be a way to tell IntroJucer “I want my Release builds to be optimized, with all the settings as they are currently, except that I want to also generate debug symbols in the executable and also produce a .pdb file.”

Right now if I check “Debugging enabled” then technically, yes it allows debugging but it also sets the DEBUG and DEBUG_ macros which makes the app run very slow and is useless for profiling. I had “isPositiveAndBelow” showing up in my profiles along with all the other code that is called in jasserts.

There is no convenient way to profile a Release target generated in IntroJucer.

#15

When I build an installer for pre-release versions of my software I always include the .pdb file and build the executables with symbols so that if there’s a crash I can get a decent stack. It is not possible to do this with IntroJucer.

#16

I’ve not got time to look at this right now Vinnie - perhaps suggest a change to the introjucer that would do what you need?

#17

A checkbox for “Generate debugging symbols” would do it. I would turn “Debugging enabled” off for Release targets, and check the box for “Generate debugging symbols.”

#18

That’d be perfect!

#19

Fixed this myself in the Introjucer because I’m tired of messing with a dickered VS project. Here’s the code to an easy way out, that doesn’t care about the other MSVC based exporters:

Added the following in jucer_PresetIDs:

DECLARE_ID (generateDebugSymbols);

Added the following in the class MSVCBuildConfiguration:

Value shouldGenerateDebugSymbolsValue()     { return getValue (Ids::generateDebugSymbols); }
bool shouldGenerateDebugSymbols() const     { return config [Ids::generateDebugSymbols]; }

void createConfigProperties (PropertyListBuilder& props)
{
    if (! isDebug())
    {
        props.add (new BooleanPropertyComponent (shouldGenerateDebugSymbolsValue(), "Debug Symbols", "Always generate debug symbols"));
    }

Replace the following in MSVCProjectExporterVC2010::fillInProjectXml():

link->createNewChildElement ("GenerateDebugInformation")->addTextElement (isDebug ? "true" : "false");

With this:

link->createNewChildElement ("GenerateDebugInformation")->addTextElement (isDebug || config.shouldGenerateDebugSymbols() ? "true" : "false");
#20

Fyi, VS2008 supports this feature, and so does VS2005.

So only one more addition to my code above would be required to have this feature available in the Introjucer for all MSVC exporter types:

In MSVCProjectExporterVC2008::createConfig(), replace:

link->createNewChildElement ("GenerateDebugInformation")->addTextElement (isDebug ? "true" : "false");

With this:

linker->setAttribute ("GenerateDebugInformation", isDebug || config.shouldGenerateDebugSymbols() ? "true" : "false");