[KDE Dot News]
 faq
 flatforty
 contribute
 subscribe
 configure
 search
 rdf

 main
 parent
 thread


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)?
  Related Links
 ·   Articles on Developer
 ·   Also by Reinhold
 ·   Contact author

Thread Threshold:

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

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 ]

 
The Fine Print: The previous comments are owned by whomever posted them.
( Reply )

  "If you have an itch not being scratched, you can scratch it, or pay someone to scratch it for you." -- Eric Laffoon
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 ]