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

José Fonseca jrfonseca at tungstengraphics.com
Sat Dec 22 12:44:35 PST 2007


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é



More information about the xorg mailing list