faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Oh no...
by Guillaume Laurent on Wednesday 14/Sep/2005, @03:22
|
> I initially heard about Scons through the KDE team
Whenever you look for an alternative to 'make', scons comes up pretty quickly. I heard about it a couple of years ago I think.
> If Scons would have been that great then by far 1/5 of the open source or free software world would have switched to it.
There's such a thing as inertia, and the Open Source community excels at it. Have you bothered to look at http://www.scons.org/refer.php ? Plus there's little doubt that KDE adopting it will give it a lot of spotlight.
> the others who work on KDE (please pardon I don't want to sound offensive now) never bothered to read the documents of said toolchain
Yes, because they shouldn't have to. Again, a development tool should not get in the way of writing code. You should not have to waste time understanding it or making it fit your needs, otherwise it's broken, period. Yes, it's a part of the development process, but a part that must be kept as small as possible.
> Dozens of manuals, howto, tutorials
I've googled my share of autotools docs in the 5 years I've maintained RG's buildsystem, and those never turned up. I must have been blind or not entered the right keywords.
> A clear sign that the whole concept of the toolchain has not been understand correctly.
Feel free to explain Coolo how he's an idiot. Please don't forget to include patches.
> Scons sound so ultimatively great without giving one example in what areas it improves.
I've switched RG's build system from autocrap to scons/bksys. I had very little problems doing so, Thomas was very responsive to all requests, and the end result is a build system that's faster, lighter, and both easier to use ('scons' compared to 'make -f Makefile.cvs && ./configure && make') and maintain. For instance after 5 years we still had recurring problems with the simple addition of a '-fexceptions' flag to g++. Or adding a new QObject would require restarting 'make -f Makefile.cvs' otherwise you'd get obscure link errors. So we're saving time both for us developers (less problems in building the whole thing, less time wasted in answering users who have trouble in building it) and users (easier for them to build it).
> This clearly shows that you live in a wasteful world and never really used a small system which is fast, maintainable and functional.
Dude, 1.5 Gb ?? Do you have *any* idea how wasteful that is ? Back in the 80's my //gs had a 40 Mb (read that : MEGA-bytes) HD, all with OS, GUI, and office stuff. And even back then that was already considered a waste of resource (after all the apple //e was just as useful with a couple of 128Kb floppies). 1.5Gb is a super-computer which should be serving dozens of users. And you have all that just for you ? What a waste.
Now seriously, if you can't spare the $50 a 80Gb costs these days, tough luck, but on my side the limited resource is *time*, not HD space, so I'm not going to waste it because you insist on using a 10 year old system. I don't care about your choices, I don't even care about leaving you choices when it diverts me from writing useful code for real non-geek users, and the same reasoning is applied by all sane open-source developers. It's pointless to hurt the majority of real users by wasting time just to satisfy the silly needs of a few uber-nerds.
As for the whining about KDE not following standards, yes, let's all stick to C (after all if you can't read on how to write OO code in C, you've no business programming, right ?) and Motif (which was standard 10 years ago). |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Oh no...
by ac on Wednesday 14/Sep/2005, @04:02
|
> Dude, 1.5 Gb ?? Do you have *any* idea how wasteful that is ?
Please stop that sarcasm, we all know that we talk about 2005 and not what was 25 years ago with out 20 or 40mb harddrives. I come from these times and know pretty well. The demands and requirements nowadays are a hell lot differently and 1.5 gb for Linux measures are quite small but yet a full featured system.
|
[
Reply To This | View ]
|
Re: Oh no...
by Guillaume Laurent on Wednesday 14/Sep/2005, @04:24
|
You're putting down the work of pretty much everybody here who's trying to provide useful software for people, pompously saying that "people should read the autotool docs", or that KDE's build system is an example of misunderstanding the tool chain, that standards should be respected and other stereotypical statements usually coming from people who have no experience in software development, all this because you cling to an obsolete system, and you expect me to remain polite or even take you seriously ?
Just what software are you working on, so we can all download it and bask in the light of your infinite wisdom ?
|
[
Reply To This | View ]
|
Re: Oh no...
by ac on Wednesday 14/Sep/2005, @06:29
|
There is no need for you to get offensive.
a) I apologized many times that the stuff I write shouldn't be taken as offense. It just is my very own opinion about what I see and what I hear.
b) I very well respect the work KDE developers have done to provide a serious plattform for good software and integrated desktop experience.
c) I still believe that the problems around autotools is just a *placebo* thing that got repeated so often till everyone started to believe it while this argument is plain holdless. Personally I believe that the autotools system is quite mature and works perfectly. The problem is that people need to learn it, to read documents, read tutorials and of course that people do help each other to get around of children's disease. You say the programmer should concentrate on programming. I say that to learn programming you need to learn the language, the api, the system, the architecture and so on. That's quite a lot of what you need to learn to start getting something serious done. I talk from quality software here and not banal stuff as written in teaching books. Since I am a long years experienced programmer I do know what I am talking here. To learn autotools you need to be willing to spent time reading about it. The same would be a valid sentence for Scons and anything else that is new.
d) I never said that Coolo is a moron (as you described it). I only said that Coolo seem to be the only person who get used to the autotools (non)issue because he was willing to read about it and skilled enough to handle the issues for the entire KDE software that exists. Look one person alone to fix everything. Now imagine everyone would have at least half of the autotools skills of Coolo and by now no one would complain about it.
c) I probably asked you a couple of times now to name at least a few 'advantages' of Scons over autotools and yet you keep insulting me on a public forum like dot.kde.org for no reasons. And still I also said (I hope I did) that I have no issues with Scons per se. I have issues with the requirements of Python as buildtime. Not that it just is an requirement at buildtime, you also build other .py files and install them from other KDE components (that you usually won't get installed and compiled if no Python is found). So what was a buildtime requirement ends up in becoming a runtime requirement as well.
d) Please don't ask me on what software I was working on because it's by far offtopic to this conversation and would only end up in deflecting from the real problem. I by far have programmed, worked, maintained far more software than many other people around I believe, I must admit that personally I have only 3 or 4 programs that require the autotool chain, the rest usually were Makefile based, some Imake based stuff from former times and a shitload of ASM 68k software that from mechanism and build procedure works a bit differently (handled through a macro assembler, IDE, editor, debugger usually written with ASM-One on former Amiga times). Today I maintain some parts of the Linux Kernel, work on my own build system, some own software that I keep working at times and some other things.
But please would you start to be willing to name a few advantages of Scons over autotools ? Since you seem to be a clever guy that keeps defending Scons like it's written by you (maybe it is who knows) you might be willing to come up easily about a few advantages. It's your luck that python recently got ported to systems like AmigaOS4 or MorphOS otherwise we wouldn't be able to use the glory Scons system without Python but we would have been able to use autotools since 1996. I don't want to know how many non posix systems exists where you don't have python existing.
And please, I would respect you even more if you would reply in a mature way to me, even if I am an anonymous person I still try to be respectful to you and be as honest as even possible. Something you probably wont see every day from AC's.
|
[
Reply To This | View ]
|
Re: Oh no...
by Guillaume Laurent on Wednesday 14/Sep/2005, @07:16
|
OK, you're right, I'll try to calm down.
> You say the programmer should concentrate on programming. I say that to learn programming you need to learn the language, the api, the system, the architecture and so on.
I agree with that, but the build system is not, or should not, be part of this. Would you use a compiler which required extensive reading just to understand how to compile a single C file ? Unless you had no choice, you'd probably prefer it to be as simple as "cc foo.c", right ? It's the same for the building system, or the text editor, the IDE, the version control system, the documentation generation system, etc... I make a clear distinction between development tools and development platform (for instance, C++/QT/KDE, or Java, or C#/.NET). Learning a platform is mandatory of course, even though it should also be as simple as possible. But your IDE, compiler, and build system should never ever get in the way, and should not require you to dive into tons of tutorials and stuff just to get simple things done. And in that regard, the autotools fail utterly, while scons is rather successful.
> Now imagine everyone would have at least half of the autotools skills of Coolo and by now no one would complain about it.
And everyone would spend time on autotools rather than on their code. Again, time is the critical issue.
> I probably asked you a couple of times now to name at least a few 'advantages' of Scons over autotools
I did in my last post. To sum up, it's just much simpler to maintain and use, simply not having this 2-level generation of files is a huge win. Also having all in one script (configuration and building) helps immensely. It also handles conditional compiling very easily. Just try it for yourself, you'll see.
Note that I'm not a huge fan of scons, I prefer Ruby over Python, but the only ruby-based build system (rake) is even more exotic than scons is, and doesn't handle configuration tests. But scons is still much better than autotools.
|
[
Reply To This | View ]
|
Re: Oh no...
by Reinhold on Wednesday 14/Sep/2005, @14:23
|
ac, you want a few advantages of scons over auto*? (Haven't others already given some, like that its simpler to customize, or the links to the experience with scons on other platform? You seem to constantly ignore them and demand other advantages. On the other hand you complain about misinterpreting if only a small part of you posts is not directly answered.)
Anyway, here are a few facts:
-) The ability to build one target with all its dependencies (and only the dependencies). E.g. in kdepim you can build only korganizer/korganizer and the required libs (libkcal/libkcal.so, libkdepim/, etc.) are also built, but the rest of kdepim won't be built.
-) Do parallel builds in a compile farm (like -jN in automax) without launching the linker N times locally, too (which basically locks up your machine).
-) Dependencies (on libs in other dirs, generated headers in other dirs, etc.) are really generated from the actual code, not implicit like in automake (where the order of the subdirs is relevant because they will always be compiled in the order given).
-) No PID overflow on systems like windows (see Jan's mail, link above, which you constantly ignore)
Of course, this list if not exhaustive.
One thing you claim is that no-one except KDE apps use scons: How about id Software (Doom) using scons, or blender using scons on all their platforms (Linux, Windows using both Microsoft Visual C and Cygwin, Solaris, Mac OS X, IRIX and OpenBSD)?
Also, by now we all seem to agree that coolo has a fairly good knowledge about the auto* systems etc. Why do you think was he the first to start a replacement for automake for the KDE build?
Yes, he's the guy who wrote unsermake (which is now recommended to build KDE; and btw it is a python script...) to cure the problems he couldn't overcome with the auto* toolchain.
Since you don't seem to use KDE anyway (let alone build it...), why is it so important to you whether the KDE build needs python (scons) or perl (autoconf)?
|
[
Reply To This | View ]
|
Re: Oh no...
by ac on Thursday 15/Sep/2005, @00:57
|
First of all, I would be thankful if you could stop saying that I am permanently ignoring things, which I clearly don't. I haven't ignored those mails if you refer to clee's posting which contains a bunch of links. To say the truth I kept reading them and even replied to clee but that mail didn't made it to dot.kde.org for some unknown reasons.
I also mentioned that scons is by far useless on systems that don't have python and there are a few of them (maybe even hobbiest systems) which are not unix like and not posix conform (which they mustn't). These systems however have perl and the autotool chain. So talking about cross plattform, it doesn't make sense to use something regardless how great it is if the host system don't support python. But this just as a sidenote and also not the worries I tried explaining. Again since you seem to have ignored more of my writings than I igored a few links posted by someone. My problems are not Scorns related, my problems are the dependency of python that I'd like to avoid. And no I also don't tell developers what to use as some others told me on IRC, I only asked whether the autotools stuff can still be supported for those who dislike having python around.
There are also people who keep telling me that perl is bigger than python and started doing some weak calculations that with scons I can get rid of perl, autoconf, automake, m4, libtool and only keep python and scons. This would be nice in a real life scenario but if you have ever dealt with building up Linux systems then you realize how many damn packages (there are tons of them) do require perl, m4, automake, autoconf, libtool and other things. So I am not able to get rid of them. The calculation 100kb scons vs. 600kb autotools is wrong too, saying that I can save 30mb perl + 6 mb autotools, libtools, autoconf is wrong as well. Correctly said it has to be (for the upcoming KDE and for the underlaying system to get build)
Perl 30mb
Libtool 3mb
Autoconf 2mb
Automake 1mb
M4 1mb
And now with the dependency of python you can add
Python 40mb
Scons 100kb
Ontop of that. Till now even by reading the Links above I don't see the problems with autotools on Cygwin, Solaris, Mac OS X, IRIX and OpenBSD and honestly I do believe that these are just excuses. I don't see any issues since there were no issues posted. Only the reminder that it would be better to use scons because they had issues with autotools, but which ones are not mentioned. But then I only bothered reading the Links posted there.
Instead of slamming the entire autoconf, automake, m4 and libtool people (since I get accused for slamming the scons people) why not helping them to improve autotools to become better, fix the bugs that exists ?
The thing with Id-Software and Blender should be seen differently:
a) I don't have to compile Id-Software, most of their stuff is propritary for years anyways till it gets released open source one day (if we refer to doom here)
b) Blender is something not really necessary for my system, it's more or less a small tool that can be converted to configure if someone likes doing this.
c) KDE is a different story I somehow expect it to seamlessly fit into the unix world, fit into the way and common arrangements of installing files (headers, libs, manfiles, infofiles) as most other (basicly everything these days) are doing. KDE still does not:
http://bugs.kde.org/show_bug.cgi?id=86986
And I would also have loved to see that KDE feels more unix'ish beneath it's desktop. Better autotools support, better dealing with libtools, better organization of the files. Manfiles, touching of files when they are installed (tons of files are still copied). These are the things I'd really expected. Right now where we finally get rid of all the different build mechanisms such as Imake (which isn't bad by the way) where we get rid of custom written Makefiles that are hard to deal with. Right now where major solutions such as XOrg started switching to autotools. Finally I thought that everything would pull on one rope and start moving to one direction.
I also prefer KDE for not depending on so many languages for getting its core build. There are bindings that people can use to code tools in the language they prefer but it was no dependency for building KDE from source which made it an interesting thing because you could delete bloat around it (no requirements for extra doocbook installation, no requirements for python, you also need curious mono dependency and other nasty thing, you simply ran a small kde build script which executes configure and you are done).
This little rant is also not about cheap diskspace or why I and others have to justify why we should or should not install python. It's simply because we still have the choice to shape our Linux systems the way we want it. We can easily add python, maybe ruby one day and then mono because someone had a brilliant idea, but we don't see the reasons for installing big bulky packages of nonsense just because some small script requires it otherwise there would be no progress further to get your desktop of choice compiled.
Of course Scons may be the better choice over autotools and that's still not what worries me, but I would really have prefered to stay without python. What's so hard to understand here ?
|
[
Reply To This | View ]
|
Re: Oh no...
by Kevin Krammer on Thursday 15/Sep/2005, @03:29
|
> I only asked whether the autotools stuff can still be supported for those who dislike having python around.
As you have now volunteered to maintain the autotools based KDE build system and be available for any third party developer that might have questions regarding autotools, can I look forward to see your improvements in the 3.5 release or do you need more time, given that you have to maintain it also for the 4.0 branch
You are really taking on a huge job here, there should be more contributors like you
|
[
Reply To This | View ]
|
Re: Oh no...
by ac on Thursday 15/Sep/2005, @03:49
|
I still wait for some of my autotools patches to get committed to SVN they are waiting on bko for quite some months now. Even asking back whether it's ok to committ them didn't return any answer so far.
|
[
Reply To This | View ]
|
Re: Oh no...
by Nicolas Goutte on Thursday 15/Sep/2005, @07:01
|
What bug number? (So that I can check what has happened?)
As for commiting yourself, as it is probably in kde-common/admin, you cannot do it.
Have a nice day!
|
[
Reply To This | View ]
|
Re: Oh no...
by aleXXX on Wednesday 14/Sep/2005, @06:30
|
Well, I tried to work with autotools and tried to read the documentation. I didn't have success. You need to learn:
-m4
-libtool
-autoconf
-automake
These are just too many things to keep them all in your head if you use them only from time to time.
While I myself prefer cmake over scons, scons will definitely an improvement over autotools.
Alex
|
[
Reply To This | View ]
|
Re: Oh no...
by ac on Wednesday 14/Sep/2005, @06:58
|
But these tools m4, libtool, autoconf, automake are existing for how many years now ? You can ask basicly everyone to help you with it, you can even go to the next chinese fish store to ask some linux guru to help you while you probably won't find that many people helping you with Scons problems. But then again, Scons isn't really my problem. Python is (as if I haven't said this two dozen times now).
|
[
Reply To This | View ]
|
Re: Oh no...
by The Badger on Wednesday 14/Sep/2005, @09:27
|
"But these tools m4, libtool, autoconf, automake are existing for how many years now ?"
For so long that we're all born with inate knowledge of them?
"You can ask basicly everyone to help you with it, you can even go to the next chinese fish store to ask some linux guru to help you"
Dream on! Makefile and autotools gurus may be able to help you, but they're nowhere near as common as you make out. Even if the Internet is littered with autotools files, as you suggest elsewhere, that doesn't necessarily make troubleshooting any easier, as anyone with any experience of TeX authoring will tell you.
"while you probably won't find that many people helping you with Scons problems."
Sure, specific SCons experience is likely to be limited, but at least there's a chance that people will either get the language or get up to speed with it, rather than getting bogged down with the usual horseplay that shell-inspired toolsets entail.
"But then again, Scons isn't really my problem. Python is (as if I haven't said this two dozen times now)."
If only to contradict yourself in two dozen other places. But to distill this objection to Python down, it would appear that you see the installation of a tool you don't use as "wasteful" - in which case I imagine that you roll your own minimalistic Linux distribution in order to avoid all the other wasteful stuff that gets installed. Or don't tell me: you've said all this but actually run Fedora Core?!
|
[
Reply To This | View ]
|
Re: Oh no...
by Morty on Wednesday 14/Sep/2005, @17:10
|
>You can ask basicly everyone to help you with it,
I'll take your word for it. I encountered a small case a few days ago, can you please explain it to me. Why does it behave this way? I had a build error in the kdeaddons package when building noatun-plugins/blurscope. For some reason it decided to try linking to KDE files(libkdeprint,libkparts etc) in /usr rather than where KDEDIR is(/opt). I have some old KDE binaries in /usr as a backup solution when SVN builds to /opt fails, but no -devel RPMS so it does not find any .so files to link with there. Making one small change to the Makefile.am made everything build correctly. So please explain to me why these two lines works differently?
"noatunblurscope_la_LDFLAGS = $(all_libraries) -module -avoid-version -n o-undefined `$(SDL_CONFIG) --libs`"
"noatunblurscope_la_LDFLAGS = -module -avoid-version -n o-undefined `$(SDL_CONFIG) --libs` $(all_libraries)"
Why does one make it link against /usr and the other against /opt?
|
[
Reply To This | View ]
|
Re: Oh no...
by ac on Thursday 15/Sep/2005, @01:06
|
If I understand your problem correctly which I assume I do, then this is clearly the old known precedence problem (where to search first).
But sadly it's not just libtool or gcc alone. They search in the default paths for libraries first. So if you have older libraries sitting in /usr and have the new ones compiled and installed in /opt/kde then you can be sure that libtool and gcc seeks for libraries in /usr first rather than in /opt/kde.
Something you can not even solve with LD_LIBRARY_PATH. The correct solution would be to remove the old libraries in /usr anyways to avoid the problems. I encountered these issues some years ago when maintaining my own well known buildscript for another desktop environment.
This is no Makefile issue, nor is it a configure or autotools issue. It's an issue of precedence of where the compiler and linker or libtools is searching first.
IIRC JHBuild on freedesktop.org provides a patch for libtool to search in ${prefixdir}/lib first. But then these bugs are solvable it's just a matter of time that someone writes a bugreport and sents it to the maintainers so they can add it. Nothing wrong about that.
|
[
Reply To This | View ]
|
Re: Oh no...
by Roberto Alsina on Thursday 15/Sep/2005, @02:20
|
If the problem is old and known and there is a patch around, why is it necessary to write a bug report and send it to the maintainers?
|
[
Reply To This | View ]
|
Re: Oh no...
by ac on Thursday 15/Sep/2005, @02:24
|
The patch comes bundled with the jhbuild package, I don't know why it wasn't forwarded and I never bothered to ask either. Could be that it was sent to them and rejected, who knows.
|
[
Reply To This | View ]
|
Re: Oh no...
by Christian Loose on Thursday 15/Sep/2005, @03:20
|
> This is no Makefile issue, nor is it a configure or autotools issue. It's an issue of precedence of where the compiler and linker or libtools is searching first.
That doesn't answer the question, why the change fixed the problem. Why does putting $(all_libraries) at last posititon change the precedence?
|
[
Reply To This | View ]
|
Re: Oh no...
by ac on Thursday 15/Sep/2005, @03:47
|
I can not answer this without knowing the whole problem case. This also requires to know what system he uses, what's installed on it, what he really did, etc. Giving an direct answer to this over dot.kde.org without knowing all facts would be far to unserious. But all I know so far is that this is not an autotools issue. It's of course clear that if I force the precedence to be differently that stuff may work as in this case.
|
[
Reply To This | View ]
|
Re: Oh no...
by Morty on Thursday 15/Sep/2005, @08:52
|
>The correct solution would be to remove the old libraries in /usr anyways to avoid the problems.
No it's not the correct solution, for several reasons. First the ability to have several versions of KDE installed is a feature, and I don't think removing the stable version for unstable/svn version would be particularly popular by some of the users on this box(me included:-).
>This is no Makefile issue, nor is it a configure or autotools issue. It's an issue of precedence of where the compiler and linker or libtools is searching first.
How come simple changes to Makefile.am make it work or not, without any other changes anywhere. If it had been that simple the rest of the package would also have had failed building, and not only the one lone directory. As $(all_libraries) are positioned both places in the rest of the package. And the same can be said of the 10 other KDE source packages which builds correctly in the same environment, not having any precedence problems. Personally I think such unpredictable behavior in the build systems clearly confirms it has major issues.
|
[
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)
