Bug 86986 - Arrange includes and files in a better way for KDE 4
Summary: Arrange includes and files in a better way for KDE 4
Status: CONFIRMED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-11 17:45 UTC by Ali Akcaagac
Modified: 2011-02-15 21:27 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ali Akcaagac 2004-08-11 17:45:51 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

I have a little request for the upcoming version of KDE 4. After a little conversation with some people on IRC I was told that KDE 4 will become a bigger task of change (probably related to QT 4) and therefore I'd like to take the chance to ask for this wish and hope that developers might like this idea. Please excuse my english by times because it's not my mother thongue. I am also no KDE developers so I can only ask for this so please bear with me.

Something I disliked in KDE 3 (when compiling from CVS for example) was that the majority of includes from KDE libraries or additional programs are copied to:

${prefix}/include/*.h

Only some KDE 'components (modules/apps/libs)' were using an own subdir such as:

${prefix}/include/kontact/*.h
${prefix}/include/noatun/*.h

And so on. I would like to ask whether this can be done for the other includes as well. I know someone would say now that this is more or less the work of a distribution but I think that this would be a general good thing to have because it would organize the includes a bit better. I keeps the includes together to those modules they belong to and can be easier to share. In the recent past I've seen a lot of Open Source programs/libraries follow this step by putting their headerfiles in an own subdir when getting installed, which looks more nicely and cleaner. The same thing I've been detecting for some libraries as well and a better example to show what I like to refer to is when we look at GNOME. Some people might know that GNOME has moved from 1.x to 2.x and that both Desktops can be installed side by side. This is realizable because of good versioning of the libraries and good organization of the includes. e.g.:

${prefix}/include/evolution/1.4/*
${prefix}/include/evolution/1.6/*

${prefix}/lib/evolution/1.4/*
${prefix}/lib/evolution/1.6/*

${prefix}/lib/libevolution-1.4.so
${prefix}/lib/libevolution-1.6.so

${prefix}/libexec/evolution/1.4/*
${prefix}/libexec/evolution/1.6/*

And so on. This is just an example and there are different possibilities howto accomplish this. All I noticed was that a few things inside KDE already work like this with a clean versioning of the libraries, a better organization of the includes and other things. Therefore I would like to ask whether these things can be taken care of once the movement to KDE 4 and QT 4 starts. It would really make things look a lot more pleasing under the hood. This is something developers can do within a couple of minutes once the port starts and then keep using this throughly.

Same for KIO'slaves etc. they could be placed in a subdir for better organization (there are probably other things too that could be organized better).

Also a thing is (only what I noticed) is that some stuff is simply copied 1:1 from A to B (sometimes I see subdirs like 'CVS') showing up once KDE applications or libraries are installed and often I noticed that files are not being redated to the actual date when getting installed or getting the right owner. This is again something that might be interesting to improve and the majority of software I know today for Open Source obey these rules (installing == redating to current date and chaning owner to either root.root) or what's defined by the 'install' program used inside the Makefiles.

I hope I was able to interest developers here. These are mainly the only things I'd personally like to see improved. Please don't take any offense with my explaination (I usually get criticised for this but at the end I only like to help improving KDE with some ideas I have).
Comment 1 Dik Takken 2004-08-16 20:57:03 UTC
Good idea. It will also be easier to remove all files of a specific KDE component without having to download the source first.
Comment 2 Ali Akcaagac 2004-08-17 02:56:06 UTC
To add a little note - library versioning is important too. Most of the KDE libraries don't support versioning and once you install some new stuff from CVS then it might be possible that you hit API differences which then leads to undefined symbols. So in case you are mixing older KDE 3.0, 3.1, 3.2, 3.3 stuff on one Desktop then it might make sense using different versions of the library which guarantees reliable operation of the stuff.
Comment 3 Philippe Fremy 2004-08-17 11:40:16 UTC
You should post this to kde-core-devel. This is the place where the people who can do this kind of change are.
Comment 4 Ali Akcaagac 2004-08-17 12:31:48 UTC
Yeah I had that in mind too. After the chat on IRC (KDE-Devel) I was told to report this to bugzilla only under the kde-libs category. I am also not subscribed to the kde-core-devel mailing list. If anyone likes, please feel free to forward this there.
Comment 5 David Faure 2004-08-17 15:01:20 UTC
On Tuesday 17 August 2004 14:44, Ali Akcaagac wrote:
> http://bugs.kde.org/show_bug.cgi?id=86986

To save everyone some time, this is about where to install header files, with
a proposal for ${prefix}/include/<something>/<version>/*.h
where <something> is the module, library, or application name.
We do it a little bit already, but not consistently.
Not sure what kdecore and kdeui should do in that scheme though.

Comment 6 Thiago Macieira 2004-08-17 17:13:35 UTC
David Faure wrote:
>On Tuesday 17 August 2004 14:44, Ali Akcaagac wrote:
>> http://bugs.kde.org/show_bug.cgi?id=86986
>
>To save everyone some time, this is about where to install header
> files, with a proposal for
> ${prefix}/include/<something>/<version>/*.h

I think we should do that only for namespaced classes.

I.e., #include <namespace/class.h> in order to have Namespace::Class. 
That would bring back the discussion on what to namespace and when. See 
lists.kde.org for previous threads on that discussion.

Comment 7 Havoc Pennington 2004-08-19 02:44:47 UTC
http://ometer.com/parallel.html is one approach to consider.
Comment 8 Ali Akcaagac 2004-10-31 14:36:13 UTC
Did we have a decision for this now or any other communicative feedback ?
Comment 9 Stephan Kulow 2004-10-31 15:19:47 UTC
What do you expect from a KDE4 wish?
Comment 10 Hans Meine 2005-06-09 18:01:12 UTC
I am against the "redating" (touching) of installed headers (at the end of the original report).  That can be done by distributions (as Gentoo does, for example), but for us developers that'd mean recompiling everything even though nothing might have changed.  I prefer to have meaningful "modification" times.
Comment 11 Ali Akcaagac 2005-06-09 22:44:29 UTC
Hans, there is a reason why modern distributions have an 'install' utility either in /bin or /usr/bin. This is the recommended way of installing stuff properly and nothing that should be put on the burden of a distribution. Almost every package I know that I compile and install follows the rules of using the install script and these usually take care to install files correctly by giving correct user group flags, was well as correct permissions and time.

With KDE (as is currently) there are plenty of things that only get 'copied' (as I have the impression) from a) to b) and some stuff even keep the old dates, old permissions, old user group flags and sometimes even not required '.svn' subdirs are copied to prefix too.

I think it's not a matter how 'you' want it or how 'I' want it, it's a matter of how it's done correctly and here we (or you, as you wish) should follow the way and approach of other projects. The chance for KDE 4 to achieve this goal. It's a well integrated and very functional Desktop, now make it follow, integrate, obey (or how you like to name it) as every other package existing that you compile and install from sources.
Comment 12 David Faure 2009-04-06 20:20:21 UTC
So, this is a request for ${prefix}/include/kdecore/*.h, a bit like Qt itself is set up? Might make sense, but now it's for kde5. Meanwhile, when compiling from sources, you can just install into a custom prefix, not e.g. /usr.

For other things like kioslaves, they are now in a kde4 subdir, so that part is fixed (no reason to have 4.1/4.2/etc, since they are forward compatible).

I admit that I'm a bit surprised to see so many votes for this wish. The location of files in kde4 is -that- unbearable?
Comment 13 Malte S. Stretz 2009-04-07 17:53:39 UTC
I think the main reason why I voted for this bug ages ago was that I ran into some issues with having two KDE versions installed in parallel (still on Gentoo back then). Ie. I was in favor of the /usr/include/kde/$major.$minor back then. Can't remember the details though.
Comment 14 David Faure 2011-02-15 21:27:09 UTC
Two development versions of KDE in the same prefix can't work anyway, if the library names don't change: even if you had /usr/include/kde4/klineedit.h and /usr/include/kde5/klineedit.h, you would still have only one /usr/lib/libkdeui.so picked up by the linker. The only way would be to put the major version number into the lib name like Windows people do, like libkdeui5.so. This might be an idea. But we'll have to see what Qt does though, since it won't help kde devs if only one QtCore.so can be there anyway.