Detrmining if a lib is a Debug version or a Release version

Or to put it another way... does anyone here have a better understanding of pkg-config than I do? Here's the problem....

I tend to use the Windows convention of adding a "D" suffix to my Debug builds. So some_lib.lib/some_lib.dll will become some_libD.lib and some_libD.dll for my Debug builds. This all works fine as long as I build with Visual Studio.

But suppose I want to build using waf (which in turn, uses pkg-config). AFAICT pkg-config carries out certain tests to establish whether a project's dependencies are present or not. But once it finds a lib that matches its expectations it doesn't look any further. This means that when building a Debug version of your app, you'll often find that it has in fact linked to the Release versions of the dependent libraries. It's possible to solve the problem by placing Debug libraries and Release libraries in different folders but that introduces problems of its own. :(

I wanted to contact the pkg-config devs and suggest that when a Debug build is specified it should search (at least initially) for Debug versions of any dependent libraries - but is that even possible? Can such a utility test to see if a found library is the Debug version or the Release version?

the simple solution is to force the lib to need rebuilding if the config changes between release and debug.
additionally, add a linked function that is only defined in release and one only in debug ( you could call them void releasebuild() and void debugbuild()). Use the #ifdef's to define one of the two depending on the type of build.

In the consuming program do the same, either call the releasebuild() or the debugbuild() function. That way, if you're using the wrong lib, it simply won't link because of missing functions).

Thanks OReubens. I think that's (kinda) similar to the strategy that most people use under Linux. You either build everything in Debug mode or you build everything in Release mode but you rarely have them both co-existing simultaneously. Personally I don't much care for that approach as it leads to libraries being repeatedly deleted and re-built when there've been no significant changes. I'm a great believer in NOT building things if I don't have to.! :D

I just discovered something that offers a tantalizing possibility. It seems that each library has its own pkg-config configuration file (ending with the extension ".pc") which usually contains a section that looks like this:-

Quote:

---

Name: Serd
Version: 0.18.1
Description: Lightweight RDF syntax library
Libs: -L${libdir} -lserd-0
Cflags: -I${includedir}/serd-0

prefix=F:/+GTK-SOURCES/gnu-win32
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib

---

If I could modify libdir I could have different folders for my Debug libraries and my Release libraries. So that last section would look something like this:-

Quote:

---

prefix=F:/+GTK-SOURCES/gnu-win32
exec_prefix=${prefix}
includedir=${prefix}/include
#ifdef DEBUG
libdir=${exec_prefix}/lib/Debug
#else
libdir=${exec_prefix}/lib/Release
#endif

---

Not that exactly of course because #ifdef is probably meaningless to pkg-config. But is there anything similar that pkg-config would understand?

Since I don't use waf I don't have the complete picture but can't you define a target before building? If so you can use something like

Quote:

---

libdir=${exec_prefix}/lib/$(target)

---

Well I found it strange that you have a build system that would have different configurations being output to the same directory causing stuff to overwrite eachother. That seems like a really weird way of doing it.

The ${something} names are probably environment settings (or the linux variant thereof), so you could potentially run the build from a batchfile/script of your own and set the environment setting before running the build.

So for windows that would be something like: MakeDebug.bat

Code:

---

set libdir=c:\myproject\debug
start compileandmake /param1 /param2

---

and an analogous one for release builds.

Quote:

---

Originally Posted by OReubens

Well I found it strange that you have a build system that would have different configurations being output to the same directory causing stuff to overwrite eachother. That seems like a really weird way of doing it.

---

No, fortunately they don't overwrite each other. The presence of the "D" suffix ensures that the Debug library never has the same name as the Release library. Mind you, your batch file suggestion is a good idea. One of the libraries I'm building is called suil. Suil depends on libgtk+. My builds of libgtk+ are called libgtk_win32_2_0.lib and libgtk_win32_2_0D.lib respectively. However, the waf process uses pkg-config to determine the name of libgtk+ and it turns out to be gtk-win32-2.0.lib

Since the required name is different from either of my names I could use two batch files to copy my libs and produce a file with the expected name. So MakeRelease.bat would copy libgtk_win32_2_0.lib and call it gtk-win32-2.0.lib - whereas MakeDebug.bat would copy libgtk_win32_2_0D.lib and call it gtk-win32-2.0.lib. I think that's probaby the best soution.