[CMake] FOSDEM Talk on CMake is available

[Alan W. Irwin]

On 2008-04-02 18:19-0700 E. Wing wrote:

>>> [Alan said]
>>> In sum, pkg-config is already widely used on the Linux/Mac OS X side of
>>> things and there doesn't seem to be any fundamental reason to discourage
>>> the
>>> use of pkg-config on windows even though most windows-only developers are
>>> currently completely unaware of how useful pkg-config can be.
>> [Bill said]
>> So, I had this discussion on the kde list. pkg-config is great if it is
>> installed on the machine you are using. However, since it is not a
>> default install on anything other than linux machines, you really don't
>> want to depend on it.

[answering Bill] I think you missed my point (which may be my fault).  Many
Linux libraries export the information you need to compile and link against
those libraries using pkg-config.  So if your software depends on those
libraries (which is the case for a number of different PLplot components),
you _must_ use pkg-config to build against those external libraries.
Fortunately, pkg-config is easy to install for any platform, and that small
extra dependency is negligible compared to all the many other library
dependencies PLplot has which require pkg-config to make their compile/link
information accessible. When pkg-config is not available for a platform, the
PLplot build system obviously give a big warning about the components that
will be missing from the PLplot build.  So those PLplot users who refuse to
install pkg-config must take the consequences (an extremely basic PLplot
with few bells and whistles).

My impression is Mac OS X users heed the warning while windows users don't
worry about it because they are generally reluctant (I guess because of DLL
hell) to use any external library, much less pkg-config to find out how to
compile and link against such an external library.  However, we do have at
least one windows developer who is keen enough on the PLplot bells and
whistles to install the required libraries and pkg-config, and he reports
(on a MinGW platform) there are no issues with those bells and whistles.
Thus, we may already have some ordinary PLplot users on the windows
platforms using those bells and whistles as well.

> [Eric said]Actually, I would go further and argue that pkg-config is
> fundamentally flawed. It totally breaks with respect to
> cross-compiling.

As you may be aware pkg-config compile/link information for a given library
for any particular platform/version is stored in a tiny ascii *.pc file.  I
have no practical experience with cross-compiling so your negative comment
about pkg-config in this regard might be correct, but I am not convinced by
your bare assertion.  The reason I think this way is the *.pc files are
normally stored with each library for each different platform.  Thus, it
should be straightforward to access the *.pc files associated with each
alternate platform library you are linking against to get the correct
compile and link flags for that library/platform combination.

> [Eric said]It doesn't work that well either when you have
> multiple versions of of a library installed either, either because you
> are testing different compiled variations or perhaps legacy versions.

On the contrary, I know that multiple library versions for the same platform
are easily handled by pkg-config since each library version has a
corresponding pkg-config *.pc file which you can easily access by playing
with the PKG_CONFIG_PATH environment variable.  I change that environment
variable often to access experimental versions of libraries that PLplot
depends upon with no issues at all for our CMake-based build system (since
FindPkgConfig.cmake runs pkg-config at CMake time, and that executable honors
PKG_CONFIG_PATH).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________