From: Chris P. <chr...@ma...> - 2014-04-09 18:40:29
|
Rob, we would be grateful for your help if you want to manage the ABI version stuff for Check. I really don't have any idea what I'm doing, and I'm the one who supposedly knows autotools; plus I'm quite busy now. And you're not to blame for the problems, this is an old project with a lot of cruft and a lot of cooks tossing things into the pot. Chris Robert Lemmen wrote: > hi everyone, > > On Mon, Apr 07, 2014 at 02:54:24PM +0200, Fredrik Hugosson wrote: >>> To be clear, we should already be distributing .la, .a, .so, and >>> anything else that people want. Chris >> On my debian squeeze system, I have these files installed >> >> /usr/lib/libcheck.a >> /usr/lib/libcheck_pic.a >> >> no .la or .so >> >> Maybe it is a packaging issue? > > you can blame me for that. The reason is that if you ship an .so then > you also imply that using that .so from a program that was built against > a different version (within limits) of the library in question still > works, otherwise you have an ABI break which means you have to create a > separate package so that both can be installed in parallel. an example: > > if we were to ship .so files, and assume check version 0.9.8, then the > check packages in debian would probably be called libcheck0 and > libcheck-dev. they would provide the .so in question. If we then update > the package to 0.9.10, and know that there are no ABI breakages, we > would just update that package. If we however do not know whether the > ABI has changed, we would need to create a second package libcheck1 > which ships a different version of the same .so, with both packages > being co-installable. the libcheck-dev package would contain header > files etc that is required during compiling, and a unversion .so link to > the actual .so file which has the version number in the filename. We > then need to regularily pester people to switch to the new version so > that we are able to remove the old packages. > > this is quite a hassle, but inevitable for many libraries. for check I > felt that this was less necessaary, because only your unit tests should > be linked against the library, and surely you don't want to ship these. > therefore I don't see any problem with linking statically, I'd be > interested in hearing about any problems that I may have overlooked. > > the other aspect is how easy it is to determine ABI compatibility. > Unfortunately this something that you cannot leave to autotools, or any > tool whatsoever. it is the (ideally upstream) developers who have to > determine this carefully and set the autotools accordingly. I was under > the impression, no offence intended, that the check project isn't really > doing this very carefully. Of course I can easily be convinced > otherwise! So check developers, please let me know if you feel that you > maintain that ABI version accurately. I was basing my assumption about > this on the fact that the .so version was 0.0.0 (in version 0.9.8), and > that I think it's unlikely that this version actually is forwards and > backwards compatible with all previous check versions... > > regards robert > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > > > ------------------------------------------------------------------------ > > _______________________________________________ > Check-devel mailing list > Che...@li... > https://lists.sourceforge.net/lists/listinfo/check-devel |