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 <ni...@freehaven.net> wrote: > 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. >
