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] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
