On Monday 11 November 2013, Aaron J. Seigo wrote:
On Sunday, November 3, 2013 20:51:57 Alexander Neundorf wrote:
I wanted to release ECM as fast as possible, since this was one of the
main points I got from the platform meeting in Randa in June 2011:
people want to be able to use cmake
On 2013-11-11, Aaron J. Seigo ase...@kde.org wrote:
would that work for everyone?
I don't think it solves the actual hard point:
Where should the final home for the stuff in ecm/kde-modules be ?
I'll like to reiterate what I suggested should happen with it:
KDEInstallDirs.cmake :
Keep it as
On Monday 11 November 2013, Aaron J. Seigo wrote:
...
in my mind this allows:
* an immediate release of ecm
* allows KDE to back it rather than have ecm distanced from KDE
* this gives ecm a needed “reference customer”
* this gives KDE a first step into the “we’re a community
On Tuesday 12 November 2013 20:04:38 Sune Vuorela wrote:
On 2013-11-11, Aaron J. Seigo ase...@kde.org wrote:
would that work for everyone?
I don't think it solves the actual hard point:
Where should the final home for the stuff in ecm/kde-modules be ?
Agreed. Although that's from the KF5
On Tuesday 12 November 2013, Kevin Ottens wrote:
On Tuesday 12 November 2013 20:04:38 Sune Vuorela wrote:
On 2013-11-11, Aaron J. Seigo ase...@kde.org wrote:
would that work for everyone?
I don't think it solves the actual hard point:
Where should the final home for the stuff in
On Sunday, November 3, 2013 20:51:57 Alexander Neundorf wrote:
I wanted to release ECM as fast as possible, since this was one of the main
points I got from the platform meeting in Randa in June 2011: people want to
be able to use cmake stuff from KDE without depending on kdelibs.
Stephen
On Sunday 10 November 2013, David Faure wrote:
On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote:
To build karchive itself, they would need cmake + tier0-kf5 + ECM
Which is exactly what I want to avoid.
You wrote To build software using karchive with cmake, they still need
On Sunday 10 November 2013, Alexander Neundorf wrote:
On Sunday 10 November 2013, David Faure wrote:
On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote:
To build karchive itself, they would need cmake + tier0-kf5 + ECM
Which is exactly what I want to avoid.
You wrote To
On Sunday 10 November 2013 16:27:06 Alexander Neundorf wrote:
On Sunday 10 November 2013, Alexander Neundorf wrote:
On Sunday 10 November 2013, David Faure wrote:
On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote:
To build karchive itself, they would need cmake + tier0-kf5 +
On Sunday 10 November 2013, Kevin Ottens wrote:
On Sunday 10 November 2013 16:27:06 Alexander Neundorf wrote:
On Sunday 10 November 2013, Alexander Neundorf wrote:
On Sunday 10 November 2013, David Faure wrote:
On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote:
To build
On Sunday 10 November 2013 17:30:23 Alexander Neundorf wrote:
On Sunday 10 November 2013, Kevin Ottens wrote:
Now I guess we could do it for both, but it looks tricky for something
which would have a separate release cycle like ECM. While for the tier0
the release cycle would be tied to the
On Saturday 02 November 2013 21:12:08 David Faure wrote:
On Saturday 02 November 2013 13:44:55 Stephen Kelly wrote:
Alexander Neundorf wrote:
In case we decide to go this way (i.e. the my ideal view plus optional
downloading), and we should hear Stephens opinion on that,
My opinion:
On Saturday 02 November 2013, Luca Beltrame wrote:
Rex Dieter wrote:
I can vouche for fedora/redhat that the buildsystem does not have
internet access.
Likewise, the OBS for openSUSE does not have net access during building.
as I said, it is trivial and IMO mandatory to have that
On Friday 01 November 2013, Sune Vuorela wrote:
On 2013-11-01, Alexander Neundorf neund...@kde.org wrote:
Anyway, attached is a quick experiment, which adds the 3 KDE*.cmake
files=
from=20
extra-cmake-modules/ to kf5umbrella/, by that turning it into tier0/,
wit= h the=20
On Saturday 02 November 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
In case we decide to go this way (i.e. the my ideal view plus optional
downloading), and we should hear Stephens opinion on that,
My opinion:
1) The current situation with ECM and KF5 is just fine.
do you
Alexander Neundorf wrote:
e.g. keeping code like always, unconditional, hardcoded searching for
QtCore
'hardcoded' doesn't have any meaning in this context.
The code you are talking about is neither 'always', nor 'unconditional'.
if(CMAKE_MINIMUM_REQUIRED_VERSION VERSION_LESS 2.8.13)
On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote:
On Saturday 02 November 2013, David Faure wrote:
On Saturday 02 November 2013 13:44:55 Stephen Kelly wrote:
Alexander Neundorf wrote:
In case we decide to go this way (i.e. the my ideal view plus
optional downloading), and
On Sunday 03 November 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
e.g. keeping code like always, unconditional, hardcoded searching for
QtCore
'hardcoded' doesn't have any meaning in this context.
The code you are talking about is neither 'always', nor 'unconditional'.
come
On Sunday 03 November 2013, Kevin Ottens wrote:
On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote:
...
To build software using an installed karchive, they don't need anything
but a compiler.
To build software using karchive with cmake, they still need only cmake.
To build
On 2013-11-03, Alexander Neundorf neund...@kde.org wrote:
This code unconditionally searches for QtCore (and sets a target property
where I'm not sure how many people here can understand what's going on).
It is hopefully a temporary hack that shouldn't be in that file.
Sometimes, temporary
Sune Vuorela wrote:
On 2013-11-03, Alexander Neundorf neund...@kde.org wrote:
This code unconditionally searches for QtCore (and sets a target property
where I'm not sure how many people here can understand what's going on).
It is hopefully a temporary hack that shouldn't be in that file.
On Sunday 03 November 2013, Sune Vuorela wrote:
On 2013-11-03, Alexander Neundorf neund...@kde.org wrote:
This code unconditionally searches for QtCore (and sets a target property
where I'm not sure how many people here can understand what's going on).
It is hopefully a temporary hack that
Alexander Neundorf wrote:
On Sunday 03 November 2013, Sune Vuorela wrote:
On 2013-11-03, Alexander Neundorf neund...@kde.org wrote:
This code unconditionally searches for QtCore (and sets a target
property where I'm not sure how many people here can understand what's
going on).
It is
Rex Dieter wrote:
I can vouche for fedora/redhat that the buildsystem does not have internet
access.
Likewise, the OBS for openSUSE does not have net access during building.
--
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: 6E1A4E79
Alexander Neundorf wrote:
In case we decide to go this way (i.e. the my ideal view plus optional
downloading), and we should hear Stephens opinion on that,
My opinion:
1) The current situation with ECM and KF5 is just fine.
2) There are other issues to work on which are more relevant, urgent
Stephen Kelly wrote:
Alexander Neundorf wrote:
In case we decide to go this way (i.e. the my ideal view plus optional
downloading), and we should hear Stephens opinion on that,
FYI:
http://public.kitware.com/Bug/view.php?id=8471
Thanks,
Steve.
On Saturday 02 November 2013 13:44:55 Stephen Kelly wrote:
Alexander Neundorf wrote:
In case we decide to go this way (i.e. the my ideal view plus optional
downloading), and we should hear Stephens opinion on that,
My opinion:
1) The current situation with ECM and KF5 is just fine.
2)
Hello,
On Friday 01 November 2013 11:23:14 Mirko Boehm wrote:
On 11/01/2013 10:46 AM, Alexander Neundorf wrote:
[1] Why not merge that into CMake ? For quicker releases, and even easier
contributing. Also Bill once said that in hindsight he would have prefered
if cmake would not ship any
On Friday 01 November 2013 12:53:17 Alexander Neundorf wrote:
On Friday 01 November 2013, Kevin Ottens wrote:
Hello,
On Friday 01 November 2013 11:23:14 Mirko Boehm wrote:
On 11/01/2013 10:46 AM, Alexander Neundorf wrote:
[1] Why not merge that into CMake ? For quicker releases, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/2013 01:37 PM, Kevin Ottens wrote:
if a package foo uses ecm (or that non existing tier0 cmake package) itself,
this does not mean that another package which uses foo, also needs ecm (or
that tier0 package) at buildtime.
Well, if the
On 2013-11-01, Kevin Ottens er...@kde.org wrote:
So far we chose the have it in cmake/ecm route. If we had what Mirko =
refers=20
to, then that'd open the door to another solution.
And it would open the first door towards alienating linux distributions.
Of course, we could say and so what?.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/2013 01:53 PM, Sune Vuorela wrote:
So far we chose the have it in cmake/ecm route. If we had what Mirko =
refers=20
to, then that'd open the door to another solution.
And it would open the first door towards alienating linux
On Friday 01 November 2013, Mirko Boehm wrote:
On 11/01/2013 01:37 PM, Kevin Ottens wrote:
if a package foo uses ecm (or that non existing tier0 cmake package)
itself,
this does not mean that another package which uses foo, also needs ecm
(or that tier0 package) at buildtime.
On 2013-11-01, Mirko Boehm mi...@kde.org wrote:
Anyone up for hacking this up next week? I am available starting Monday
afternoon.
Before you start hacking, please consider the following:
http vs https? should http even be allowed?
certificate handling?
how to do ssl? a library? will
On Friday 01 November 2013, Mirko Boehm wrote:
On 11/01/2013 01:53 PM, Sune Vuorela wrote:
So far we chose the have it in cmake/ecm route. If we had what Mirko =
refers=20
to, then that'd open the door to another solution.
And it would open the first door towards alienating linux
On Friday, November 01, 2013 11:57:35 Kevin Ottens wrote:
Then it is time to think of a way to integrate cmake with the separate
source of find_modules. Algorithmically, it would look like
PROJECT(MyApplication)
FIND_MODULES_REPOSITORY(http://ecm.kde.org;)
FIND_PACKAGES(KF5
On Friday 01 November 2013 17:04:12 Sebastian Kügler wrote:
On Friday, November 01, 2013 11:57:35 Kevin Ottens wrote:
Then it is time to think of a way to integrate cmake with the separate
source of find_modules. Algorithmically, it would look like
PROJECT(MyApplication)
2013/11/1 Kevin Ottens er...@kde.org:
Hello,
On Friday 01 November 2013 11:23:14 Mirko Boehm wrote:
On 11/01/2013 10:46 AM, Alexander Neundorf wrote:
[1] Why not merge that into CMake ? For quicker releases, and even easier
contributing. Also Bill once said that in hindsight he would have
On Friday 01 November 2013 15:46:30 Nicolás Alvarez wrote:
2013/11/1 Kevin Ottens er...@kde.org:
Hello,
On Friday 01 November 2013 11:23:14 Mirko Boehm wrote:
On 11/01/2013 10:46 AM, Alexander Neundorf wrote:
[1] Why not merge that into CMake ? For quicker releases, and even
easier
On 11/01/2013 10:46 AM, Alexander Neundorf wrote:
[1] Why not merge that into CMake ? For quicker releases, and even easier
contributing. Also Bill once said that in hindsight he would have prefered
if
cmake would not ship any find-modules itself at all. So one could imagine
that cmake
On Friday 01 November 2013, Treeve Jelbert wrote:
On Friday 01 November 2013 15:46:30 Nicolás Alvarez wrote:
...
Maven is a disgusting monstrosity used by the Java crowd where
backwards compatibility rarely exists, and the approach to make things
not break is to make packages depend on
On Friday 01 November 2013, Alexander Neundorf wrote:
...
If that option was enabled when installing kf5umbrella, kf5umbrella will
load that embedded ECM when asked for ECM.
In this quick hack attached here
find_package(KF5Umbrella)
unconditionally loads KDECMakeSettings.cmake.
The version
On Fri, November 1, 2013 20:06:43 Alexander Neundorf wrote:
Anyway, attached is a quick experiment, which adds the 3 KDE*.cmake files
from extra-cmake-modules/ to kf5umbrella/, by that turning it into tier0/,
with the optional ability (-DWITH_ECM) to download ECM and install ECM when
building
On Friday 01 November 2013, Michael Pyne wrote:
On Fri, November 1, 2013 20:06:43 Alexander Neundorf wrote:
Anyway, attached is a quick experiment, which adds the 3 KDE*.cmake files
from extra-cmake-modules/ to kf5umbrella/, by that turning it into
tier0/, with the optional ability
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/2013 06:46 PM, Nicolás Alvarez wrote:
and so forth. That would be a real breakthrough. It is related to the
approach taken by Maven and others. All it takes is a built-in way for
CMake to download the find_modules into a cache location
2013/11/1 Mirko Boehm mi...@kde.org:
I'm also surprised at Almost everybody has internet access for build
machines. Is there *any* Linux distro where that's the case??
Pretty strong language. Not much proof. Do you *know* how Red Hat or SuSE
build their packages?
No I don't. I didn't say no
On 2013-11-01, Alexander Neundorf neund...@kde.org wrote:
Anyway, attached is a quick experiment, which adds the 3 KDE*.cmake files=
from=20
extra-cmake-modules/ to kf5umbrella/, by that turning it into tier0/, wit=
h the=20
optional ability (-DWITH_ECM) to download ECM and install ECM when
On 2013-11-01, Mirko Boehm mi...@kde.org wrote:
To me, build systems should not download anything sounds like a movie
from the 80ies.
To me, build systems fetches code and executes it sounds like a bad
horror movie.
For example, from a developers point of view, what is the difference between
On Fri, November 1, 2013 22:41:29 Mirko Boehm wrote:
In my opinion, a central repository of community maintained find module
packages has a chance of making a real difference.
I'm not at all opposed to a centralized module of Find* cmake modules, in case
I left that impression. But this
Mirko Boehm wrote:
Pretty strong language. Not much proof. Do you *know* how Red Hat or SuSE
build their packages?
I can vouche for fedora/redhat that the buildsystem does not have internet
access.
-- rex
___
Kde-frameworks-devel mailing list
On Wednesday 30 October 2013 21:19:43 Alexander Neundorf wrote:
On Wednesday 30 October 2013, Stephen Kelly wrote:
Hello,
Soon I will be replacing code like
find_package(KF5 REQUIRED CMake Compiler InstallDirs)
with
include(KDEInstallDirs)
include(KDECMakeSettings)
Alexander Neundorf wrote:
find_package(KF5 ... COMPONENTS karchive solid kcompletion)
call in their CMakeLists.txt and get the same results.
And if this works for tier3 libs, why not just do the same in tier2 and
also in tier1...
Because tier1 doesn't depend on or find KF5 at all, by
On Thursday 31 October 2013, David Faure wrote:
On Wednesday 30 October 2013 21:19:43 Alexander Neundorf wrote:
On Wednesday 30 October 2013, Stephen Kelly wrote:
Hello,
Soon I will be replacing code like
find_package(KF5 REQUIRED CMake Compiler InstallDirs)
with
On Thursday 31 October 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
find_package(KF5 ... COMPONENTS karchive solid kcompletion)
call in their CMakeLists.txt and get the same results.
And if this works for tier3 libs, why not just do the same in tier2 and
also in tier1...
On Thursday 31 October 2013 17:54:06 Alexander Neundorf wrote:
IOW, those three files exist only for KF5, and no other reason.
This contradicts use KDECMakeSettings.cmake in gammaray if you want automatic
RPATH handling as you told me some time ago.
In other words, these things are convenience
Hello,
Soon I will be replacing code like
find_package(KF5 REQUIRED CMake Compiler InstallDirs)
with
include(KDEInstallDirs)
include(KDECMakeSettings)
include(KDECompilerSettings)
As I've said before, it makes no sense that we have to find KF5 in order to
build KF5, so I'm going to
On Wednesday 30 October 2013, Stephen Kelly wrote:
Hello,
Soon I will be replacing code like
find_package(KF5 REQUIRED CMake Compiler InstallDirs)
with
include(KDEInstallDirs)
include(KDECMakeSettings)
include(KDECompilerSettings)
As I've said before, it makes no sense that
57 matches
Mail list logo
