[xorg] Re: CMake (was More about x-packages)

[José Fonseca]

On 12/23/07, Daniel Stone <daniel at fooishbar.org> wrote:
> > "Convinience libraries" are temporary libraries that will be linked
> > into SOs and will not be released by themselves. The problems with
> > these convenience libraries is that: a) linking a static library into
> > a SO is not guaranteed to work, unless the static library was compiled
> > with the proper compilation flags, and b) it does not fit into CMake's
> > general approach for libraries quite well.
>
> Right.  At the moment, I'm not talking about linking static libraries
> into shared objects (Debian people tend to have a better appreciation
> than most of the problems inherent here), nor am I talking about
> shipping static libraries.  I'm talking about the convenince libraries
> (of which there are over 112) in the server, which are compiled once,
> never installed, and then linked multiple times into every server[0].

> How does CMake solve this problem, apart from 'badly'?

I'm not very familiar with KDrive, but the situation that you describe
(static libraries, statically linked into many executables, and never
installed) poses no problem to CMake AFAIK. You can decide with CMake
which libraries get or not installed. Furthermore, CMake makes it easy
to cope with many static libraries, since whenever you specify that a
static library shall be linked, CMake automatically links all the
recursive dependencies of that library (static or dynamic).

> Having to hack
> CMake internals to support convenience libraries and do things very
> non-portably sounds about as good as, well, having to hack automake
> internals to get rid of libtool for shared objects.

That's quite a true statement. And that situation will surely arise
if/when you cross the "dynamic bridge" you mention below. CMake has
portability going for it, but it is by no mean one-size-fits-all
solution, especially because portability implies compromises. And
there's then all sort of problems that will only be noticed when one
actually tries to use it...

If it's worth it or not for Xorg to switch from autotools to CMake is
a something that I don't really feel entitled to say. But if X.Org
doesn't care for non-unix portability (and I mostly mean Windows here)
then there isn't that much to be gained by switching to an unfamiliar
build system as CMake.

> Cheers,
> Daniel
>
> [0]: Yes, some of these are linked into .so's which are later
>      dynamically loaded by Xorg.  Imagine Xorg doesn't exist and that
>      we're talking about KDrive, and then we'll cross the dynamic bridge
>      when we come to it.

José