Kevin wrote:
> On Sun, Jan 2, 2011 at 5:54 AM, Harlan Stenn <
stenn@xxxxxxx> wrote:
>
> > A number of different packages will install foo-config in the PATH to
> > make it easy to figure out if the package installed and what options
> > should be used.
> >
> > Anyway, I was wondering if libevent could install something similar.
> >
> > I'm looking for path information (include and library) and any needed
> > CPP, library, etc. flags.
>
> libevent provides pkg-config files that should do the same as these helper
> programs. You can run shell program
> 'PKG_CONFIG_PATH=/foo/libevent/lib/pkgconfig/ pkg-config' to get the
> information you desire on stdout.
But that (mechanism) assumes you know where libevent was installed
(which is a local policy choice).
I think the tradeoff is reasonable. If the pkg-config files exist in a
standard location (/usr/lib/pkgconfig, /usr/local/lib/pkgconfig), no environment variable is needed. If it doesn't, a
shell PATH env var would be needed for a standalone program.
So if the answer is "Let's produce a libevent-config program that is a
1-liner that does this" then that may be an OK answer. It would require
pkg-config to be installed though, and I'm interested in this capabilty
for *portability*, and making folks install even more software is not
the way I'd like to see this evolve.
pkg-config will handle everything in your third paragraph out of the
box. Test for libevent of a specific version. If that fails, abort the
build and tell the user to pass ./configure a bundled libevent flag if
they desire or point to the correct system path. That flag would do a recursive autoconf build with SUBDIRS
and link directly to the internal copy of libevent. Linking internal would be based on the build root, not pkg-config so you could even test against whether pkg-config is installed or not and offer a workaround. pkg-config is pretty much universal on Linux (used by glib) and available for most commercial Unix in repos sys admins are savvy to so I don't think it's a problem in practice.
> pkg-config also has nice Autoconf macros.
I don't know exactly what you mean by that, but it's where I was gonna
go next, as I also need autoconf macros to do some things with libevent
(like see if a local version exists, and is at a suitable version level.
If so, we can use the existing, installed libevent. Otherwise, we
should configure, build, *possibly* install, but link against, libevents
that is included in the "parent" package).
Also, some food for thought. Since you are talking about users building
from source, I'm guessing this is FOSS. If that's the case, you should
avoid bundling libraries like libevent if you have any desire for
inclusion in distros like Debian, Fedora, and Gentoo. Now that libevent
2.0.10 is "stable", we should start seeing it in the next round of
releases. Users of older releases like RHEL are used to jumping through hoops to build software.