Re: diff/Makefile.am

[Derek R. Price]

Pavel Roskin wrote:

> 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.

I thought the prescribed algorithm when distributing a package that could be
installed as a shared lib with your own was:

1)  Distribute a stable release
2)  If it is not found installed by configure, install it on 'make install'
3)  If it is found installed and the shared library version of the main package
has been built:

     a)  If installed version < packaged version, warn about it (perhaps a
     configure option makes it install?  otherwise, the answer is to make
     the user go into the package's directory and type 'make install' there)

     b)  If installed version >= packaged version, do not install

> > 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".

Is there really a good reason for that?  Libtool installs static & dynamic
libraries together with its metadata in a single directory for each library,
correct?  Why wasn't the metadata just installed in parallel as a third library
type?  i.e. a *.a, *.so, and *.la for each library would be installed next to
each other in /usr/lib or wherever?

For that matter, how hard would it be to write a workaround that installed all
three types of libraries?  At the expense of a bit of disk space, the best of
both worlds would then be available.

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:dprice@openavenue.com     OpenAvenue ( http://OpenAvenue.com )
--
BUFFERS=20 FILES=15 2nd down, 4th quarter, 5 yards to go!