Need to allow debug/release builds to coexist

[brucedechant]

If you mix debug and release CRT libraries on Windows your application will end up crashing. There needs to be a way to allow both debug and release builds to coexist.

Perhaps adding a "d" to the end of the library/dll name to indicate the debug version and building each debug/release in its own sub-folder would help with this.

[brucedechant]

Updated file

[brucedechant]

Updated file

[brucedechant]

Updated file

[brucedechant]

Updated file

[brucedechant]

Updated file

[warmerdam]

This is an enhancement request.

It is currently possible to do a debug and a release build with the current makefiles, installing them into distinct trees, and setting distinct DLL names by passing distinct values for the VERSION macro.

eg. 

nmake /f makefile.vc clean
nmake /f makefile.vc 
nmake /f makefile.vc install GDAL_HOME=C:\gdal_release

nmake /f makefile.vc clean
nmake /f makefile.vc OPTFLAGS="/nologo /MD /EHsc /Zi /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /Fd$(GDAL_ROOT)\gdal.pdb" VERSION=14d
nmake /f makefile.vc VERSION=14d GDAL_HOME=C:\gdal_debug

I don't see a compelling reason to support distinct release and debug builds in the build tree.

But it might be nice to make doing the above easier.

[stevedang]

Running a debug or release build will create one library and remove the other. This may lead to the mixed CRT usage problem during development where a release version of the application is linked to a debug version of the library, and vice versa. Note that the VERSION macro only applies to the dynamic library name, not the static one.

Allowing debug and release builds to coexist could be done by one of the following options:

1. The debug and release libraries have a different name and are in the same directory.
2. The debug and release libraries have the same name but are in a different directory.
3. The debug and release libraries have a different name and are in a different directory (Xerces-C project adopts this).

[warmerdam]

Bruce,

The above mentioned approach installs the debug and release versions of stuff into distinct directories. So the debug and release configurations of the application would point to the appropriate directories.

I am guessing you are in the habit of using the gdal_i.lib directly from the build tree, and I think this is inadivisable.

So I'm basically advocating that you use option "2" - the debug and release stub libraries have the same name, but are in different directories (after being installed).

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.