faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
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. |
|
|
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 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 ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
