#6 CMake build support

[Sandro Mani]

Recently you removed the autotools build system in favour of hand-written makefiles. While I appreciate the fact that autotools is not the most pleasant buildsystem, the hand-written makefile unfortunately breaks library versioning (missing -Wl,-soname -Wl,libgif.so.$(LIBMAJOR) in the libgif.so rule) and does not allow cross-compiling (i.e. to mingw) without very heavy patching.

While all issues can be fixed in the hand-written Makefile, it would add a certain level of complexity which I suppose defeats the goal of having a readable build script. For this reason, I'd like to propose to switch back to a proper build system, and I suppose a good candidate would be CMake. Find a port of (most of) the current Makefile to CMake attached. I believe it is as readable as the hand-written makefile, but makes life for downstream distributors so much more pleasant.

Thanks

[Sandro Mani]

Updated CMakeLists.txt

[Eric S. Raymond]

I've already fixed the siname problem, and I've received a patch which implies that the only change rquired for cross-compilation is to replace ar with $(AR). What other changes do you believe are required tp support cross-compilation from the makefile?

I'll go with cmake if those changes look too complicated, but right now it doesn'yt look like a win. One issue is that the makefile gets the version number it uses by inspecting the gif_lib.h header file, meaning there is a single point of truth about the version. Your cmake recipe breaks that; it would require me to manually sync the version in two different places,

[Sandro Mani]

So, taking mingw32 as the cross target, a couple of examples:

• The command for building a DLL should look something like

i686-w64-mingw32-gcc -O2 -g -pipe -shared -o libgif-7.dll -Wl,--out-implib,libgif.dll.a -Wl,--major-image-version,7,--minor-image-version,1 <object_files></object_files>

• Installing should give you a libgif.dll in bindir and a libgif.dll.a in libdir for the shared library build, and a libgif.a in libdir for the static library build. There are no symlinks.

• Executables need to have *.exe extension

And other cross-compilation targets have their own special rules.

And another point, out of source builds are not possible with the current Makefile. Out of source builds however are very convenient when packaging, as you can build for multiple targets out of the same source tree.

As for the version number, this could be easily done also with cmake, an I'm happy to provide an example if desired. The other often used approach is to set the version number as a variable in CMakeLists.txt and then generate the header with the version number as a preprocessor variable.

[Eric S. Raymond]

I am totally uninterested in supporting Windows, so that's not persuasive.

If you can post a cmake recipe that properly extracts the version number from the existing header file, I'll consider it. What I will be weighing in that case is whether I think the the Makefile or cmake recipe will be easier for me to to read and modify in the future.

[Sandro Mani]

Well actually that is an argument for using a build system which takes care of handling all those annoying difference between various targets (and windows is just one example here, other platforms also have their own differences), so that you don't need to put all that much thought into it (i.e. if you look at the proposed CMakeLists.txt, you'll find that WIN32 is just mentioned one single time for adding a library suffix, which is just for following the convention how autotools does it and more generally often adopted in the mingw world).

Also please note that giflib is a dependency for various other projects, so downstream packagers will need to build it one way or the other. Either each packager carries his own homegrown patches downstream, or we attempt to work with upstream to ensure stuff works for everyone, which in the long run make life easier for everyone.

As for extracting the version, actually the

execute_process(COMMAND ./getversion
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
OUTPUT_VARIABLE VERSION
OUTPUT_STRIP_TRAILING_WHITESPACE
)

block already takes care of it, i.e. the VERSION variable will contain the version extracted via the getversion script. Is anything else missing?

[Eric S. Raymond]

After due consideration, I'm rejecting this approch.

CMake is tioo heavyweight. I choose to stick with a plain Makefile

[John Cupitt]

Hello, thank you for this useful library.

I help maintain libvips and we use giflib for GIF loading. libvips is one of the larger image processing libraries -- the node binding sees about 400,000 downloads a week, for example.

Without either cmake or autotools, we will be forced to switch away from giflib. I know gegl and gdk-pixbuf at least have already moved away because of this issue.

Would you reconsider? Hand-written makefiles are costing giflib users and creating extra work for downstream projects.