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

[José Fonseca]

On 12/22/07, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
> On 2007-12-22 09:50-0000 José Fonseca wrote:
>
> > I also have good experiences with CMake, but there is one other
> > disadvantage comparing with libtool: lack of support for convenience
> > libraries. This makes the creation of large SO modules which shared code
> > (e.g. a DRI driver) painful if not unfeasible without writing custom and
> > likely non-portable CMake macros.
> >
> > See the "Autoconf support for Mesa" thread on mesa3d-dev ML:
> >
> >  http://sourceforge.net/mailarchive/message.php?msg_name=fjgkbm%24mc6%
> > 241%40ger.gmane.org
> >
> > and
> >  http://www.cmake.org/Wiki/
> > CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F
>
> Actually, I think you can state it stronger than that. If you insist on
> "convenience" libraries (unorganized collections of compiled objects that
> are not a real library), then CMake is not for you since from discussions on
> this subject on the CMake mailing list the CMake developers feel that
> convenience libraries are a build-system crutch that they do not want to
> support, and I agree with their stand on this.

I don't think they have that they have that stand at all. Check Bill
Hoffman note on the bottom of
http://www.cmake.org/Bug/view.php?id=5155 , It is a technically
difficult problem but there are legitimate use cases. I think DRI
drivers, or drivers in general, is one of them.

> Analysis of the X specifics may indicate an obvious way to avoid using this
> crutch. For example, if large SO modules share extensive code as indicated
> above, isn't that a strong indication that you should make a real library
> out of that shared code?

Not really. There will be only one DRI driver loaded in a single
process. I don't know enough to comment on X.

> Real libraries are stongly supported by CMake
> without any need for recompilation, and the end result is a lot easier to
> understand and maintain in my opinion.

I don't agree. It might make easier to understand and maintain from
the build system POV. But I fail to see the practical benefit of
increasing the number of shared libraries, if they won't be shared at
all at runtime, just linked once.

José