[GiNaC-list] questions about CLN build system [Was: about CLN versus win32 patch]

[Sheplyakov Alexei]

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 

find src -type f -name '*.cc' -or -name '*.h' 

into Makefile.am is not very compicated.

> Quite frankly, the current scheme appears much more elegant.
IMHO that deeply recursive $(MAKE) SUBDIR=$(foo) with a lot of 
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-list/attachments/20060804/9904edb7/attachment.pgp