I am saddened that you have responded with such ferocity -- calling me a liar and making several other derogatory statements.
Your docs state: "The goal is to enable you to just copy the neecssary files into your source directory without having to change even a single line in them, so you can easily upgrade by simply copying ***(or having a checked- out copy of libev somewhere in your source tree)***." (I added the emphasis, obviously) Having a checked out copy of libev (or, more precisely, an expanded tarball) is exactly what I want. And I wanted to use your Makefile.am. I have tried to explain why, I have given code examples, and I have cited that it's a common AC/AM/LT model. I've even been polite in the presence of overwhelming hostility. I freely admitted that I got my first posts all wrong and I totally bozoed by missing the docs. But somehow, my asking for a feature has resulted in rather fierce attacks. I have come to the sad conclusion that your hostility makes further discussion pointless. FWIW, thanks for the software. It will probably help us quite a bit. On Dec 18, 2007, at 8:59 PM, Marc Lehmann wrote: > On Tue, Dec 18, 2007 at 10:45:04AM -0500, Jeff Squyres <[EMAIL PROTECTED] > > wrote: >>> write your own Makefile.am. >> >> I think that much of your verbiage is repeatedly saying that you >> disagree with me on this point. :-) > > No, I am telling you how it is, and you keep repeating you want it > different but never give reasons. > >> If we have a checked-out version of libev (or an expanded tarball), >> then we have your Makefile.am. I'd like to use what you provide, not >> have to work around it because only some parts are suitable for >> embedding and others are not. > > If you want to do it the wrong way, you are on your own, thats all I > cna say > on that issue: As many times as you repeat it, if you want to do it > your way > regardless of how it is supposed to be done, and if you want to make > it more > complicated than neecssary, then you are on your own. > > I only support the simple, normal way of doing this. If you simply > want to do > it differently thats certainly possible by the license, but thats your > problem. > >>> Already possible, as you can easily do that yourself, too, even >>> programmatically. >> >> I assume that you are saying that the project embedding libev can do >> this (not the libev-provided .m4 / Makefile.am). And yes, of course >> we (Open MPI) can. I'm just saying that it would be nice if libev >> provided all of the embedding glue and didn't require additional glue >> from the upper-level package. > > Yes, you keep making that claim, but since you never ever substantiate > that claim, it can easily enough be ignored. If you make a claim you > should > give evidence on why this would be true, as I can see no reason for > that. > > And quite obviously I will not be bothered making senseless changes > just > because you claim it would be nice when, in fact, it would reduce > the quality > and ease-of-use of the library without giving any advantage, except > that you > then think it would be nicer. > > Or ot put it differently, your unexplained desires have no technical > merit > on their own. > >> I see no mention in http://pod.tst.eu/http://cvs.schmorp.de/libev/ >> ev.pod of how the Makefile.am is not intended to be embedded, nor >> anything about renaming all the public symbols. > > You will also not find anything in ev.pod that says that killing > people > is good or bad. Or that compressing the sources with bzip2 is better > than with lzop, or about any of the 127 other ways of doing things. > The > documentation explains how you embed it, it doesn't need to explain > how it > is not done. This is completely nonsensical. > > I don't understand this way of arguing at all, sorry. Try it with > logics. > >> No need to be nasty to a new user who is just asking some >> questions... :-) > > People who refuse to read the documentation, who refuse to > substantiate their > empty claims with arguments and people who make nonsensical > arguments are > damage that needs to be routed around. > > You are a liar, too, you are not "asking some questions" as you want > to make people believe. You are making up epical stories of what you > would like to do and how this cannot be done and what needs to be > changed > (without giving reasons) and how these weird ways of doing things > are not > mentioned in the documentation. > > Where are the questions? I do not see this. > > Please don't give me more of your rethorics: If you have questions, > then > please read the documentation and afterwards ask your questions. > > But claiming you are "just asking questions" when in fatc you are > only troling > without actually asking questions is pointless. > > Again: the documentation explains how you embed libev, in a way that > works > and has been proven. If you have questions that are not answered > there, > please feel free to ask them. > > The only unanswered question is how you best rename the symbols, and > that is > not actually a question you asked, but I nevertheless offered to > answer. > > If there is anything else, feel free to aks, but please stop > trolling like > this. > >> We have a different bias / way of doing things that is apparently >> "new" to this community. > > There is no "this community" and there is no "bias". Libev defines > how it is > being embedded. If you want to do it differently for no given > reason, you are > on your own. > > Note that this is yet another claim and not "just a question". > >> I don't understand why you think this is so difficult or weird; it is >> certainly a documented and supported way of using Automake and >> Libtool. > > I say it is more difficult because it is more difficult, you need to > create a Makefile.am, make it configurable etc. > > The documented way is clearly much simpler: you only have to copy and > paste and adjust your existing makefile a tiny bit. It is also much > better > documented. > > It is weird because you give no reasons for doing it the more > difficult > way. > > That you can do it otherwise is no argument against the other method > being > more complicated. > >> If projects that are using the AC/AM/LT model have to write >> their own wrappers for their configure/build system, then the "not >> modifying libev source" promise is half-empty, > > They do not have to do that when they follow the method documented. > They only > need to do that when they want to do it your way. > > So please don't use inverted logic here by claiming xyour way is bad > and I > would force it when in fatc the opposite is the case. There is no > need for > any configure/build system wrappers of any kind, pelase stop making > bogus > claims. > > If anything in the documentation is unclear, please tell me. But > spreading > this bullshit won't help you in any way. > >> IMHO: yes, you don't >> have to modify the libev source, but you have to provide your own >> configure/build source and possibly modify it over time because the >> libev configure/build stuff is not guaranteed to be a stable >> interface >> (e.g., the list of functions to be renamed). > > Bullshit: When embedding a library you of course *must* provide your > own > configure/build source already as you have to build your own project > already. The fact that you add libev doesn't change that. > > Claiming that libev requires this when in fact it doesn't certainly > doesn't make me think you know what you are talking about. > > Note that here again there is no questions, just wrong claims and > rethorics. > >> libev; we'll cope (we'll likely have to use the approaches you >> mentioned, but we would prefer to use the method I mentioned above). >> If you choose this route, please: a) add this point to your fine >> documentation, and b) do not berate someone for asking about it. :-) > > There is no need to add something to the documentation: It is only > logical > that if you deviate from the method documented you might run into > problems > not mentioned there. Using undocumented functionality, in general, is > always possible, but its clear that you get to keep the pieces: The > reason > it is not documented is that you cannot rely on it being there or > being > supported. > > It is idiotic to ask for irrelevant things to be documented, or all > the > possible ways of not doing it, when the documentation clearly spells > out > how to do it the right way. > >> Ah, a misunderstanding: Open MPI will not install any of libev's >> header files > > ok. > >> As I understand the other projects that are using libev, they are >> applications and plugins. They are not libraries themselves (that >> are >> linked to by other applications). > > EV is a library. > >> In a later e-mail, you proposed providing a text file with all the >> public symbols. That's fine > > Ok, will be part of the next release, it is already part of CVS and > documented. > >> add more glue to our configure / build system to create a .h file >> with >> all the #define's (and be smart about generating this .h file so that >> we don't cause all dependencies to be rebuilt when the list of >> symbols >> hasn't changed, similar to how AC won't re-generate config.h if it >> hasn't changed). > > Wrong: your build system does not need to generate the file at build > time, > no special logic is required, you only need to do this when > integrating a > new version of libev, i.e. when coding. > > The file is not dependent on anything thats created dynamically. > >> Sure, we could do that, but it certainly would be >> nice if libev were fully self-contained. > > libev is already fully self-contained, so your argument is false. > >> That would be great (that's off the top of my head; I'm sure that you >> can poke holes in it -- it will likely require a little more > > This doesn't achieve your goal, though, nothing will be prefixed > that way. > >> Yes, I can see how that would be a problem. >> >> Aren't signals stackable such that multiple libev's could all get >> invoked when a signal is invoked? (I didn't look into how libev >> implements its signal handling) > > man signal (ISO C) > man sigaction (POSIX) > > this is a beginner unix programming question, it has nothing to do > with > libev. libev provides this stacking, as any good event library > should do. > > And no, this is not mentioned in the documentation: basic C langauge > knowledge is required to be able to use libev, likely an even higher > level > of profession is required. > >> Failing that, is there any way to detect that there are two libev's >> running in a single process such that if both of them tried to do >> something with a global resource, it could be detected? > > To what point, crashing differently? No, there isn't a reasonable > way to > do that. > >> of "collision" error code were returned by libev, the caller could >> print a friendly error message (or handle it in some other way). > > How? by crashing in a different way? > > Thats pretty pointless. > > -- > The choice of a Deliantra, the free code > +content MORPG > -----==- _GNU_ http://www.deliantra.net > ----==-- _ generation > ---==---(_)__ __ ____ __ Marc Lehmann > --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] > -=====/_/_//_/\_,_/ /_/\_\ -- Jeff Squyres Cisco Systems _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
