Re: Something for the weekend
On Friday 17 February 2012 17:00:03 Stephen Kelly wrote:
3) Remove dependencies from frameworks on kdecore and others.
For example tier1/kdbusaddons depends in some way on Nepomuk:
stephen@hal:~/dev/src/kf5/tier1/kdbusaddons{frameworks}$ git grep -i nepomuk
src/kdbusconnectionpool.cpp: * This file is part of the Nepomuk KDE
project. src/kdbusconnectionpool.cpp:
QString::fromLatin1(NepomukQueryServiceConnection%1).arg(newNumber()) ) )
src/kdbusconnectionpool.h: * This file is part of the Nepomuk KDE project.
Nah, that's just an old comment ;-)
I'll remove it.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: From kdelibs4 to KDE frameworks... how to make KDE more cross platform...
hate to chime in as well, but i think replacing the Windows shell should definitely be something that's looked at. imho it makes a lot of sense. face it, the Windows shell sucks. why are we replacing their apps and adding our own (dolphin kicking explorer's butt)? because the default ones are terrible. honestly i see that as the point of running kde. whether or not it's optional is something else, but it lets people who love kde, hate windows, but are forced to use it (me especially)..have that much more bearability(pft, what do you mean it isn't a word?). just like we run apps in wine so that we don't have to boot out of our precious kernels and workspaces and apps, the same should be equally sought after. if a non-linux port is going to be done at all -- do it all the way, the right way, imho. just go ahead and ask me about all of the annoyances that it really brings on me -- honestly, i could rant on for days about flaws from little to small that really make me loathe having to be in windows for another second. the way i see it, KDE helps alleviate that, and plasma is awesome (explorer is just a sad thing imho). and i'm certain there are tons of other users who are forced to use windows because of apps x y and z which aren't possible in a VM or wine. while i'm not necessarily for the port to windows, just because i see it as sort of taking away the uniqueness of linux and leaving the why bother switching?...but i also see the other side as well, and appreciate the port. kuiserver shouldn't be difficult to cut out of the picture. it just requires mapping of e.g. the plasma dataengine directly to kio when kuiserver is not going to be enabled.. -- Shaun Reich, KDE Software Developer (kde.org) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Strange commit to FindKDE4Internal.cmake
Am 17.02.2012 15:07, schrieb Alexander Neundorf:
Hi Alex
I saw a recent commit from you to FindKDE4Internal.cmake:
http://quickgit.kde.org/index.php?p=kdelibs.gita=commitdiffh=ca501aa9f4c1e7adcd42accbd53538502ba50ce3hp=3186e7a5f3acfaa5b5ac1b5cce9315eb53f54655
with the commit message on win32 we need access to the installed cmake
modules dir .
This looks wrong. Why do you add
${CMAKE_INSTALL_PREFIX}/share/apps/cmake/modules to CMAKE_MODULE_PATH ?
In general this directory does not even exist at buildtime (since you can
install to anywhere).
Who did you need ?
We ned to do that properly.
It would be great if you could join the kde-frameworks mailing list, so we can
make sure that the modularized kdelibs work properly under Windows too.
Alex
This related to the commit before
http://quickgit.kde.org/index.php?p=kdelibs.gita=commith=3186e7a5f3acfaa5b5ac1b5cce9315eb53f54655,
which moves out FindKDEWin.cmake and related from kdelibs into kdewin
package.
To let cmake be able to find this files, the path to the installed cmake
module directory is required.
Ralf
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Which package will provide the common KDE library version number ?
Am Freitag, 17. Februar 2012, 19:48:33 schrieb Alexander Neundorf: Hi, right now the common version number for libraries in kdelibs/KDE is defined in KDE4Defaults.cmake: # define the generic version of the libraries here # this makes it easy to advance it when the next KDE release comes # Use this version number for libraries which are at version n in KDE # version n set(GENERIC_LIB_VERSION 4.8.0) set(GENERIC_LIB_SOVERSION 4) # Use this version number for libraries which are already at version n+1 # in KDE version n set(KDE_NON_GENERIC_LIB_VERSION 5.8.0) set(KDE_NON_GENERIC_LIB_SOVERSION 5) So whichever package wants to have a common version number with the rest of KDE, uses this. (rest of KDE is what?) Which is somehow broken anyway for packages outside of kdelibs. E.g. compile a package from KDE SC 4.7 against kdelibs 4.8, that one gets the version number of kdelibs 4.8. Now compile the same package from KDE SC 4.8 against kdelibs 4.8 as well, same version number as before. Not sure if this does not provide the base for some problems. IMHO each package should have its own GENERIC_LIB_* vars, for some saneness. Otherwise those GENERIC_LIB* vars could also be set to those of Qt or whatever other base lib. What reason would there be to have them versioned in the same way the current kdelibs is versioned? Friedrich ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Which package will provide the common KDE library version number ?
On Friday 17 February 2012, Friedrich W. H. Kossebau wrote: Am Freitag, 17. Februar 2012, 19:48:33 schrieb Alexander Neundorf: Hi, right now the common version number for libraries in kdelibs/KDE is defined in KDE4Defaults.cmake: # define the generic version of the libraries here # this makes it easy to advance it when the next KDE release comes # Use this version number for libraries which are at version n in KDE # version n set(GENERIC_LIB_VERSION 4.8.0) set(GENERIC_LIB_SOVERSION 4) # Use this version number for libraries which are already at version n+1 # in KDE version n set(KDE_NON_GENERIC_LIB_VERSION 5.8.0) set(KDE_NON_GENERIC_LIB_SOVERSION 5) So whichever package wants to have a common version number with the rest of KDE, uses this. (rest of KDE is what?) either those which made up kdelibs before, or those + kdesupport, or all of KDE SC, or those which will be considered KDE frameworks, Yes, it is becoming very unclear. Which is somehow broken anyway for packages outside of kdelibs. E.g. Maybe. So, how do we do it for those that were kdelibs ? When we started with KDE4, it was important that there is one place where the version number has to be updated, and not 50 all over svn. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDECompilerSettings.cmake added to extra-cmake-modules
On Saturday 18 February 2012, David Faure wrote: On Friday 17 February 2012 18:58:04 Alexander Neundorf wrote: Or should we just declare that by including that file (which you don't have to do) you just get those flags automatically ? That seems like the best solution to me. Why use two lines to do what you can do in one line. I think so too. For those who want to have more control, some control variables could be provided: set(KDE_BUILD_FLAGS_SKIP_LINK_FLAGS TRUE) set(KDE_BUILD_FLAGS_SKIP_DEFINITIONS TRUE) include(KDEBuildFlags) And, in the mean time I'm not sure KDECompilerSettings.cmake is the best name... This is much like include(KDE4Defaults.cmake). In fact they could possibly be merged, if that one still exists. This or a similar file will stay. It will have a bunch of settings. I think I'll move the RPATH settings from KDEBuildFlags.cmake to this file. This would mean, if you just want to use some KDE libraries, you would do: find_package(extra-cmake-modules REQUIRED) find_package(kcore) find_package(kui) ...and then use them. If you want to use the compile flags and link flags as suggested by the KDE team, you additionally do include(KDEBuildFlags) If you additionally want to use the various other cmake settings considered useful by the KDE team, you do include(KDESettings) If you additionally want to use the install locations as defined by KDE, you do include(KDEInstallDirs) So, how to name these files ? For the compile and link flags: KDE + (Compile|Build|Compiler) + (Flags|Settings) ? for the cmake settings: KDESettings, KDEDefaults, KDECMakeSettings ? Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Which package will provide the common KDE library version number ?
On Friday 17 February 2012 20:37:12 Sune Vuorela wrote: On 2012-02-17, Alexander Neundorf neund...@kde.org wrote: Do we still want a such a common version number ? If yes, who (which file/package) should define it ? No. It basically doesn't make sense. Also not in its current usage. if I e.g. take a kdepimlibs 4.3 and build against kdelibs 4.8, all my pimlibs libraries are versioned like they were pimlibs4.8. That behavior is indeed a problem. Still we need a way to ensure that we have the same version number accross all frameworks when we release. And to avoid the current problem it sounds likely to me that it would be a file generated when we create the release tarballs. CMake could then pick it up when executed, if said file is not present (e.g. developer build) then CMake should probably use the git revision instead. How does that sound? Sensible or smoking crack? Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Which package will provide the common KDE library version number ?
On Saturday 18 February 2012, Kevin Ottens wrote:
On Friday 17 February 2012 20:37:12 Sune Vuorela wrote:
On 2012-02-17, Alexander Neundorf neund...@kde.org wrote:
Do we still want a such a common version number ?
If yes, who (which file/package) should define it ?
No. It basically doesn't make sense. Also not in its current usage.
if I e.g. take a kdepimlibs 4.3 and build against kdelibs 4.8, all my
pimlibs libraries are versioned like they were pimlibs4.8.
That behavior is indeed a problem. Still we need a way to ensure that we
have the same version number accross all frameworks when we release.
In general, when we build one git repository, it doesn't know anything about
its environment, except:
1. the packages it depends on via find_package()
2. variables defined from the outside via -DFoo=foo
3. ...and environment variables
4. files existing somewhere relative to the source or build tree
For defining the library version numbers, somewhere must be something like:
set_target_properties(Foo PROPERTIES VERSION ${VERSION_NUMBER}
SOVERSION ${SOVERSION_NUMBER} )
These two version numbers should always have sensible values.
I didn't test, but I'm not sure a libfoo.so.3dea0a0c6be9df8db4d01d6d5 actually
works.
Option 2) is basically out of the game because I am very sure we should not
define the version number of a library via a command line parameter. Same for
option 3.
Seriously, if the libraries share something, which makes them KDE frameworks
libraries, then this something should exist.
Currently, this something seems to contain the shared version numbers, and
the shared install directories.
It's basically a file which specifies properties of KDE frameworks
libraries.
I.e. a package consisting more or less only of this one (cmake) file holding
some properties.
Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Which package will provide the common KDE library version number ?
On Saturday 18 February 2012 17:50:28 Alexander Neundorf wrote:
On Saturday 18 February 2012, Kevin Ottens wrote:
On Friday 17 February 2012 20:37:12 Sune Vuorela wrote:
On 2012-02-17, Alexander Neundorf neund...@kde.org wrote:
Do we still want a such a common version number ?
If yes, who (which file/package) should define it ?
No. It basically doesn't make sense. Also not in its current usage.
if I e.g. take a kdepimlibs 4.3 and build against kdelibs 4.8, all my
pimlibs libraries are versioned like they were pimlibs4.8.
That behavior is indeed a problem. Still we need a way to ensure that we
have the same version number accross all frameworks when we release.
In general, when we build one git repository, it doesn't know anything about
its environment, except:
1. the packages it depends on via find_package()
2. variables defined from the outside via -DFoo=foo
3. ...and environment variables
4. files existing somewhere relative to the source or build tree
For defining the library version numbers, somewhere must be something like:
set_target_properties(Foo PROPERTIES VERSION ${VERSION_NUMBER}
SOVERSION ${SOVERSION_NUMBER} )
These two version numbers should always have sensible values.
I didn't test, but I'm not sure a libfoo.so.3dea0a0c6be9df8db4d01d6d5
actually works.
Option 2) is basically out of the game because I am very sure we should not
define the version number of a library via a command line parameter. Same
for option 3.
Which leaves us the option 4 which is what I proposed in my previous email for
release tarballs. You point out indeed a proper issue for the hash in version
number for a library in the case of developer builds... We'd need to derive a
proper version number in such case, not sure how.
Seriously, if the libraries share something, which makes them KDE
frameworks libraries, then this something should exist.
Currently, this something seems to contain the shared version numbers, and
the shared install directories.
It's basically a file which specifies properties of KDE frameworks
libraries.
I.e. a package consisting more or less only of this one (cmake) file holding
some properties.
Which would then recreate the problem Sune pointed out. Depending on which
package got picked up you change the version number of the library even though
the code base is the same.
So the other possibility would be to have the version number in the main
CMakeLists.txt of each framework which raises potential consistency issues...
Solution would then be that the scripts used to generate the release tarballs
verify the version is properly set everywhere.
I really think the solution lies in the way we execute the release, not at
build time.
Regards.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud patron of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDEInstallDirs.cmake in extra-cmake-modules
On Saturday 18 February 2012 18:01:26 Alexander Neundorf wrote: On Saturday 18 February 2012, Kevin Ottens wrote: On Friday 17 February 2012 00:41:49 Alexander Neundorf wrote: On Thursday 16 February 2012, Stephen Kelly wrote: I'd still go with kf5. I think we should keep the kde in the string, so the name stays present. That's why I also named the file KDEInstallDirs.cmake and not KF5InstallDirs.cmake. Comments ? I think kf5 is a name that kde can own anyway, and which we can use. I mean, kde is a well-known name, we should not hide it. That's trying to put some marketing details in a technical aspect IMHO. It should map to the product, and product code name if KF5. No, it's not. See my other mail. Currently there is no KF5, and there are no plans to have one. Instead we have plans to make a set of libraries which are called together KDE frameworks. KDEInstallDirs.cmake is in extra-cmake-modules since yesterday. This is definitely not a KF5InstallDirs.cmake. There is nothing in it which is KF5-specific. Sorry, I apparently misunderstood what you meant or replied at the wrong place (as you can see in the other thread I didn't ask for file rename). I was talking about the variable names, we used to have a KDE4_ prefix I just meant it should be a KF5_ prefix in such cases now. My apologies for the noise then. :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: srcdir/cmake/modules/ vs. srcdir/cmake/
On Saturday 18 February 2012, Kevin Ottens wrote: On Saturday 18 February 2012 17:35:14 Alexander Neundorf wrote: On Saturday 18 February 2012, Kevin Ottens wrote: Sounds good to me. Worth putting in the directory policy? http://community.kde.org/Frameworks/Policies#Framework_directory_struct ure We're basically saying nothing about cmake, I wonder how common that will be to have cmake modules in a single framework, aren't we pushing to have as many as possible in ECM? No, not as many as possible, only those which are somewhat generic and good enough. A good sign that it is somewhat generic is if there exists already a Find-module for this package somewhere else. If some library needs some exotic library, it should be good enough if it contains the Find-module itself. One policy is: don't install Find-modules ! (except via extra-cmake-modules) Then please amend with details about a cmake folder: http://community.kde.org/Frameworks/Policies#Framework_directory_structure Done. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
