> Ok, that's one way to do it. The way we do it right now is that we > don't embed the revision of the library into the library name (that's > why we pass 3.0 and not 3.0.0 to -revision).
Well, obviously I think that's a bad idea, as you can tell by now. I don't like the idea of hiding the change inside the same filename. You sort of have to do it on Windows (apart from using assemblies) because of how DLLs load, but not on Unix. It also makes things harder for packaging, because filenames are part of what packages track. The few times I've done this for other, equally bad reasons, I've been attacked very quickly by downstreamers. > BTW, do all UNIX linkers support -version-info? I have much doubt > about AIX in this regard. I have never seen much evidence that AIX can handle any autotools-based project without pain, and I have never tried. But you could be right. Which is fine, but I would still disagree with using -release to put out different revisions with the same name as a matter of just "my sense" of how things should work. > > Why is it a requirement for them to be connected? > > Because it is in some sense an interface: the number of messages > and their relative position can change from release to release so > the major.minor version needs to be embedded into it (think of > it as another library except that it is not built with libtool). If your definition of binary compatibility is such that by definition a 3.0.1 release must have a compatible message catalog (which makes sense), then you simply wouldn't encode the minor rev into the name. As you said, this isn't a library in the same sense. -- Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
