From: Arnold K. <ar...@ar...> - 2007-08-27 09:32:58
|
Am Montag, 27. August 2007 schrieb Jonathan Woithe: > > And it contains my merge introducing scons as a buildsystem. > Just out of interest, what is it about scons that makes it so much better > than auto* in the context of ffado? I know that numerous projects are > moving to scons citing "problems" with the auto* tools, but what specific > advantages does scons bring? As ppalmers already presented, It reduces code and work and is easier to=20 maintain. Especially since ppalmers already knows python where on auto* you= =20 have to learn yet another script-language (or two or three) which are not=20 even object oriented (which can really get on your tits if you are used to= =20 that way of thinking). After all I think "make" isn't bad. If you know how to write makefiles, you= =20 can do small jobs pretty easy and fast. The problem is that after a certain= =20 point you need more automatism and then you search for other tools to creat= e=20 the makefiles. KDE switched to cmake to create these and Qt provides their= =20 qmake. They both seem to use the full featureset of make (real parallel=20 builds for example) while the grown-over-the-years autotools have implement= ed=20 so much features that its a hell to maintain a project with autotools and i= t=20 doesn't even use the full featureset of make. We could have switched to cmake (or even qmake) or something else. The real= =20 decision for scons (apart from the advantages listed above and below and by= =20 ppalmers) was simply that I know scons (I am using it for my private- and=20 work-projects) and was willing to spend some time to do the transition. If= =20 someone else had stepped up to port the buildsystem to something else, that= =20 would have been the decision. But in free software most decisions of this=20 kind aren't made by long and glorious discussions on mailinglists and irc b= ut=20 by people actually doing the stuff. So that is why ffado is using scons=20 now :-) > Do we not risk replacing one set of=20 > build-related problems with another? Yes. But we replace many problems by far less problems (which are easier to= =20 solve because the script-language is less obscure). > In some ways it seems switching to "scons" (or any other relatively > new/experimental build system) is becoming a bit of a hobby amongst FOSS > projects. Which shows a) that more and more people realize the shortcomings of auto* = and=20 b) that there are true alternatives available. I wouldn't call scons or cma= ke=20 experimental just because they are not as old as the autotools, they are=20 relatively new though. > Note that I'm not criticising the move to scons here as such - it's just > that to this point I've seen little technical justification as to why > the move is desirable for us (perhaps I missed a post). Apart from my big paragraphs above, you should look at your daily usage of= =20 auto* and now scons (and on ppalmers mails) and see which one has less work= =20 for you and all the devs. :-) > The one thing which irritates me about scons is the lack of "uninstall" > functionality. While certainly not essential (or even bug-free) I have > found it useful to ensure that things are cleaned up when switching betwe= en > different versions of the same software. You should read my announcement mail again, it states "scons -c install" as= =20 the replacement for "make uninstall". Its just not another target "uninstal= l"=20 to be defined in the scripts, but simply a negation of the install-target, = so=20 everything that would be installed is checked for presence in the system an= d=20 uninstalled. Arnold =2D-=20 visit http://www.arnoldarts.de/ =2D-- Hi, I am a .signature virus. Please copy me into your ~/.signature and send= me=20 to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your=20 administrator to do so... |