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
Not done yet
Lack of specifications
The only way to learn about pkg-config specifications is to read examples
or consult the code. This is a waste of time for the developer.
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.
|
