Bryce Harrington wrote:
I think it would be great to see the following build system problems solved:
- Changing a header file invariably results in a nigh-complete rebuild of the whole tree
I don't know if cmake can help this. CMake generates makefiles. So it still uses make. I also don't know if we can blame this on the build system or if we have to take the blame ourselves because of the structure of our code. Perhaps someone else can answer.
- Having to update the version number in 7+ different files each time we increment a build
Ditto. Is there a reason all of these files couldn't be *.in-ized and processed now? The only ones I can imagine causing a problem is win32 because it is a separate build system entirely. (doesn't have to be separate, that's just the way we do it now.)
- There are way too many packaging scripts in the root inkscape directory. Better if these were either unneeded, included in the makefile, or placed in a subdirectory.
Again, isn't this unrelated to the build system? If we want it organized differently, let's just do it.
- Adding/changing configuration options or new libs is a bit cumbersome
- Installing to locations other than /usr sometimes does not work (inkscape not finding its share dir, etc. etc.)
Prove it. I install in locations all over the place. Haven't seen a problem yet. Best I can figure is that problems like this happen when inkscape is run from the build root and not make installed.
If cmake can help address some of these issues, it could be a very good thing.
One thing to consider when changing build systems is the potential of the new system to pose a hurdle for new developers. If people get stuck just figuring out how to get the build system working, that may be enough to scare them away from getting more further involved. On the other hand, if the build system is easy to run, well documented, and works very reliably, it could be a very good thing. Autotools has the advantage of being a common denominator, and cmake starts at a disadvantage because it is not yet super widespread. However, if it can greatly simplify tasks that new developers will want to do, compared with autotools, then it could easily come out way ahead.
Even if we choose to concentrate on the new developer demographic we're lumping a whole bunch of issues together here.
1) Difficulty for an outsider to compile? Neither autotools nor cmake are difficult to use for a compile. Four lines of explaination in a README should be sufficient to get the newest linux newbie or the hardest core hacker compiling inkscape. But the hard core hackers won't read the README. :-) I'm willing to bet that teaching the old dogs new tricks is where the difficulty comes. (We can watch this in action now that 2geom 0.0.1 is released. ;-) )
2) Difficulty to maintain the build system? I mean Verbalshadow no disrespect whatsoever, but he and I ain't real pros. We picked up cmake in just days and got real stuff done. (Truthfully I didn't do much at the start but help him troubleshoot a few win32 issues.) I'd love to see some real numbers because I know cmake would wipe the floors with autotools in a contest of approachability. Again I think a seasoned autotools hacker will find it more difficult than a newbie.
But there's the rub! Where are our seasoned autotools hackers? I think cmake's approchability could greatly broaden the pool of build system hackers in the Inkscape project.
Aaron Spike