Pre Make Kit Pre Make Kit






 
 
SourceForge.net Logo
 

The story of pmkpc


Introduction

This page will explain all the reasons that made the addition of a pkg-config alternative into the PMK package.

Adding internal support

This story begins when we started to add internal support of pkg-config. The idea was to save some time by avoiding to call the binary in a subshell, so we added basic code that was used into CHECK_PKG_CONFIG command. As there is almost no documentation about pkg-config we had to look at its sources. That's where the nightmare begins, look at the following:
    if (name)
	con->appName = strcpy(malloc(strlen(name) + 1), name);

    invokeCallbacks(con, con->options, 0);
Or this one:
    *alias = newAlias;
    if (alias->longName)
	alias->longName = strcpy(malloc(strlen(alias->longName) + 1), 
				    alias->longName);
    else
	alias->longName = NULL;

    return 0;
First we were surprised that malloc() return value wasn't checked. Some Linux people will tell us that their malloc() doesn't need to be checked. Yeah, but what about other OSes ? Isn't pkg-config supposed to be portable? That said, when we found the previous examples we were amazed to see how malloc() was used directly into strcpy() without any return value checks for _BOTH_ functions.

Output bug for configuration tools

While adding support for extra config tools Damien found a bug. First look the output when gtk+.pc doesn't exist:
$ pkg-config gtk+ --modversion --cflags
1.2.10

-I/usr/local/include/gtk-1.2 -I/usr/local/include/glib-1.2 -I/usr/X11R6/include  
As you can see there is a blank line displayed. Now let's see what is the result when the pc file exists:
$ pkg-config gtk+ --modversion --cflags 
1.2.10
-I/usr/local/include/gtk-1.2 -I/usr/local/include/glib-1.2 -I/usr/local/lib/glib
/include -I/usr/X11R6/include  
Here we get the "standard" output of pkgconfig so we can said safely that support of extra configuration tools is bugged.

Call of gnome-config by default

Another weird behavior of pkg-config was found while playing with its debug option:
$ pkg-config libpng --debug --modversion --cflags
[... SNIP ...]
Looking for package 'libpng'
Looking for package 'libpng-uninstalled'
Looking for 'libpng' using legacy -config scripts
Calling gnome-config
Package libpng was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpng' found
A quick look in parse.c showed that get_compat_package() was using the gnome-config tool by default if the given package name wasn't in the list of known packages. I'm sure that there was a reason for that but we still don't get it :)

Bad behavior with *-only-* flags

*todo*

Lack of specifications

*todo*

Conclusion

All these problems were resulting into the decision of making an alternative to pkg-config: pmkpc was born. You could tell me "why not fixing pkg-config?". I could reply to this by the following reasons:
  • it would have cost more time to fix pkg-config. We also had some code already available with the internal support.
  • fixing code is nice but useless if the mainstream author(s) don't follow the goal of making something more safer and portable.
  • that was a good opportunity to have a BSD alternative that some people should appreciate.
  • multitude is good for users. They can chose what is better for them.


website design: "the.glassroom.studio (2003)