faq  flatforty  contribute  subscribe  configure  search  rdf  main  parent	Oh no, this is definately a shot in the own leg by ac on Tuesday 13/Sep/2005, @02:59 If you allow, I am not a big fan of stuff that requires Python. It was a big pain to have Python stuff together with GNOME and I hoped that KDE would stay entirely free of it, not just runtime, but also buildtime. I feel a bit sad to say the truth because I've been following the Scons discussion on IRC for quite a while now amd came to the personal conclusion that Scons has absolutely no advantage over Auto* not to mention that this requires a new learning curve to the developers to keep on with the stuff and then in what aspects does it make stuff easier ? I was seriously considering keeping KDE as my main desktop of choice once I set up a new source based setup of my Linux system and Python was one of the main reasons that I wanted to get rid off. 40 mb of Python trash for just some config files - what's next MONO ?	Related Links  ·   Articles on Developer  ·   Also by ac  ·   Contact author Thread Threshold: 10 comments 20 comments 30 comments 40 comments 50 comments 60 comments 70 comments 80 comments 90 comments 100 comments 110 comments 120 comments 130 comments 140 comments 150 comments 160 comments 170 comments 180 comments 190 comments 200 comments 300 comments 400 comments 500 comments 1000 comments
	The Fine Print: The following comments are owned by whomever posted them. ( Reply ) Re: Oh no, this is definately a shot in the own le by ac on Tuesday 13/Sep/2005, @03:01 * Size: 100KB (miniSCons included) vs 600KB (autotools) Not to forget 40mb of Pyhton which makes it 40mb and 100kb. Autotools is still smaller :) [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by Anonymous Python on Tuesday 13/Sep/2005, @05:14 But you'll quickly reduce that saving once you start generating or distributing configure scripts, and Python is installed as standard on most distros, anyway. Don't you think it's better to pay the cost up front rather than every time you download or create a new package? [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by ac on Tuesday 13/Sep/2005, @12:15 > and Python is installed as standard on most distros, anyway. This is placebo talk and a very bad excuse too. On most modern distros we have MONO and JAVA installed too, so why not make it a dependency for KDE as well ? Oh and even more distros and developers use auto* because it's a defacto standard in professional building of source based software - but no, let's make Scons a new unnecessary dependency because someone said so. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by anonymous_curious on Tuesday 13/Sep/2005, @14:22 On the other hand it removes the dependency on Perl .. and also M4, GNU/Make, libtool, automake, autoconf. What KDE or autotool-based project are you maintaining once again ? [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by Dolio on Tuesday 13/Sep/2005, @16:57 > On most modern distros we have MONO and JAVA installed too, so why not make it a dependency for KDE as well ? Because there's no compelling reason to do so. Scons is a compelling reason to depend on Python. Qt is a compelling reason to depend on C++. Et cetera. Your excuse for the use of autotools of, "everyone else does" is worse. If scons is significantly better, then it should be used, and the fact that most distributions ship Python simply shows that the Python dependency is a non-issue for the great majority of people. Why aren't you lambasting KDE for moving to Subversion? Most other project haven't, and CVS is like a de facto standard. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by ac on Wednesday 14/Sep/2005, @00:20 a) We don't know if Scons is really that significantly better. The reasons for switching away from autotools was because a significant amount of KDE developers were not willing to read the manuals so they could set up their stuff correctly. b) Python may be shopped with most distributions and I don't deny that but it's not required on most distributions. It's an option to be installed for people who desperately need it to hack up some small scripts. c) Python will not be a build dependency anymore because as soon as Python is detected by the KDE scripts as soon it starts to compile optional python files too and installs them (which is not wanted). d) If you read the autotool documents correctly then you would figure that autotools has to serve on a lot of POSIX compliant systems with dozens if not hundrets of different toolchains, compilers, headers and whatever. It's not limited to linux, it's not limited on windows, it's not even limited on operating systems such as MorphOS, AmigaOS (which are totally NON POSIX). That are the big advantages of autotools. You enter configure and then make afterwards. But you of course know perfectly the difference between scons and auto* since you never ever read a damn doc about it. So now name up some advantages of scons over auto* and I will reply in a few hours to crush all of them down. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by Aaron J. Seigo on Wednesday 14/Sep/2005, @06:00 > So now name up some advantages of scons over auto* not only does scons not make me cringe every time i look at it, but i can even reasonably hack on it without become a scons wizard. it also means that instead of every 3rd party app shipping a couple of megs of configuration structure (have you SEEN how big configure, aclocal.m4, acinclude.m4, etc is these days?!), they can ship a tiny little script. when your app is only a few hundred KB (if that) of source code, the current situation is just silly and a bandwidth waster. scons does the job, does it well, does it with less black magic and does it smaller. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by The Badger on Wednesday 14/Sep/2005, @09:10 "The reasons for switching away from autotools was because a significant amount of KDE developers were not willing to read the manuals so they could set up their stuff correctly." Heaven help anyone who has to read the autotools manuals! I've done a fair amount of autotools work and whilst I see the benefits in small scale projects, having to write shell script-like code with bizarre tricks that only seasoned bash coders find acceptable is not exactly how I envisaged spending the 21st century. Of course, most autotools-based projects blow most of the benefits away by using automake, thus generating a configure script with 20000 system tests just to compile a "hello world"-level program. "Python may be shopped with most distributions and I don't deny that but it's not required on most distributions. It's an option to be installed for people who desperately need it to hack up some small scripts." The increasing recognition of dynamically-typed programming languages is another trend that passed you by, then? "But you of course know perfectly the difference between scons and auto* since you never ever read a damn doc about it." I've read the "damn doc about it" and, as I said, it has its place. But given that SCons has a certain amount of heritage in a project to make better and more usable development tools, and given that is extensible using a modern programming language, I'd suggest that you seriously reconsider those advantages whether you seek to publicly (and ridiculously, in my view) "crush all of them down" or not. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by ac on Wednesday 14/Sep/2005, @10:09 > The increasing recognition of dynamically-typed programming > languages is another trend that passed you by, then? You mean (and I am trolling here) the same trend that KDE keeps passing such as dbus, hal, libnotify, gstreamer, cairo, glitz, libburn, pkgconfig, poppler, startup-notification and all the other standards found on fdo ? But yet create their own set of stuff to avoid being compared with GNOME ? If I recall back times when I read some archives of XDG ML then well, I find really curious reasons raised by KDE devels to NOT USE them. The same justified reasons I accept people to dislike something because its from the evil opponent the same way I would expect people to accept my dislike of Python as depedency. Maybe both reasons are braindead but they are at least reasons, the one has those the others has others. I don't want to bash or attack anyone here because I believe everyone has a good right to have his or her own opinion but please don't make it sound like Python is the trendsetter in languages. So why not using MONO to develop core KDE apps ? Anyone missing the trend of .NET and C# ? [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by Anonymous on Wednesday 14/Sep/2005, @10:45 > [...] and all the other standards found on fdo ? http://www.freedesktop.org "freedesktop.org is not a formal standards organization" "Unlike a standards organization, freedesktop.org is a "collaboration zone" where ideas and code are tossed around" [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by Roberto Alsina on Wednesday 14/Sep/2005, @17:21 Saying that people don't use auto* because they are not bothering with the manuals is stupid. It's like saying people prefer wearing shoes because they are not bothering to form calluses in their feet. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by Anonymous Python on Wednesday 14/Sep/2005, @04:18 Well, maybe it wouldn't be such a bad idea to require Mono, Java, Ruby and Python. >:-) At least it would open up the KDE platform to developers who use those languages and environments, and it would take away the pressure to use C++ for everything just because the other bindings are "optional". Let me ask you a question: if Scons was written in Perl, C or C++, would you still have the same reservations? I believe you would, and this makes your arguments about Python secondary to the ones you're trying to make. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by Guillaume Laurent on Tuesday 13/Sep/2005, @07:07 Except you don't have to distribute python along with your software, while you do have to distribute the auto* generated files. Come on, a build-time dependency on python is hardly a problem in practice. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by ac on Wednesday 14/Sep/2005, @00:23 > Come on, a build-time dependency on python is hardly a problem in practice. It's not just a build time dependency. ;--- reply from another comment c) Python will not be a build dependency anymore because as soon as Python is detected by the KDE scripts as soon it starts to compile optional python files too and installs them (which is not wanted). [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by Guillaume Laurent on Wednesday 14/Sep/2005, @00:45 *sigh*. Look, if you really want to save every cpu cycle and HD block you have, I suggest you switch back to twm. Better yet, stick to the console. Your complains are really not making any sense beyond "python baaaad, whaaaaa". [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by ac on Wednesday 14/Sep/2005, @00:52 You are not making any sense either, you see that I dislike Scons because of Python - which you seem to have an even bigger issue with - and you start to discredit my comments by making silly replies. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by ac on Wednesday 14/Sep/2005, @20:22 That would be only silly if that weren't possible to disable. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by clee on Wednesday 14/Sep/2005, @05:51 Either you are misinformed, or your distribution has terrible python packages. My own research on my local system shows: clee ~ % aptitude show perl autoconf automake1.9 m4 libtool | grep 'Uncompressed Size' Uncompressed Size: 11.5M Uncompressed Size: 1507k Uncompressed Size: 1602k Uncompressed Size: 348k Uncompressed Size: 2380k That's about 16MB for perl, m4, autoconf, automake, and libtool on my system. clee ~ % aptitude show python2.4 | grep 'Uncompressed Size' Uncompressed Size: 9191k So, it's a little over half the size of perl + m4 + autoconf + automake + libtool. Plus, you claim that the autotools work perfectly on every system ever, except that it's patently untrue; the vast majority of the problems our porters have on MacOS X and Win32 systems are directly because of autotools. Benjamin Reed, the main developer behind the MacOS X port, said in this message (http://lists.kde.org/?l=kde-core-devel&m=111866452210421&w=2) on the Build system for KDE4 thread (http://lists.kde.org/?t=111863688400002&r=1&w=2): "Writing tests in scons/etc. is considerably easier than doing it in M4 and shell." Jaroslaw Staniek, the main developer on the Win32 port, said (http://lists.kde.org/?l=kde-core-devel&m=111866757017220&w=2) in the same thread: "SCons would be my favourite. Among others, there's one more advantage: with python scripts I wont run off with win32 PIDs on cygwin. For now oferflowing PIDs counter forces me to (sic!) reboot." So the "BUT THE AUTOTOOLS ARE CROSS-PLATFORM!" argument falls on its face. They're unusable on non-UNIX systems for real projects, especially ones the size of KDE. There are other serious issues with the autotools, as well, which is the main reason that we're interested in moving away from them. Such reasons include the fact that the autotools make it very difficult (if not impossible) to properly support parallelized builds, and the fact that they are difficult and unintuitive to use, especially "properly". So much so that you have to read "dozens of documents" on them in order to make use of them.... (half of these documents, incidentally, are for obsolete versions, and the behaviours have changed significantly in some aspects depending on the version that you're using.) So, to sum up: 1) The autotools have serious issues with their "cross-platform" support 2) The autotools lack features we desire, such as easy extensibility and easily parallelizable builds 3) The autotools use a variety of languages, none of which is simple or well-known by the vast majority of our developers. 4) The autotools actually take up *more* space on disk, both in the installed packages required and in the amount of space required for our autotools infrastructure (the 600kb vs 100kb argument) I look forward to you "crushing my arguments into dust" though. Try to remember to cite actual sources, instead of just using rhetoric. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by kundor on Wednesday 14/Sep/2005, @12:28 I don't have any beef with SCons, but I'm not sure why you included perl in the autotools size measurement? What does perl have to do with anything? [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by clee on Wednesday 14/Sep/2005, @13:12 Because the autotools require Perl to run, and Perl is bigger than Python. Try running 'rpm -q --requires autoconf' or 'aptitude show -v autoconf' (depending on which distribution you're on). [ Reply To This | View ] Re: Oh no, this is definately a shot in the own leg by Max Howell on Tuesday 13/Sep/2005, @09:34 Using bksys instead of auto* on my projects has prevented me from having to commit suicide. Which at the very least is an advantage for me, and I'd like to think some other people too. Developers have to learn a new build system, true. But after 3 hours of using it they will very quickly understand that their lives will be infinitely better forever more. The users will benefit from quicker configure checks, smaller downloads and not having to deal with the horrendous autotools if the build breaks. I don't think a build-dependency on python/SCONS is a problem for 95% of users or developers. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by ac on Wednesday 14/Sep/2005, @00:22 > Using bksys instead of auto* on my projects has prevented me from > having to commit suicide. If you'd read the auto* documents then you wouldn't need to commit suicide. [ Reply To This | View ] Re: Oh no, this is definately a shot in the own le by The Badger on Wednesday 14/Sep/2005, @08:42 > If you'd read the auto* documents then you wouldn't need to commit suicide. I wouldn't say that reading the auto* documents is an experience that's going to cheer you up, however. [ Reply To This | View ] clueless troll by anonymous_curious on Thursday 15/Sep/2005, @04:01 * KDE 4 already required python (Unsermake) and for months * The poster "ac" is not a KDE developer (it even looks like he works on Gnome) Do not feed the troll, Thanks. [ Reply To This | View ] Re: clueless troll by ac on Thursday 15/Sep/2005, @04:17 a) Unsermake was also used by KDE 3 for people who liked using it, but there was no nesessarity for it too since people were doing fine using autotools for getting KDE compiled. So basicly no python requirements. b) Could you please refer me to the site on *.kde.org where it's written that you must be a developer to participate to KDE ? You are just attacking all the people who keep contributing to KDE (including me). We are not developing KDE by providing code (nontheless I am coder and developers but work on other stuff) but the KDE participants are still able to contribute with translations, webpresentations, documentations, audiovisual stuff and other things such as bugreporting and excessive testing. Still though I am skilled anough to talk my mind out of things that bothers me, after all the sentence 'free software as in free speach and free beer is still valid'. For the part of not feeding the Troll. Please thanks for the advise, I am not going to feed you any further but I think it would have been fair to give you at least a normal answer. Till now I thought that KDE people were much more open minded for feedback given by others. It would be a pity to pop this bubble. I recall good enough that some weeks ago people kept praying the pester about Scons on IRC, at least I had that feeling (might be wrong but that time I surely had) I keep wondering myself what kept them changing so fast. Or is it just because you can flame ahead someone ? [ Reply To This | View ] Re: clueless troll by ac on Thursday 15/Sep/2005, @12:08 Do you by a chance mix up this board with a mailing list where all this discussion already took place? Either way you are late with your concerns and not involved enough to make those who are believe in your case. [ Reply To This | View ] Re: clueless troll by ac on Thursday 15/Sep/2005, @04:21 Oh and by the way I never mentioned any KDE 4 since KDE 4 doesn't exist as of now. People started porting things from KDE 3 to QT 4 starting maybe 1 month ago or so and this will be KDE 4 one day. So why bother for things that don't exist yet. And for being acused to mortify scons and python loving people, please take my apologizes but reading about autotools being shit, perl sucks, etc. of course is not offending those who write it or contribute to it. My bad.. [ Reply To This | View ] Re: clueless troll by anonymous on Thursday 15/Sep/2005, @13:36 Fact: people have started working on kde4 at least 4 months ago http://www.kdedevelopers.org/node/1094 [ Reply To This | View ]   The Fine Print: The previous comments are owned by whomever posted them. ( Reply )

		"The trick is not to dream of adding a feature, but simply to do it." -- Stefan Westerfeld
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.

[ home | post article | flat forty | subscribe | search | rdf ]