The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Oh no...
by ac on Wednesday 14/Sep/2005, @00:50
|
> And if you haven't heard of scons, well, I hope the rock you're
> living under is comfy.
There is no need to get sarcastic here. I initially heard about Scons through the KDE team and 2 people spending all their time on IRC convincing everyone how great it is while 3/4 of the developers kept crushing all their arguments to dust on IRC. 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.
> First of all, I think the people who wrote all the autotools-based build
> framework for KDE (S. Kulow being one of the first) are knowledgeable enough
> about it.
See, you simply answered one of my arguments above. From this sentence I understood it so. S. Kulow is the only skilled person around the KDE team who understands the autotools stuff. Which clearly says that 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. This most likely includes you too otherwise you would have realized that:
;--- from another comment.
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.
> Second, if a build system requires you to do more than quickly browsing
> through a few example files to be understood and used on your code, then it's
> just plain too complicated.
There are dozens (if not millions) of example files for autotools floating around all over the net. Dozens of manuals, howto, tutorials. But then there is that 'reading' and 'understanding' problem again. What good does all tutorials, docs and howtos give if people won't spent time reading them ?
> A build system should never get in the way of development, and should not
> require extensive reading. That's plain broken.
It doesn't since it's part of the development process.
> You don't know anything about KDE's build system, do you ?
I do and I consider it a hack with all the *.in.in files that get concatenated to an *.in file which then get passed through the autotools to generate working configure and makefiles. Of course the best example in howto NOT use the autotools. A clear sign that the whole concept of the toolchain has not been understand correctly.
> Yes. Whatever. If you don't mind, we'd like to move on, but feel
> free to remain on your high horse.
Please pardon but that's the worst bit of ignorance that I've ever read from your side. You keep ignoring comments done by me and some other guy here, you only reply on the things you see fits best in your picture and pull other text under the carpet and you make Scons sound so ultimatively great without giving one example in what areas it improves.
I would like to call you up for a challange to write a nice Scons tutorial and have a real life comparison between where you think Scons is better than autotools instead braging out how great it is. Until now I haven't seen anything about it except 2 people hyping hymns about it. The autotools* toolchain work on all sorts of systems, taking acount of all types of different hardware, toolchains, compilers, it even works on non POSIX systems such as Windows, AmigaOS, MorphOS and whatever other OS' and the best, it doesn't require Python.
Please also stop talking about HARDDISKSPACE is so cheap. This clearly shows that you live in a wasteful world and never really used a small system which is fast, maintainable and functional. The point is to have small systems and not monster systems. My entire system here is just 1.5 gb of space this includes X11R6, teTeX, Linux (+ Kernels), GNOME, Evolution, Abiword, Firefox, my home dir with all my files. Tar'ed up the entire System would be smaller than 590 mb of size and you can be sure I am not missing anything. I listen to music, watch movies, look at pictures, do documents, print, even play games. The point for using KDE is not just because of its superior architecture because I could save again 300 mb by simply switching from GNOME to KDE and getting rid of Python and the docbook crap. If you live ok with having a 240 gb harddisk and live perfectly by installing everything you find then it's your choice. But my choice (talking about choices here) is to keep and prefer small systems - a point you seem to not understand.
KDE 3.5.x perfectly works without Python, I am not missing anything, everything works and I would have enjoyed to see the same for KDE 4.
Sometimes I have the feeling (and please apologize here) that KDE is walking alongside of the entire open source and free software movement (I said it's just a feeling). It starts with the way how KDE installs the files (pulling all includes in the top include dir, installing all libs without versioning) while the majority of open source and free software projects agreed to install their headers nicely sorted in subdirs so people know they are all keep together, give their libraries good versioning, make use of man files, info files. But under KDE all is stuffed in as it shows up. But ok chances are great that with KDE4 these issues are dealt with, there is a top voted bugreport for this on bko which is in the first 10 places of most voted bugs.
And now with Scons, the vast majority of project imigrated to autotools these days this even includes XOrg and a few other really large and major projects without any problems (XOrg and Mozilla are quite big ones and yet they seem to handle the oh so bad autotools perfectly). And again KDE need to walk alongside with a silly buildenvironment.
|
[
Reply To This | View ]
|
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).
|
[
Reply To This | View ]
|
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 ]
|
Re: Oh no...
by Reinhold on Wednesday 14/Sep/2005, @14:30
|
To quote Mozilla's webpage on why they're not using another build system like scons or ant:
"Mainly, because no one has implemented these systems for Mozilla."
|
[
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)
