On Wednesday 26 March 2008, Eric S. Raymond wrote: > Most of you are aware that our autotools setup has reached a point > of unmaintainability at which Ivanovic and I believe we need to > change our build system to something (anything!) else. Additionally, > we'd like to be able to use the same build recipe for all platforms. > > Ivanovic and I are claiming this decision because (a) as our > release manager he is the single person most affected as a user by > autotools problems, and (b) with isaac seldom around I'm the person who > has been most called on to modify our build setup. > > Some weeks ago we effectively narrowed the alternatives to scons and > cmake. I am championing scons, Ivanovic cmake.
Ivanovic: I'm here and will try to help as good as possible with cmake (answering questions, not actually doing the porting). Does Wesnoth currently use also automake ? In http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/ you can find a Ruby script named am2cmake, which was used to translate the KDE Makefile.am to CMakeLists.txt . It has some special handling for the KDE extensions for autotools, so I don't know how good it works for non-KDE Makefile.am's, but I'd suggest that you give it a try. It doesn't do a complete conversion, but something like 80 to 90 percent of it. At the top you'll find LibMappingKDE[34] and InstallDirsKDE[34] variables, you probably want to do something there (modify them, add generic or Wesnoth specific variants, etc.). > But I think either of > us is willing to yield on this; we've more or less agreed that we will > make the final decision by comparing the readability and > maintainability of the scons and cmake recipes (what in American slang > we call a "bake-off"). In that comparison all active devs will be > invited to taste the baked goods and express their judgments, and I am > confident that Ivanovic will listen with the same attentiveness and > good judgment that I intend to apply. > > As a first step towards all this goodness, I have been working hard on > an scons recipe to replace all our autotools cruft. Unfortunately I > have about reached the limit of what I can do alone, and must now ask > for help. > > The basic problem here isn't that I can't make scons do what we want; > scons is not very complicated. It's that analyzing the behavior of > autotools is painful. So much so that you basically have to have a > pretty good a-priori grasp of what it's intended to do before you can > read it. I have done that for the main build, but there are some > outlying areas where I don't know enough about what is supposed to be > going on. > > Even if we go with cmake, the scons recipe working is critical-path > for the following reasons: Not sure about that... > 1. For the scons vs. cmake bake-off to happen, the scons recipe has to > work. > > 2. scons is like earth orbit. We may not want to stay there, but most > of the work of getting to anywhere *else* in build-system space is getting > out of the fierce gravity well of autotools. And that is the real > problem we are facing now. 3. KDE did that too ;-) (first tried to convert to scons, when that didn't work, switch to cmake) > Our current state is this: > * The scons recipe can build the game and edtor and all tools > * The scons recipe can correctly install everything but the data > directory. > * The scons recipe can correctly uninstall everything. > > Here are the "outlying areas". Basically, at this point I need to > hand these off to domain experts who have a better hope than I of > understanding what autotools is intending. > > 1. Building the unit-test binaries. > > This one is grzywacz's I think. There's some stuff with setting > #defines I don't understand, also how to get the link line to work. Which problem do you have when linking the unit tests ? > I suspect it would be easier for grzywacz to learn basic scons > and just do this one than to try to explain it. > > 2. Documentation formatting > > I don't know who owns this one. I'd be willing to do it if the other > missing stuff gets covered. > > 3. Data-directory installation. > > I thought I understood this, then I looked more closely and it turns > out that (a), I don't, and (b) looking at the autotools machinery for > it makes my head hurt. This one is Ivanovic's, except that > Shadow_Master has hinted that he understands it and thus might be > qualified to do it if he is foolish enough to volunteer :-). > > The minimum I need here is a detailed directory-by-directory spec of > what is supposed to get copied where. Yes, that would be good. Another approach is to install the autotools build somewhere and the other build somewhere and diff the two install directories until they contain the same files. > But it would be better if > whoever takes this one actually does it, so as to develop some > scons skill and not leave me as the project's only expert. > > 4. Distribution making. > > I think this one lands squarely on Ivanovic, maker of tarballs :-) I > have tried to make it easy by creating scons variables that list all > the shippable *.[ch]pp files. CMake comes with CPack, which can create source and binary packages (tgz, deb, rpm, NSIS and some Mac format). But CPack is not yet as mature as CMake itself, so it would be nice if we (CMake developers) would get some more feedback on that. > At minimum, I need a spec of what else goes in a tarball and where. > But it would be better if Ivanovic learned enough basic scons to > modify the recipe himself, because he is likely to need that skill later. > > 5. Translations handling. > > The headache I get from trying to unravel data-directory installation > is nothing compared to this, from which I run screaming and of which > I want no part. We need to have a detailed spec for how this is > done just as self-protection, but I would strongly prefer to never > even look at it. Ivanovic's again, though Torangan might be helpful. What is done there ? Alex _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
