Re: [Libevent-users] Configure changes

[Ralph Castain <rhc@xxxxxxxxxxxx>]

Hi Nick

I have greatly simplified the changes so that configure.in only adds two lines to it, each of which is a call to a separate AC function. So the changes are now quite contained. I'll put them in the tracker later this week (I'm currently on travel).

I can insert the actual copyright text. You are indeed free to use the code (we checked to ensure our licenses are compatible) - just need to include the copyright.

As for changing the tests to run-time: I think it's a little bit of pro/con. The advantage is as you state - cross-compile is always an issue. The disadvantage is in startup time for a process as running a bunch of tests doesn't come for free.

What I have done in the port is retain some of both options. You can configure out functionality, and you can set run-time options to select/deselect various modes. So I don't consume time running tests at run-time, but do allow a user to specify "I want to run with these modes", and gracefully fail-out if they aren't available. Note that configuration tests are -not- run in cross-compile mode - if you configure an option "in" when cross-compiling, libevent is built with that support (it does not run a test to see if it works).

Not quite what you describe, but like I said - in our world, process startup time is important (we get beat up about every second), and in our experience, it is rare that someone configuring a cross-compile version doesn't know what methods are going to be supported on the backend.

As for the embedded vs non-embedded configuration: I chose to add an "--enable-embedded" configuration option to your configure.in that ensures symbols are hidden and does whatever else might be suitable for such environments.

HTH

Ralph

On Mon, Sep 13, 2010 at 8:24 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:

On Tue, Sep 7, 2010 at 2:31 PM, Ralph Castain <rhc@xxxxxxxxxxxx> wrote:
> Hi folks
> Continuing the discussion re pushing some of Open MPI's experiences
> upstream, I have attached our opal_setup_libevent.m4 script for building
> libevent as part of OMPI. Note that the comments describe several scenarios
> where the existing libevent tests aren't quite adequate for detecting when
> various functionality should be "on" vs "off". These have been rather
> thoroughly tested by the respective developers, so we offer them to you for
> consideration.
> I also have added a set of options to your configure.in and associated files
> that might prove useful. Nothing profound - they just allow users to
> "deselect" certain support options (e.g., DNS, http). I've attached a diff
> (options.diff) that shows the changes, though I suspect you'll want to clean
> them up.
> HTH
> Ralph

Thanks, Ralph!

It would be great if you can upload these to the patch tracker at
sourceforge [1] ; I would hate to lose track of them between now and
when we fork 2.1.x.

Re licensing: The opal_setup_libevent.m4 file has a huge pile of
copyright statements on it, but no actual license.  FWICT, that means
I am  have permission to use it.  Could you slap one on?  It's also
pretty clearly made (in parts) by changes to Libevent's configure.in
(many of the lines are identical), but it looks like when the preamble
got chopped off, Dug Song's credit for the original version got
chopped off too.

Once that's cleared up, it would be cool to start picking this apart
to figure out which parts are improvements or new features and which
parts are just porting Libevent's configure.in to be embedded.
Anything that constitutes a bug in 2.0.x should get fixed now (if
feasible).  Anything else can wait for 2.1.

Oh, and a random code strategy thought: it seems to me that testing at
compile-time for poll and epoll and kqueue behavior is subtly
suboptimal.  Consider a program built to use one linux kernel where
epoll works that's run with another where epoll doesn't work. That's
pretty much a poster case for a run-time check.  (Yes, I know that
libevent already does some compile-time checks for backend
correctness, but I'm not sure that they're actually the right thing to
do.)  In 2.1.x, we should see if we can make more of these checks
happen at startup time (as feasible).  This should also improve
correctness in the cross-compilation case, where you can't do a
compile-time check that involves running code.

So, to summarize:
 * Thanks!
 * Patch tracker [1].
 * License.
 * Let's figure out what's a bugfix.
 * I think we should migrate to doing fewer "does this backend work"
checks at compile-time.

[1] https://sourceforge.net/tracker/?group_id=50884&atid=461324

peace and thanks again,
--
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.