-
September 10th, 2012, 08:34 AM
#1
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?
"A problem well stated is a problem half solved.” - Charles F. Kettering
-
September 10th, 2012, 08:51 AM
#2
Re: Detrmining if a lib is a Debug version or a 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).
-
September 10th, 2012, 09:11 AM
#3
Re: Detrmining if a lib is a Debug version or a Release version
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.!
"A problem well stated is a problem half solved.” - Charles F. Kettering
-
September 10th, 2012, 10:31 AM
#4
Re: Detrmining if a lib is a Debug version or a Release version
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:-
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:-
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?
Last edited by John E; September 10th, 2012 at 10:34 AM.
"A problem well stated is a problem half solved.” - Charles F. Kettering
-
September 10th, 2012, 10:57 AM
#5
Re: Detrmining if a lib is a Debug version or a Release version
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
libdir=${exec_prefix}/lib/$(target)
-
September 10th, 2012, 10:59 AM
#6
Re: Detrmining if a lib is a Debug version or a Release version
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.
-
September 10th, 2012, 11:50 AM
#7
Re: Detrmining if a lib is a Debug version or a Release version
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.
"A problem well stated is a problem half solved.” - Charles F. Kettering
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|