Re: PKG_CHECK_MODULES on system without pkg-config installed?
On Fri, 11 Mar 2011, Ralf Wildenhues wrote: * Roger Leigh wrote on Thu, Mar 10, 2011 at 01:03:16PM CET: This is not meant to sound like a troll, but: is anyone really *really* using static linking in 2011? I'd love to answer no, but at least parts of the HPC crowd will do almost anything to get a couple percent more performance out of their code plus libraries. Static linking is a real low-hanging fruit there. Static linking is also nice for self-contained executables. All sorts of benefits including ease of distribution and not worrying about libraries crossing when old versions are kept for testing. I've worked on several projects where we've intentionally reverted to static linking for such reasons. They were medium-sized codebases with several libraries and executables, generally deployed to a couple dozen machines. One project in particular required that we keep all deployed versions in working order on a test server for easy use. Speed and space weren't issues. Simple correctness was. - Daniel P.S. pkg-config suffers many of the same issues as imake, but in generally less bad ways. I often need details not forseen by the pkg-config writer, and it is frustrating trying to keep multiple pkg-config environments for similar but different builds.
Re: Automake GSoC idea
[ adding the SoC list back in Cc: ] Hello, * Daniel Herring wrote on Wed, Mar 09, 2011 at 08:06:45AM CET: > Refactor Automake so it can easily be extended for new file types. Yes, this is a good idea, too. Actually, there is a pending patch from Valentin that does an important first step in this area; I wasn't sure whether he'd pick up work on this again eventually. Valentin? > Examples: > - Qt preprocessed files (e.g. moc and linguist generate sources to link) > - IDL files (may generate headers and several sources to link) > - NVidia's CUDA Yep. Actually, we even have proposed patches for QT and three for CUDA. The QT ones would need some love (more importantly, review), none of the CUDA ones can go in because of copyright assignment issues. :-( > P.S. I'm employed, but not with enough free time to mentor this. I > could help by providing case studies of tasks that aren't easy with > automake. Unfortunately, I still lack final confirmation that I can be mentor for this. In the case that I can't, we'd still need somebody for this role. Eric has agreed to be my backup mentor. Cheers, Ralf
Re: PKG_CHECK_MODULES on system without pkg-config installed?
Hello, * Roger Leigh wrote on Thu, Mar 10, 2011 at 01:03:16PM CET: > This is not meant to sound like a troll, but: is anyone really > *really* using static linking in 2011? I'd love to answer no, but at least parts of the HPC crowd will do almost anything to get a couple percent more performance out of their code plus libraries. Static linking is a real low-hanging fruit there. Cheers, Ralf
Re: PKG_CHECK_MODULES on system without pkg-config installed?
Roger Leigh writes: > This is not meant to sound like a troll, but: is anyone really > *really* using static linking in 2011? Sure; it's very useful for specialized libraries that won't be widely used enough to merit the effort to build and install as dynamic libraries. Using/creating static libraries is, after all, _very_ simple (dynamic libraries, well ... not so much). -Miles -- Quotation, n. The act of repeating erroneously the words of another. The words erroneously repeated.
Re: PKG_CHECK_MODULES on system without pkg-config installed?
On Thu, Mar 10, 2011 at 1:53 PM, Jef Driesen wrote: > You don't have to convince me of the advantages of using pkg-config. > I want to use pkg-config for exactly the same reasons as you explain. > But when I tried to build my project on a system without pkg-config > installed it failed. Proceeding without the feature (that would be enabled > through the pkg-config checks) would be perfectly acceptable, except > that autoconf fails on the PKG_* macros and aborts. So I can't build > anything at all and that's the main problem. I actually didn't use the PKG_ macros at all so I didn't run into this problem -- configure.ac searches for pkg-config using AC_PATH_TOOL and invokes it. However, I like the idea of using PKG_* m4 macros instead, and I'm disappointed to hear of your snag. Do not despair, you can use the macros on systems that have them (and not break on systems without) by using m4_ifdef to conditionalize the use. For example, this is how ntp-dev enables Automake's silent rules generation without requiring automake 1.11, which was the first release to provide AM_SILENT_RULES: m4_ifdef( [AM_SILENT_RULES], [AM_SILENT_RULES([yes])] ) Cheers, Dave Hart
Re: PKG_CHECK_MODULES on system without pkg-config installed?
On Thu, Mar 10, 2011 at 11:38:16AM +0100, Vincent Torri wrote: > On Thu, Mar 10, 2011 at 11:02 AM, Jef Driesen wrote: > > > > > mi...@gnu.org wrote: > > > Jef Driesen writes: > > >> Isn't it easier to just check for the presence of the header file and/or > > >> the library file, avoiding pkg-config entirely? > > > > > > Well, I'd prefer not to guess when possible, and not using pkg-config > > > for a package that wants you to use it means you end up guessing at the > > > proper locations/settings. Maybe this often works, but why risk it when > > > it's not necessary? > > > > I'm aware of the advantage of using pkg-config. I even supply the *.pc > > files for my own projects. But the point is that if I want to support > > systems that don't have pkg-config installed (like Mac OS X in my case), I > > have to provide a fallback with manual detection anyway. So why not skip > > pkg-config entirely? > > > > You also have to support static linking. This is not meant to sound like a troll, but: is anyone really *really* using static linking in 2011? We go through great pains to support it, but I can't even remember the last time I even /tried/ to link something statically. Maybe 2001? I do like to support pkg-config in my packages, but I don't do it for the static linking support. Is the gain actually worth the effort? Is static linking support actually tested regularly in most packages? (I suspect very much not.) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: PKG_CHECK_MODULES on system without pkg-config installed?
On Thu, Mar 10, 2011 at 10:02 UTC, Jef Driesen wrote: > I'm aware of the advantage of using pkg-config. I even supply the *.pc > files for my own projects. But the point is that if I want to support systems > that don't have pkg-config installed (like Mac OS X in my case), I have to > provide a fallback with manual detection anyway. But you are not everyone. In some cases, the use of the library is optional, or there is a bundled copy of the library used when an installed one isn't found via pkg-config. It's reasonable to provide no fallback probing for an installed headers and libs -- you just proceed without or substitute. > So why not skip pkg-config entirely? Personally, I want to never write any more manual detection code when pkg-config will do the job. I'm also a big fan of the way PKG_CONFIG_PATH lets me customize my choices as a user of a system which is shared with and administered by others. The staff likes a 6 year old version of openssl with backported patches as of three years ago, which triggers compiler warnings that modern openssl headers don't? I love that I can install a newer openssl in my homedir and arrange my PKG_CONFIG_PATH to find my openssl before the decrepit one, for packages that respect any openssl.pc found via pkg-config. I could get by without pkg-config, but it would mean specifying extra configure options repeatedly to point to my local openssl. pkg-config lets me enshrine that preference once and get on with more important things than remember which combination of overrides I need at configure time. Cheers, Dave Hart
Re: PKG_CHECK_MODULES on system without pkg-config installed?
On 10/03/11 17:14, Dave Hart wrote: On Thu, Mar 10, 2011 at 1:53 PM, Jef Driesen wrote: You don't have to convince me of the advantages of using pkg-config. I want to use pkg-config for exactly the same reasons as you explain. But when I tried to build my project on a system without pkg-config installed it failed. Proceeding without the feature (that would be enabled through the pkg-config checks) would be perfectly acceptable, except that autoconf fails on the PKG_* macros and aborts. So I can't build anything at all and that's the main problem. I actually didn't use the PKG_ macros at all so I didn't run into this problem -- configure.ac searches for pkg-config using AC_PATH_TOOL and invokes it. However, I like the idea of using PKG_* m4 macros instead, and I'm disappointed to hear of your snag. Do not despair, you can use the macros on systems that have them (and not break on systems without) by using m4_ifdef to conditionalize the use. For example, this is how ntp-dev enables Automake's silent rules generation without requiring automake 1.11, which was the first release to provide AM_SILENT_RULES: m4_ifdef( [AM_SILENT_RULES], [AM_SILENT_RULES([yes])] ) I noticed there are projects (see for example [1]) that ship the pkg.m4 file, and then add this line in configure.ac: AC_CONFIG_MACRO_DIR([m4]) and in the toplevel Makefile.am: ACLOCAL_AMFLAGS = -I m4 I haven't tried this yet, but I assume it works. But I wonder what happens on a system that does have pkg-config installed. Does it use the system wide pkg.m4 file or the local one? If it's the local one, then the downside is that you have to keep this file up-to-data. But other than that it looks like the best option. [1] http://mailman.videolan.org/pipermail/libbluray-devel/2011-February/000232.html
RE: PKG_CHECK_MODULES on system without pkg-config installed?
daveh...@gmail.com wrote: > On Thu, Mar 10, 2011 at 10:02 UTC, Jef Driesen wrote: > > I'm aware of the advantage of using pkg-config. I even supply the *.pc > > files for my own projects. But the point is that if I want to support > > systems > > that don't have pkg-config installed (like Mac OS X in my case), I have to > > provide a fallback with manual detection anyway. > > But you are not everyone. In some cases, the use of the library is > optional, or there is a bundled copy of the library used when an > installed one isn't found via pkg-config. It's reasonable to provide > no fallback probing for an installed headers and libs -- you just > proceed without or substitute. > > > So why not skip pkg-config entirely? > > Personally, I want to never write any more manual detection code when > pkg-config will do the job. I'm also a big fan of the way > PKG_CONFIG_PATH lets me customize my choices as a user of a system > which is shared with and administered by others. The staff likes a 6 > year old version of openssl with backported patches as of three years > ago, which triggers compiler warnings that modern openssl headers > don't? I love that I can install a newer openssl in my homedir and > arrange my PKG_CONFIG_PATH to find my openssl before the decrepit one, > for packages that respect any openssl.pc found via pkg-config. I > could get by without pkg-config, but it would mean specifying extra > configure options repeatedly to point to my local openssl. pkg-config > lets me enshrine that preference once and get on with more important > things than remember which combination of overrides I need at > configure time. You don't have to convince me of the advantages of using pkg-config. I want to use pkg-config for exactly the same reasons as you explain. But when I tried to build my project on a system without pkg-config installed it failed. Proceeding without the feature (that would be enabled through the pkg-config checks) would be perfectly acceptable, except that autoconf fails on the PKG_* macros and aborts. So I can't build anything at all and that's the main problem.
Re: PKG_CHECK_MODULES on system without pkg-config installed?
Miles Bader writes: > I don't even try to fully support systems without pkg-config, I > basically just want a fallback so I can get some sort of build on them, > maybe with some features disabled. I should note that although this is my tactic, it's not actually a very important point. For the rest of the reasons mentioned, _even if_ one wants to fully support systems without pkg-config (so one has to add the manual probing code), it's still a good idea to just support both methods: supporting pkg-config doesn't add much complexity to the configure.ac file (the bloat is the manual probing code), and for systems that _can_ benefit from it, it yields superior results. -Miles -- Ocean, n. A body of water covering seven-tenths of a world designed for Man - who has no gills.
Re: PKG_CHECK_MODULES on system without pkg-config installed?
On Thu, Mar 10, 2011 at 11:02 AM, Jef Driesen wrote: > > mi...@gnu.org wrote: > > Jef Driesen writes: > >> Isn't it easier to just check for the presence of the header file and/or > >> the library file, avoiding pkg-config entirely? > > > > Well, I'd prefer not to guess when possible, and not using pkg-config > > for a package that wants you to use it means you end up guessing at the > > proper locations/settings. Maybe this often works, but why risk it when > > it's not necessary? > > I'm aware of the advantage of using pkg-config. I even supply the *.pc > files for my own projects. But the point is that if I want to support > systems that don't have pkg-config installed (like Mac OS X in my case), I > have to provide a fallback with manual detection anyway. So why not skip > pkg-config entirely? > You also have to support static linking. Vincent
Re: PKG_CHECK_MODULES on system without pkg-config installed?
Jef Driesen writes: > I'm aware of the advantage of using pkg-config. I even supply the *.pc > files for my own projects. But the point is that if I want to support > systems that don't have pkg-config installed (like Mac OS X in my > case), I have to provide a fallback with manual detection anyway. So > why not skip pkg-config entirely? I don't even try to fully support systems without pkg-config, I basically just want a fallback so I can get some sort of build on them, maybe with some features disabled. So what I do is use PKG_CHECK_MODULES for normally pkg-config'd packages. It's very concise and easy to use (one line per library, normally). On systems without pkg-config, this will just fail as if the package wasn't installed at all. For a few of the most critical libraries, I use both PKG_CHECK_MODULES (it yields better results when available, is almost trivial, and the support infrastructure is present for other packages anyway), _and_ more traditional probing code as a backup (but see below why it's annoying). > And I could simply replace the pkg-config based check with something like: Even that -- rather verbose -- code often isn't enough, because install locations can vary between systems, in a manner that varies from package to package. In such cases, you can either require the user to specify the location with a configure option (and I want to avoid require user input if at all possible), or you can add a loop to guess various common configurations (which make the configure code somewhat more complex as well as being more likely to yield incorrect results). [Note, all of this results from trying to compile on systems where something didn't work!] -Miles -- Faith, n. Belief without evidence in what is told by one who speaks without knowledge, of things without parallel.
RE: PKG_CHECK_MODULES on system without pkg-config installed?
mi...@gnu.org wrote:
> Jef Driesen writes:
>> Isn't it easier to just check for the presence of the header file and/or
>> the library file, avoiding pkg-config entirely?
>
> Well, I'd prefer not to guess when possible, and not using pkg-config
> for a package that wants you to use it means you end up guessing at the
> proper locations/settings. Maybe this often works, but why risk it when
> it's not necessary?
I'm aware of the advantage of using pkg-config. I even supply the *.pc files
for my own projects. But the point is that if I want to support systems that
don't have pkg-config installed (like Mac OS X in my case), I have to provide a
fallback with manual detection anyway. So why not skip pkg-config entirely?
Most libraries have only very standard stuff in there pkg-config file, like
this:
Libs: -L${libdir} -lusb-1.0
Cflags: -I${includedir}/libusb-1.0
And I could simply replace the pkg-config based check with something like:
AC_CHECK_HEADER([libusb-1.0/libusb.h],
AC_CHECK_LIB([usb-1.0], [libusb_init],
[have_libusb=yes],
[have_libusb=no]),
[have_libusb=no])
if test "$have_libusb" = "yes"; then
AC_DEFINE([HAVE_LIBUSB], [1], [Define if you have the libusb library and
header])
AC_SUBST([LIBUSB_CFLAGS], [])
AC_SUBST([LIBUSB_LIBS], [-lusb-1.0])
fi
Jef
Re: Autotools GSoC ideas
Hi, On Wed, Mar 09, 2011 at 08:52:39AM +0100, Stefano Lattarini wrote: > OK. If you say that a more fuzzy proposal shouldn't cause problems at > this point, I'll follow your lead. In our experience, fuzzy proposals do not work well. Very few students are up to making design decisions -- and considering that they are usually new to the projects, it would really be demanding quite a lot... -antrik-
