On Sat, 08 Dec 2007 17:48:59 -0800, Dan Nicholson wrote:
> On Dec 8, 2007 12:48 PM, Alex Neundorf <[EMAIL PROTECTED]>
> wrote:
>>
>> On 12/8/07, Dan Nicholson <[EMAIL PROTECTED]> wrote:
>> > This patch set adds initial autoconf support for Mesa. Previous
>> > discussion was that full autotools was not desired. This approach is
>>
>> Is switching *to* autotools now not a bit late ? I mean lots of
>> projects are switching away from it now. In case anybody is interested,
>> I could assist with adding a cmake-based build system to mesa.
>
> Well, it's not my call, but I'll just throw out my opinion.
>
> First, some projects might be exploring different build systems, but
> still roughly 75% of the projects I've built use some form of
> autoconf/automake/libtool. So, it's hardly crazy to suggest using
> autoconf right now. Also, mesa is practically a sister project to Xorg,
> which is fully autotooled. So, you can leverage all that experience onto
> mesa. If you switch to another system like cmake or waf, then mesa is
> still off on its own like it is now.
>
> Second, while a cmake system or even a full autotooling would require a
> major overhaul of the source tree, this approach is completely
> non-invasive. You can continue to build mesa the exact same way if you
> prefer. It's just an extra script to generate configuration for you.
>
> Third, autoconf requires no additional components than what's already
> required to build mesa (from the tarball, anyway). So, you could start
> using the configure script immediately without changing the requirements
> at all. Definitely can't say that about cmake.
>
> Maybe the most important is that autoconf is really mature, well
> understood and supports tons of platforms. People will know how to work
> with it because it's used everywhere.
By "tons of platforms" you mean tons of Unix variants. AFAIK, autotools
still require shell scripts. Mesa is built on more than those. No, I
don't think autoconf is even remotely close to being called cross-
platform.
That being said, I experimented using cmake to build Gallium, which aims
to be cross-platform. Using cmake doesn't require any "major overhaul of
the source tree" but I stumbled into an obstacle -- cmake doesn't support
convenience libraries [1], i.e., libraries that will be linked into other
libraries.
We need convenience libraries because Mesa's build end result is
shared libraries, and we want to link the intermediate modules into
these convenience libraries.
The solution pointed out in the CMake FAQ is to put the sources of the
libraries into every target library. However this will cause the files
to be recompiled for every target. Taking mesa as example, the common
sources files in src/mesa/{main,pipe,etc} would be recompiled for
*every* driver in src/mesa/drivers/* . Therefore this solution won't
work for Mesa.
The reason cmake doesn't support convenience libraries is because it
is very difficult to get them right on all platforms. There are
however some efforts on that direction [2], and it's not that
difficult to get it working on Linux.
The summary is that, yes, can use CMake to build with Mesa, however it
will have to resort to some custom macros to get convenience
libraries, and we will have to make those macros work for every
platform we care...
I plan to look into this again when I have some more time.
[1] http://www.cmake.org/Wiki/
CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F
[2] http://www.cmake.org/Bug/view.php?id=5155
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
