On Mon, Jun 18, 2012 at 02:10:10PM +0200, Thomas Jarosch wrote:
> On Monday, 11. June 2012 22:21:58 Thomas Jarosch wrote:
> > I propose the following changes for libftdi 1.x
> > ------------------------------------------------------------
> > - libftdi-config -> libftdi-1.0-config
> > - ftdi.h -> /usr/include/ftdi-1.0.h
> > - libftdi.pc -> libftdi-1.0.pc (pkgconfig file). Also "libftdipp-1.0.pc"
> > - we can't do much about possible man page clashes.
> > You can't prefix them in doxygen, just redirect
> > the output to a non-default directory
> > - Rename "libftdi.spec" to "libftdi-1.0.spec"
> > ------------------------------------------------------------
> >
> > Now the big question: Should we also change the library name to
> > "libftdi-1.0"? IMHO it's a good idea since broken linker flags might
> > point to the previous libftdi 0.1 and result in very bogus error
> > messages.
>
> So, any opinion on this, especially the last one?
IMHO, 95% of the use cases don't care what version of a library is
available. Even though the version number is bumped because of an
incompatible application-interface, not all users will be affected.
So I write an app. I check the changes, find nothing changes for me so
I dutifully adapt my includes to:
#include <ftdi-1.0.h>
Two years from now, my app still runs without any maintenance
required. It's something simple, so no bugs found, not many users but
those that use it are happy. A new version of libftdi comes out. 2.0!
So for the apps that still use libftdi-1.0, the headers, and libraries
are kept around. Anohter two years go by. Still my app is unmaintained
because it simply works. And it's simple: The API changes don't affect
it. But now the distributions are bored from keeping the old stuff
around. So libftdi-1.0 is dropped.
Now I HAVE to go in and change the source to say:
#include <libftdi-2.0.h>
Not happy.
So my preference would be to be able to have the code compile against
libftdi-1.0 and libftdi-2.0 without chaning any source code.
My proposal: Put an ftdi.h in /usr/include/libftdi-1.0/
Users who want to use the 1.0 version will link
/usr/include/libftdi-1.0/ftdi.h to /usr/include/ftdi.h
If there is more than one header file, we should consider recommending
to include "ftdi/ftdi.h", so that we have just one symlink to the
directory to change when you swap versions.
Now, to compile with the other version, -L /usr/include/libftdi-0.0
will suffice. Just a Makefile change.
"portable" programs that don't expect to be affected by changes in the
library even in the face of incompatible changes in libftdi will just
#include "ftdi.h" and hope for the best.
Makefiles for "portable" programs should allow setting of the library
path on the make commandline, so that in the "transition period"
should a program be found incompatible with the latest and symlinked
version users can compile with a commandline argument on the make
commandline.
Roger.
--
** R.E.Wolff@xxxxxxxxxxxx ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
