[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 28 Feb 2001 18:34:04 -0500 (EST)
> > On the other hand, it's not that hard to maintain Makefile.am compared to
> > Makefile.in. If you look at that file, there is nothing to maintain except
> > a list of files.
> Yeah, but moving to Libtool is on my "sometime over the next few
You are reading my thoughts! I removed the sentence about Libtool from my
message, but you are replying to its original form :-)
> months" list. Doing that opens up the possibility of compiling with
> shared libraries. I think _this_ means that we could move to the
> Automake recommended method of including other packages (such as zlib
> & diff-utils), which is making them stand-alone sub-packages and even
> configuring them separately, so they can be installed when necessary
> and ignored when not.
This would work with zlib, but not with diff-utils. There is no
established interface to diff except the command line. The interface CVS
is using was made for CVS only. In fact, CVS is sending a command line to
the diff library, which means that the interface is immature.
If somebody writes libdiff with a generic interface, we could consider
porting CVS to it. It is not a matter of just modifying makefiles.
On the other hand, it should be possible to link CVS against external
zlib. However, I see no benefit in having libtool support for our zlib. I
would have reservations against linking something not CVS-related (e.g.
RPM) with libz.so installed by CVS.
Of course, you could try to include a stable release of zlib as is in CVS,
in which case libtool will be included, but please disable shared library
support and make sure that "make install" never descends there.
> Of course all of this is probably rather ambitious, the plan is
> somewhat dependent on my admittedly still slightly sketchy knowledge
> of Libtool, and I am fairly certain that zlib, at least, would need
> some work before this would be possible, but I figured if we could get
> a head start...
Just in case, you don't have to use Libtool on the top level for that. If
shared libraries are disabled you can safely link against static libraries
in zlib without libtool (gcc -o cvs *.o -L../zlib -lz).
Another issue is that Libtool can help you statisfy interlibrary
dependencies when linking against installed libraries produced by Libtool.
This may be useful e.g. for linking with Heimdal. However, Libtool begins
acting like a virus (to link against libtool-generated libraries you
almost have to use libtool), and I don't think that CVS should be one of
the first "victims".
> I understand not wanting to get your hands immersed that far in the
> diff-utils project, though.
Not at all. But I'm waiting for Autoconf-2.50 for the projects that are
not actively maintained.