Re: pkg-config wisdom
* Bob Friesenhahn wrote on Sat, Oct 24, 2009 at 06:33:18PM CEST: On Sat, 24 Oct 2009, Peter Johansson wrote: Is there anything conceptually stopping us from writing a new AC_LINK_IFELSE that links using libtool? That would make life easier and avoid problems that only occur in configure and not when building the package (using libtool). A complexity is that libtool itself is configured via configure so it can not use itself to configure itself. Right, but you can use LT_OUTPUT and use the ./libtool script after that macro. Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: pkg-config wisdom
Alfred M. Szmidt wrote: pkg-config tries to solve an important problem, but it does so in the wrong way. pkg-config checks for an exact library name, PKG_CHECK_MODULES does not check for a library name at all, but for the name of the .pc file. This gives the administrator one extra level of indirection. The .pc file specifies the library name, so my point stands. A user cannot modify the .pc files, so it makes it hard to modify that file for a user without setting PKG_CONFIG_PATH or similar, in which case you are back to square one with CFLAGS/LDFLAGS which are far more flexible. I don't understand what is wrong with setting PKG_CONFIG_PATH. Is your argument merely that pkg-config is less well known than the traditional methods, and therefore broken? Setting PKG_CONFIG_PATH is no more difficult than setting CFLAGS. In fact, it strikes me that using pkg-config is more flexible than using CFLAGS/LDFLAGS, since the user can set PKG_CONFIG_PATH to gain complete control of the contents of the .pc files and could then make FOO_CFLAGS and FOO_LIBS be always empty, and could then control the configury with CFLAGS/LDFLAGS if so desired. If the maintainer uses pkg-config, the user can do everything that can be done with a traditional setup, but the converse is not true--therefore packages using pkg-config are more flexible. The only drawback is that if the user tweaks the .pc files in this way and the package maintainer merely invokes PKG_CHECK_MODULES and does not perform any additional tests to check the api, then the build will fail. pkg-config is simply broken in far to many ways. I've only seen one way in which pkg-config is deficient, and that is that PKG_CHECK_MODULES does not actually check that the library as specified in the .pc file exists and can be succesfully linked against. Rather, the user is assumed to be competent. In that sense, it is very much in keeping with the autoconf philosophy. In what ways, other than not being in step with the autoconf philosophy is pkg-config actually broken? It seems that if PKG_CHECK_MODULES were simply expanded to invoke AC_LINK_IFELSE to check that the contents of the .pc files are valid, then there would be no issue at all. -- William Pursell ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: pkg-config wisdom
On Thu, 2009-10-22 at 11:44 -0700, Murray S. Kucherawy wrote: What's the current general wisdom on using the pkg-config extensions? I presume there's a reason they've not been incorporated into basic autoconf, so I'm keen to learn what common practices there are toward adopting it into people's builds (or avoiding it). What I dislike on pkg-config are these: - cross-compilation does not work for you out of the box. If you want pkg-config to help you cross compile, you have to create a script in order to do that. - you can set only CFLAGS and LDFLAGS by default. No CPPFLAGS or CXXFLAGS or anything else. Although AFAIK you can add support for any variable, it is quite complicated for both sides. In other words, it does not blend well with autotools. On the other hand, custom macros are usually a disaster both for maintainers and users. Most maintainers are not autoconf experts and don't fully understand what are they doing. So they just copy and modify the macro code from another library. pkg-config is a relief in such cases. It is quite simple and easy to understand - and therefore at least not as misused as autotools. On Fri, 2009-10-23 at 18:32 -0600, John Calcote wrote: ... Issues like this are the reason why AC_SEARCH_LIBS was invented. Using AC_SEARCH_LIBS, you can specify a list of library names from most probable to least probable in the library argument. ... There is one big issue with AC_SEARCH_LIBS: If you use a different calling convention than cdecl (like stdcall, but I don't know, they've just told me), you will get unresolved symbols if you try to link without a proper include file (or something like that). Which means you can't rely on that macro, especially when it concerns Windows libraries. This is quite catastrophic, isn't it? What else than pkg-config would be the proper solution of this? ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: pkg-config wisdom
Alfred M. Szmidt wrote: pkg-config is broken because it checks for the existance of libraries, and not for the features that are required for the program to run. It does not even check for the existence of libraries. It checks for the existence of a .pc file and assumes that the user (or administrator) has supplied the correct information. -- William Pursell ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: pkg-config wisdom
pkg-config is broken because it checks for the existance of libraries, and not for the features that are required for the program to run. It does not even check for the existence of libraries. It checks for the existence of a .pc file and assumes that the user (or administrator) has supplied the correct information. Sighs, which is the exact same thing. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: pkg-config wisdom
Alfred M. Szmidt wrote: pkg-config is broken because it checks for the existance of libraries, and not for the features that are required for the program to run. It does not even check for the existence of libraries. It checks for the existence of a .pc file and assumes that the user (or administrator) has supplied the correct information. Sighs, which is the exact same thing. No, it is not the same thing. The user can construct foo.pc to add -lbar to the build when the package requests libfoo. The user has more control over certain aspects of the build, but less safety because no checks are done during configure time to ensure that libbar even exists, unless the maintainer takes extra steps to do so beyond invoking PKG_CHECK_MODULES. There is an extra level of indirection available to the user at configure time. -- William Pursell ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: pkg-config wisdom
William Pursell wrote: Alfred M. Szmidt wrote: pkg-config is broken because it checks for the existance of libraries, and not for the features that are required for the program to run. It does not even check for the existence of libraries. It checks for the existence of a .pc file and assumes that the user (or administrator) has supplied the correct information. It would be useful to have a note in the autoconf manual about pkg-config, why it exists, and what problems it has. I've wondered for years about it, and have used it a bit. I haven't found any authoritive discussion about it other than random posts if one gets lucky. I might know a bit more now, but a lot of others don't. I still don't know why pkg-config exists, except that it seems to avoid autoconfery, which many don't grok. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
