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

[José Fonseca]

On 12/23/07, Daniel Stone <daniel at fooishbar.org> wrote:
> On Sat, Dec 22, 2007 at 04:02:06PM -0800, Alan W. Irwin wrote:
> > On 2007-12-22 21:02-0000 Daniel Stone wrote:
> >> Yes, real libraries are good, but they won't work for the X case due to
> >> design that assumes everything's linked into the same final object, and
> >> also due to the fact that they're, well, not real libraries.  We don't
> >> make API guarantees for internals.
> >
> > I would appreciate your comments on the following idea, but please be gentle
> > if I have wandered beyond my depth.  :-)
> >
> > The idea is to directly replace a convenience library (a collection of
> > compiled objects according to
> > http://sourceware.org/autobook/autobook/autobook_92.html) by a real static
> > library which is private to X.  Of course, assuming the SO modules will need
> > to be linked to that static library, the static library has to be compiled
> > with the same compile flags (e.g., -fPIC) used to create the SO modules.
> > Then I understand that the linking of the SO module with the static library
> > proceeds by copying the required code from the static library and placing it
> > in the SO with no necessity of installing the static library or letting its
> > internals be exposed.  There may be some additional linking options required
> > to keep the API of the copied static library code within the SO private. But
> > if my overall mental model of the linking issues is correct, then the above
> > idea should work.

Yes, I agree this is the way to go in respect to supporting
convenience libraries in CMake.

> > Furthermore, implementing it with CMake would be
> > straightforward so that lack of convenience library support would no longer
> > be a CMake deal breaker for X.

It can and reportedly has been made to work on Linux systems (the best
attempt I found so far was in the bug report link I emailed before,
but there are a few more on the mailing list), but it is not that
straightforward since it implies dealing with some CMake internals,
which are not guaranteed to be preserved across versions. For those
who care for portability to non-unix platforms it is even more
difficult to accomplish.

> Which .so modules? I'm talking about the convenience libraries within
> the X server at the moment, which all get linked into the final
> Xorg/Xephyr/etc binaries (handwaving past the loadable module case).
> And again, maybe I'm missing something, but it does look vastly like
> we're missing the point, and reinventing convenience libraries in a
> pretty stunningly roundabout fashion.

Daniel, if a library will be linked into an executable, and not a SO,
then it is not referred as a "convenience library". It is just a
regular static library, and CMake handles those fine.

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

José