Re: [Libevent-users] Configure changes

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

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.