| Summary: | Arrange includes and files in a better way for KDE 4 | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Ali Akcaagac <aliakc> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | wishlist | CC: | mss |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Good idea. It will also be easier to remove all files of a specific KDE component without having to download the source first. 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. You should post this to kde-core-devel. This is the place where the people who can do this kind of change are. 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. 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.
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. http://ometer.com/parallel.html is one approach to consider. Did we have a decision for this now or any other communicative feedback ? What do you expect from a KDE4 wish? 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. 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. 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?
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. 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. Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have implemented this wish. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann |
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).