How many of us understand how autoconf and friends work? How many are able to effectively edit and maintain the build process? I spent a few days during the 0.45 dev cycle working to add soft linking for libssl. Most of my time was spent in total confusion. And when I asked around no one among us was able to give much help. I find this a little scary. And I wonder if there isn't a different build system out there that more of us could become proficient in.
For lib2geom Verbalshadow decided to give CMake a try. I'm not sure what led to this decision. I think he looked at Scons and a few others first. Maybe because a huge project like KDE is using it. I found out recently that our sister project Scribus is also switching to CMake. You can read their happy rants:
http://rants.scribus.net/2006/05/20/cmake-rocks/ http://rants.scribus.net/2006/05/20/cmake-certainly-does-rock/ http://rants.scribus.net/2006/07/16/a-little-help-from-your-friends/
Verbal and I have been pretty able to take care of things with CMake. But I'm not sure I can make a recommendation for or against anything because I really don't know that much about build systems.
We also have Bob's build system to consider. I'll let him give you the details.
I'd like to use this thread to enumerate our needs for a build system. And I'd like to request some volunteers to help me evaluate any alternatives we find.
The general needs I know about are:
- maintainable by our team - crossplatform support - availability to our end users
Build systems I know of include:
- gnu auto* (what is the proper name?) - Bob's buildtool - Scons - Cmake
People interested in finding and evaluating a new build system:
- Aaron Spike
Please add to these lists.
Aaron Spike
People interested in finding and evaluating a new build system:
I think I agree that the current system is a dangerous mess, so I'm certainly interested in finding something better... and I'll try to be helpful in testing it if I have time.
On 2/3/07, Aaron Spike <aaron@...749...> wrote:
Did you test cmake with lib2geom? Any first impressions?
I don't normally pay attention to these things, so long as they work... and cmake worked fine :)
On Sat, Feb 03, 2007 at 07:59:45PM +0300, Alexandre Prokoudine 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 * Having to update the version number in 7+ different files each time we increment a build * 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. * 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.)
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.
Bryce
Bryce Harrington wrote:
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.
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.)
Again, isn't this unrelated to the build system? If we want it organized differently, let's just do it.
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.
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
I'm going to chime in here. The main reason I picked Cmake was the Build syntax looked considerable less painfully then most of the other systems out especially when compared to the Auto* build system. Secondly it is cross-platform on all the major platforms that we wanted to support *nix, Windows, MACOSX, and many others as well. And the thrid reason was I wanted to see if i could do it with a small project looking to hopefully build enough knowledge to attempt something like Inkscape.
I think a Handful of dedicated People could have all of the build system converted in a week or two at most. With only one or two working part time on it the outside of a month. And that is people with no knowledge of how Cmake build system works. If we could borrow some experts from the Scribus team or some other Cmake knowledgeable group it would go much faster.
I'm of course willing to help to convert to whatever system we decide on, but Cmake would be my choice. Whatever help I can give. It should be noted that i have piss poor access to web for the time being and the foreseeable future.
Joshua L. Blocher verbalshadow
I think it would be great to see the following build system problems solved:
For me the most important thing about the build system, is the easy way of creating debian package of it. (I dont like the make install, because it copy files all over my system, and there is no easy way to remove).
Creating debian package is mostly just a dpkg-buildpackage -rfakeroot.
However, sometime I need autogen.sh to run before this, and some other thing to tuning...
I have build .deb package from inkscape (to trying out the newest feature and/or bugreporting), but I never succeed to use the effects on my system.
Currently I installed the pre3 from debian SID, and the python-numpy (which is required by the perspective extension) still use and require python 2.3. Some effects are using python 2.4. And on my system there is python 2.5 too.
To summarizing up: * easy way to create system specific package (eg. debian package). * easy way to install the extensions. (using just one python version)
Just my 0.02 cents.
Khiraly
On Sat, Feb 03, 2007 at 06:12:56PM -0800, Bryce Harrington wrote:
I think it would be great to see the following build system problems solved: [snip]
I'll throw in my $0.02 too... If the current build system were replaced, I'd like to not lose one specific feature: fully parallel builds. At present, given the "single Makefile in src/", I can actually use all 4 CPUs to do compiles, etc. I don't want to regress to having a separate Makefile in every subdirectory. :)
Kees Cook wrote:
Great, thanks informing me so I can check this out. If you remember I'm pretty unfamiliar with build systems. I have no idea what you are talking about. Can I get a link or a more detailed explaination?
One thing to note, CMake still uses make. It is a Makefile generator (also generates build process files for various other tools). So I would assume anything you can do with make is easily supported. But it doesn't hurt to check it out.
Please keep the requirement's coming!
Aaron Spike
"Jon A. Cruz" <jon@...18...> writes:
Right: http://members.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html
Just two days ago I was reading that again by accident...
Cheers Colin
Can autopackage be ported to other Unix?! ...like Mac OS X 10.5
Unix > Windows
2007/2/7, Kees Cook <kees@...62...>:
On Feb 3, 2007, at 8:59 AM, Alexandre Prokoudine wrote:
I know nothing about Bob's buildtool. CMake seems to eventually become mainstream for desktop applications these days (KDE4, Scribus etc.)
Yes...
But before that SCONS was the new system for KDE, etc.
One huge problem there was that I could not get certain SCONS projects to work on OSX. I believe that CMake is much better in that regards, but very good cross-platform support is definitely something to test well.
participants (12)
-
Aaron Spike -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
Colin Marquardt -
Craig Bradney -
Esteban Barahona -
Jon A. Cruz -
Joshua A. Andler -
Joshua Blocher -
Kees Cook -
Khiraly