Re: [Libevent-users] libevent-config script?

[Harlan Stenn <stenn@xxxxxxx>]

Kevin wrote:
> On Sun, Jan 2, 2011 at 6:48 PM, Harlan Stenn <stenn@xxxxxxx> wrote:
> 
> > 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.

Yes, but again, for this to be portably useful the script that is run to
do this must "just work".

The primay use =-case for this for me is OS-independent, and in this
use-case libevent will not be installed in a "standard location".  A
(libevent-specific) bin/ subdirectory will be in the PATH, however.

> > 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.

And again, you are *requiring* pkg-config, another 3rd party package, be
installed.

My goals include requiring *no* additional packages.

If interesting packages (like pkg-config) are there, I'm happy to make
use of them.

But I'm specifically targeting a bigger universe than
"current-technology linux distros".

> 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.

We generally don't bother the user with that.  We'll look for an
installed libevent (in this case) of suitable version, and if we don't
find one we'll automatically build from our bundled copy.

> 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.

Right.

> 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.

Again, our target-universe is much broader than recent Linux.

And we target both less-skilled staff, as well as automatic build
systems where no staff is required to fetch, deal with dependencies,
configure, build, and install our packages.

> > > 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.

Just because we bundle it doesn't mean we have to use it.  We've been
down this road before.

> 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.

True, but we have to support building on a *lot* of older and non-linux
platforms.

h
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.