On Thursday 03 April 2008, Alan W. Irwin wrote: > 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),
One prinicipal problem I see with pkg-config is that it is intended to be used in such a way that the stdout is directly used as command line arguments for the compiler. E.g. instead of a list of include directories it just prints -I/opt/foo/include -I/home/alex/install/include . It does the same for other flags, which may be not that standard as -I for include dirs. This breaks if you try to use the package with another compiler than the one the pc-file was written for. It would be so much better if it would store something like an xml file: <include_dirs> <dir>/opt/foo/include</dir> <dir>/home/alex/install/include</dir> </include_dirs> This would be independent from the syntax of the *command line arguments of the compiler*. > 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. If you run pkg-config of the build host it will find the pkg-config files of the libs for the build host. In general you can't run the pkg-config for the target since, well, this is binary code for some other platform. > 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. One idea would be to parse the *.pc-files directly with cmake, this would help with the cross compiling and this could also help against buggy *.pc-files (i.e. where the flags are not stored in the correct variables). Alex _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
