On Thu, Aug 03, 2006 at 10:11:26PM +0200, Richard B. Kreckel wrote:
Sheplyakov Alexei wrote:
Okay, but as I mentioned: not all auto* tools are used.
What is (was) the reason of that? Would you accept a patch which converts CLN build system to usual automake/autoconf/libtool?
Let's ask undogmatically: What would be the reason for converting CLN? The point is to compile CLN easy not only on particular version of particular GNU/Linux distro.
The user who wants to compile the library is confronted with the well-known configure / make / make install steps. Before that one needs re-libtoolize the package (otherwise compilation fill fail). I don't think this step is well-known or easy.
So, there's adherance to quasi-standards. I'm not an expert at building libraries (and even if I were, I won't re-invent the wheel anyway), so I use tools written by others: libtool _and_ automake.
The developer will have to remember that Makefile.devel will have to be used instead of autoreconf. Big deal. Yes. Maintaining your private build system is not that easy.
It is already autoconfed and libtooled. Manully writing proper rules for libtool is a compilcated task. Rules in CLN's Makefile.in contain a lot of errors. For example,
LIBTOOL_COMPILE = $(LIBTOOL) --mode=compile %.lo : %.cc $(LIBTOOL_COMPILE) $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c $< Invoking make as make -j2 CC='distcc gcc' CXX='distcc g++' will result in cd src && make all make[1]: Entering directory `/tmp/obj/src' make SUBDIR=base make[2]: Entering directory `/tmp/obj/src' /bin/sh ../libtool --mode=compile distcc g++ -O -I../include -I/mnt/host/home/pc7135/varg/src/cln-1.1.12/include -I/mnt/host/home/pc7135/varg/src/cln-1.1.12/src/base -c /mnt/host/home/pc7135/varg/src/cln-1.1.12/src/base/cl_debug.cc /bin/sh ../libtool --mode=compile distcc g++ -O -I../include -I/mnt/host/home/pc7135/varg/src/cln-1.1.12/include -I/mnt/host/home/pc7135/varg/src/cln-1.1.12/src/base -c /mnt/host/home/pc7135/varg/src/cln-1.1.12/src/base/cl_debugout.cc libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[2]: *** [cl_debugout.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... The rule should be something like CXXCOMPILE = $(LIBTOOL) --tag=CXX --mode=compile %.lo: %.cc $(CXXCOMPILE) $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c $< But that is not the end of the story, since source dependencies are not taken into account: change some header file, and run make, wait for a while (due to recursive make) and nothing gets recompiled! Yet another example is using C compiler (instead of C++ one) when linking, this was the reason of many weird linker errors (see, e.g. http://www.ginac.de/pipermail/ginac-list/2005-October/000749.html) I think fixing such errors is even much more complicated then using automake.
The only thing is that it carries its own copy of some files, but that is (was?) for a good reason: It enabled us to actually create the configure script when we needed to despite disruptive changes in the macro repository in Debian/RedHat/whatever.
The library with obsolete libtool is going to FTBFS (in a very weird way), so what is the point of generating non-working configure script?
Okay, so what about automake? CLN's sources are modularly structured in a deep hierarchy, not a flat or shallow one. All of these object files end up linked into a single library, so in fact it is *flat*.
If I'm not mistaken, converting it to automake would involve putting a Makefile.am in every directory (there are 107 of them) Incorrect. BTW, there are already Makeflags files in (almost) every directory.
and having to list at least every .cc file (there are 854 of them). Yes, automake requires this (for good reason which is explained in the manual). Anyway, inserting the output of
Quite frankly, the current scheme appears much more elegant. IMHO that deeply recursive $(MAKE) SUBDIR=$(foo) with a lot of
find src -type f -name '*.cc' -or -name '*.h' into Makefile.am is not very compicated. directory-specific preprocessor flags is ugly. But that is a matter of taste, the problems are 1) It is not obvoius what file gets included by #include "cl_foo.h". 2) Re-compilation after changing a couple of files takes unnecessary long time.
Sure I would accept a patch if it was lightweight and elegant and worked well. It does work well, but it is not lightweight.
But I don't think I'm ever going to see one. And I'm sure that pursuing such a patch is not worth the effort since it would only save a couple of minutes of every aspiring maintainer (how many of these are there?). It would save _a lot_ of time for many CLN users.
Best regards, Alexei. -- All science is either physics or stamp collecting.