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 'fix
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
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(KD
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 d
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)
>
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 convenien
On Thursday 31 October 2013, David Faure wrote:
> 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 s
On Friday 01 November 2013, Alexander Neundorf wrote:
> As a fact, all KF5 frameworks on these three files, including the
...all KF5 frameworks *depend* on these three files, including the...
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 itse
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
On 2013-11-01, Mirko Boehm 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 and update them when
> needed, or on request.
>
> This w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/2013 11:25 AM, Sune Vuorela 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
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 even
> > > easier contributing. Also Bill once said that in
On Friday 01 November 2013, Mirko Boehm wrote:
> On 11/01/2013 11:25 AM, Sune Vuorela 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 lo
Alexander Neundorf 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.
Plasma does currently, but that might be a bug.
Thanks,
Steve.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/2013 12:56 PM, Alexander Neundorf wrote:
>> As for internet access, I doubt this will be a problem.
> there would have to be a way to do this without internet access.
> There are setups, where developers simply don't want to depend on some
>
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
-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, i
On 2013-11-01, Kevin Ottens 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?". But that
-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 d
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 b
On 2013-11-01, Mirko Boehm 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 cmake accept a
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 towar
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(KF
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)
On Friday 01 November 2013 13:37:56 Kevin Ottens wrote:
> 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 Neun
2013/11/1 Kevin Ottens :
> 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 pre
On Friday 01 November 2013 15:46:30 Nicolás Alvarez wrote:
> 2013/11/1 Kevin Ottens :
> > 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
> >> > ea
> 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
> > t
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 o
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 vers
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
> buildi
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 cach
2013/11/1 Mirko Boehm :
>> 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 dis
On 2013-11-01, Alexander Neundorf 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 buildi=
> ng
On 2013-11-01, Mirko Boehm 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
> me
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 centr
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
Kde
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, urge
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
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,
> >
>
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 do
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 we should hear Stephens opinion on that,
> >
> > My opi
On Friday 01 November 2013, Sune Vuorela wrote:
> On 2013-11-01, Alexander Neundorf 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
> > optio
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.
d
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)
f
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 do
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'.
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 bui
On Sunday 03 November 2013 14:37:33 Alexander Neundorf wrote:
> 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 bui
On 2013-11-03, Alexander Neundorf 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 hacks in developm
Sune Vuorela wrote:
> On 2013-11-03, Alexander Neundorf 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.
Yes.
> S
On Sunday 03 November 2013, Sune Vuorela wrote:
> On 2013-11-03, Alexander Neundorf 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
Alexander Neundorf wrote:
> On Sunday 03 November 2013, Sune Vuorela wrote:
>> On 2013-11-03, Alexander Neundorf 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 ho
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 only
cmake." but this requires karchive to be installed
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 ne
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.
> >
> > Y
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 + tier
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:
> > >
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
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 a
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 cmak
On 2013-11-11, Aaron J. Seigo 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 is, just like
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 communi
On Tuesday 12 November 2013 20:04:38 Sune Vuorela wrote:
> On 2013-11-11, Aaron J. Seigo 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 perspecti
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 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
70 matches
Mail list logo
