On 27 Feb 2010, at 21:18, Matthias Melcher wrote:
>>> This issue will dissolve when we get back to the concept of true >>> release >>> numbers (i.e. fltk1, fltk2, fltk3, etc.) >> >> Still bugs me right now though! :-) > > Fair enough. How could we fix it though? Yup. I have no good answer for this. I thought about putting version numbers into the so name (viz libfltk. 1.3.so and so on) but then you still have to have a symlink from libfltk.so to the "correct" numbered version... Or, we assume that libfltk.so always means (or symlinks to) libfltk. 1.1.so and make sure that any code that wants fltk-1.3 is linked against libfltk.1.3.so explicitly. That's the closest I came to a "working" solution, and it does work OK. However, mostly I just link static and avoid this issue entirely. A related problem I have is what to call fltk-config, and what to do with the FL include directory... At present, I have wrapper scripts - fltk1-1-config, fltk1-3-config - that invoke the correct version of fltk-config. Of course, this means that I can't "install" fltk itself on any system, for fear of overwriting any system wide fltk-config and FL directory the distro might have... and many of them do these days. If we are really going to deploy fltk-1.3 though, we do need to find some way to version things so that they do not break any pre-existing fltk-1.1 that folk may have installed as part of their linux distro or whatever. It is tricky. -- Ian _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
