On Tue, Sep 7, 2010 at 2:31 PM, Ralph Castain <r...@open-mpi.org> 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 majord...@freehaven.net with unsubscribe libevent-users in the body.
