Hi Ralf,
I saw a recent commit from you to FindKDE4Internal.cmake:
http://quickgit.kde.org/index.php?p=kdelibs.git&a=commitdiff&h=ca501aa9f4c1e7adcd42accbd53538502ba50ce3&hp=3186e7a5f3acfaa5b5ac1b5cce9315eb53f54655
with the commit message "on win32 we need access to the installed cmake
modules d
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.git&a=commitdiff&h=ca501aa9f4c1e7adcd42accbd53538502ba50ce3&hp=3186e7a5f3acfaa5b5ac1b5cce9315eb53f54655
with the commit message "on win
On Friday 17 February 2012, Ralf Habacker wrote:
> 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.git&a=commitdiff&h=ca501aa9f4
> > c1e7adcd42accbd53538502ba50ce3&hp=3186e
On Fri, Feb 17, 2012 at 5:33 PM, Alexander Neundorf wrote:
> A library must never install the Find-module for itself.
>
> This defeats the purpose. This is like putting the remote control right next
> to the TV, or the treasure map right into the treasure chest. You don't know
> where the plan is
Am 17.02.2012 17:33, schrieb Alexander Neundorf:
On Friday 17 February 2012, Ralf Habacker wrote:
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.git&a=commitdiff&h=ca501aa9f4
c1e7ad
On Friday 17 of February 2012 17:48:37 Pau Garcia i Quiles wrote:
> On Fri, Feb 17, 2012 at 5:33 PM, Alexander Neundorf
wrote:
> > A library must never install the Find-module for itself.
> >
> > This defeats the purpose. This is like putting the remote control right
> > next to the TV, or the t
2012/2/18 Maciej Mrozowski :
> FindXXX.cmake should not be installed to target system because it suggests
> this file will be somewhat magically available for the client (application
> using FindXXX.cmake).
> But it will not and it's it's client's sole responsibility to provide this
> file.
> libf
On Sunday 19 February 2012, Pau Garcia i Quiles wrote:
> 2012/2/18 Maciej Mrozowski :
> > FindXXX.cmake should not be installed to target system because it
> > suggests this file will be somewhat magically available for the client
> > (application using FindXXX.cmake).
> > But it will not and it's
>> On Linux/BSD/etc, most people never download or use the source tarball
>> for libfoo. When they are developing, they would download libfoo-dev.
>> Where are they going to take FindLibFoo.cmake from if they never used
>> libfoo.tar.gz in the first place?
>
> In the future from extra-cmake-modules
Pau Garcia i Quiles wrote:
>>> On Linux/BSD/etc, most people never download or use the source tarball
>>> for libfoo. When they are developing, they would download libfoo-dev.
>>> Where are they going to take FindLibFoo.cmake from if they never used
>>> libfoo.tar.gz in the first place?
>>
>> In t
On Sunday 19 February 2012, Pau Garcia i Quiles wrote:
> >> On Linux/BSD/etc, most people never download or use the source tarball
> >> for libfoo. When they are developing, they would download libfoo-dev.
> >> Where are they going to take FindLibFoo.cmake from if they never used
> >> libfoo.tar.gz
On Sun, Feb 19, 2012 at 4:24 PM, Alexander Neundorf wrote:
>> - A reference FindLibFoo.cmake is useful for developers who want to
>> make sure libfoo will be located on *any* platform, be it Linux,
>> Windows, Mac or something else. FooConfig.cmake is probably of little
>> use on Windows,
>
> Why
On Sunday 19 February 2012, Pau Garcia i Quiles wrote:
> On Sun, Feb 19, 2012 at 4:24 PM, Alexander Neundorf
wrote:
> >> - A reference FindLibFoo.cmake is useful for developers who want to
> >> make sure libfoo will be located on *any* platform, be it Linux,
> >> Windows, Mac or something else. F
On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf wrote:
> CMake searches in a set of self-defined standard locations, as documented in
> the find_package() section of the man page.
> I don't have experience with this myself on Windows, but doesn't this make it
> kind of work ?
No, it does not
Pau Garcia i Quiles wrote:
> On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf
> wrote:
> Now try and find a LibFooConfig.cmake somehow. Absolutely impossible.
> Heck, many times headers and libraries will be under some shared
> network drive! (something like H:\lib + H:\include). Are you going
Am 19.02.2012 22:45, schrieb Pau Garcia i Quiles:
On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf wrote:
CMake searches in a set of self-defined standard locations, as documented in
the find_package() section of the man page.
I don't have experience with this myself on Windows, but doesn't
Am 19.02.2012 23:12, schrieb Stephen Kelly:
Pau Garcia i Quiles wrote:
On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf
wrote:
Now try and find a LibFooConfig.cmake somehow. Absolutely impossible.
Heck, many times headers and libraries will be under some shared
network drive! (something like
On Sun, Feb 19, 2012 at 11:41 PM, Ralf Habacker
wrote:
> There is a linux rpm package installing about 150 Find... scripts into
> /usr/share/cmake-2.8/modules (the package is named cmake) and a 3rdparty
> library rpm package installing a dedicated Find... script into the same
> location (or a we
On Sun, Feb 19, 2012 at 11:12 PM, Stephen Kelly wrote:
> Pau Garcia i Quiles wrote:
>
>> On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf
>> wrote:
>> Now try and find a LibFooConfig.cmake somehow. Absolutely impossible.
>> Heck, many times headers and libraries will be under some shared
>> ne
On 2/19/2012 5:53 PM, Pau Garcia i Quiles wrote:
On Sun, Feb 19, 2012 at 11:12 PM, Stephen Kelly wrote:
How would FindFoo.cmake know where to look?
Exactly like it does know now: trial and error looking for the most
common places. If it does not find the headers, libraries, etc, then
it will
On Sunday 19 February 2012, Pau Garcia i Quiles wrote:
> On Sun, Feb 19, 2012 at 11:41 PM, Ralf Habacker
>
> wrote:
> > There is a linux rpm package installing about 150 Find... scripts into
> > /usr/share/cmake-2.8/modules (the package is named cmake) and a 3rdparty
> > library rpm package inst
On Sunday 19 February 2012, Ralf Habacker wrote:
> Am 19.02.2012 22:45, schrieb Pau Garcia i Quiles:
...
> > The search order would be like this:
> >
> > 1. LibFooConfig.cmake
> > 2. FindLibFoo.cmake in CMAKE_MODULE_PATH
> > 3. FindLibFoo.cmake in /usr/share/cmake/official3rdpartymodules
> > 4. Fi
On 20.02.12 18:28:43, Alexander Neundorf wrote:
> On Sunday 19 February 2012, Ralf Habacker wrote:
> > Am 19.02.2012 22:45, schrieb Pau Garcia i Quiles:
> ...
> > > The search order would be like this:
> > >
> > > 1. LibFooConfig.cmake
> > > 2. FindLibFoo.cmake in CMAKE_MODULE_PATH
> > > 3. FindLi
On Monday 20 February 2012, Andreas Pakulat wrote:
> Debian also installs into /usr/share/cmake-/Modules/. There is
> a /usr/share/cmake too, but thats from SDO and only from that one. But
SDO ?
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.
Hello,
On pirmadienis 20 Vasaris 2012 20:56:04 Andreas Pakulat wrote:
> > Really ?
> > My original 2.8.3 binary package as provided by Kitware installs into
> > /usr/share/cmake-2.8/modules
>
> Debian also installs into /usr/share/cmake-/Modules/. There is
> a /usr/share/cmake too, but thats from
On 20.02.12 20:35:58, Alexander Neundorf wrote:
> On Monday 20 February 2012, Andreas Pakulat wrote:
> > Debian also installs into /usr/share/cmake-/Modules/. There is
> > a /usr/share/cmake too, but thats from SDO and only from that one. But
>
> SDO ?
Shared Desktop Ontologies, that project inst
Alexander Neundorf writes:
> On Monday 20 February 2012, Andreas Pakulat wrote:
>> Debian also installs into /usr/share/cmake-/Modules/. There is
>> a /usr/share/cmake too, but thats from SDO and only from that one. But
>
> SDO ?
shared-desktop-ontologies
On Monday 20 February 2012, Andreas Pakulat wrote:
> On 20.02.12 20:35:58, Alexander Neundorf wrote:
> > On Monday 20 February 2012, Andreas Pakulat wrote:
> > > Debian also installs into /usr/share/cmake-/Modules/. There is
> > > a /usr/share/cmake too, but thats from SDO and only from that one. B
Hello,
On pirmadienis 20 Vasaris 2012 22:50:46 Alexander Neundorf wrote:
> > that project installs its find-module into
> > /usr/share/cmake/modules - at least the debian package does.
>
> This is wrong.
Emm no, Debian package installs to /usr/share/cmake/SharedDesktopOntologies/
(*Config.cmake
On Monday 20 February 2012, you wrote:
> Hello,
>
> On pirmadienis 20 Vasaris 2012 22:50:46 Alexander Neundorf wrote:
> > > that project installs its find-module into
> > > /usr/share/cmake/modules - at least the debian package does.
> >
> > This is wrong.
>
> Emm no, Debian package installs to
On 20.02.12 22:07:27, Alexander Neundorf wrote:
> On Monday 20 February 2012, you wrote:
> > Hello,
> >
> > On pirmadienis 20 Vasaris 2012 22:50:46 Alexander Neundorf wrote:
> > > > that project installs its find-module into
> > > > /usr/share/cmake/modules - at least the debian package does.
> >
Am Freitag, 17. Februar 2012, 17:33:34 schrieb Alexander Neundorf:
> A library must never install the Find-module for itself.
>
> This defeats the purpose. This is like putting the remote control right next
> to the TV, or the treasure map right into the treasure chest. You don't
> know where the
On Friday 17 February 2012, Friedrich W. H. Kossebau wrote:
> Am Freitag, 17. Februar 2012, 17:33:34 schrieb Alexander Neundorf:
> > A library must never install the Find-module for itself.
> >
> > This defeats the purpose. This is like putting the remote control right
> > next to the TV, or the t
Am Freitag, 17. Februar 2012, 19:34:38 schrieb Alexander Neundorf:
> On Friday 17 February 2012, Friedrich W. H. Kossebau wrote:
> > Am Freitag, 17. Februar 2012, 17:33:34 schrieb Alexander Neundorf:
> > > A library must never install the Find-module for itself.
> > >
> > > This defeats the purpos
On Friday 17 February 2012, Friedrich W. H. Kossebau wrote:
> Am Freitag, 17. Februar 2012, 19:34:38 schrieb Alexander Neundorf:
> > On Friday 17 February 2012, Friedrich W. H. Kossebau wrote:
> > > Am Freitag, 17. Februar 2012, 17:33:34 schrieb Alexander Neundorf:
> > > > A library must never inst
Friedrich W. H. Kossebau wrote:
> So any dev wanting to make use of that lib cannot rely on
> extra-cmake-modules and has to do things himself. Which somehow renders
> extra-cmake-modules a little bit useless for me (as usually as dev you
> want the latest-and-coolest version of some lib).
What
Alexander Neundorf wrote:
> There will be the first release this spring or early summer, at the latest
> at the same time of the first KDE frameworks alpha/beta/preview/whatever
> release.
I don't see whay we should make a stable release before releasing kf5. I
even think it would be a bad idea
37 matches
Mail list logo
