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 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 ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
