From: Hans U. N. <gp...@n-...> - 2005-02-09 22:09:43
|
Hi, I have started to do something libexif, libgphoto2 and Co. have needed for quite some time: To get away from the ugly autogen.sh solution using gettextize (you will remember that forced manual keypress). You can read ChangeLog and the CVS log messages to libexif-cvs for the complete details, but I'll write a short summary here: Usage: cvs co libexif cd libexif ./autogen.sh ./configure --prefix=3D/foo make check make install make uninstall make distclean ./autogen.sh --clean and you should have a system which is clean again :) Changes: =3D complete redesign of autogen.sh + use autoreconf (comes with autoconf) to automagically do the right thing instead of home-brewn solution manually calling autoconf, aclocal, autoheader, libtoolize, gettextize, etc. + autoreconf calls autopoint instead of gettextize - no more keypresses while building, no more modifications of configure.in, Makefile.am, ChangeLog. + moved a number of common definitions from the single Makefile.am files to a central place - configure.in. + misc. small stuff - Downside: Building from CVS requires a newer toolset. Too old are: autoconf 2.50, automake 1.4, gettext < 0.14.1 autoconf 2.59, automake 1.8 and gettext 0.14.1 will work find, and have been releases more than a year ago. What works: + intl/ gets shipped, unlike 0.6.11 + Building a .so library on Linux works flawlessly (tested) + I can build a Windows DLL file without NLS support + on a Linux system using a MinGW crosscompiler (tested) + on a Windows system using Cygwin (tested) + You can now build in the CVS tree without having something modify existing files (OK, the *.po files don't count :) What doesn't work: - The included libintl doesn't use libtool to build, which makes it non-trivial to build a DLL with intl support. So Windows users will have to live without i18n for now. - Building from CVS with antique build tool set. Considering the age of the supported tools and that libexif addresses developers not end users, this should be acceptable. A word on the Windows support: Windows is an environment which is very unfriendly to programmers according to my personal experience. This means that I (personally) don't intend to create or maintain a real Windows port or something like that, but the new build system builds for Windows without any additional costs, so I'm fine with that. I think this is a lot better than the stuff we had previously, but I'd appreciate any feedback - be it positive or negative (degradation). If this thing works out well here, I'd like to move * exif, libexif-gtk, gexif and * libgphoto2, gphoto2, gtkam to the same autogen.sh script and do the corresponding changes to configure.in and **/Makefile.am over the next few weeks and months. I've just started with libexif because libexif is quite small, and libexif development currently isn't all that hectic. Gru=C3=9F, Uli =2D-=20 Some gphoto2 links: http://www.teaser.fr/~hfiguiere/linux/digicam.html http://gphoto.sf.net/ http://n-dimensional.de/projects/digicam/ #gphoto on irc.freenode.net http://sf.net/projects/gphoto http://sf.net/projects/libusb http://sf.net/projects/libexif |