Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Friday 20 June 2008, Matthias Kretz wrote:
On Monday 16 June 2008 17:13:41 Matthias Kretz wrote:
Hmm, perhaps the target could be made explicit:
add_automoc4_target(phonon_automoc phonon_SRCS)
add_library(phonon ${phonon_SRCS})
add_dependencies(phonon phonon_automoc)
kde4_add_library/executable/plugin would hide all that.
Please test the attached patch (esp. on Windows) and let me know what you
think about this new automoc macro.
This patch adds the additional automoc target for every target.
KDE developers will complain that it got slower.
Can we have two versions of the macro, one with the extra target and one
without ?
The one with the extra target could be the one recommended for general use
outside of KDE. Inside KDE (i.e. KDE4Macros.cmake) the one without the extra
target could be used, except in the case where this doesn't work (nmake ?).
It should be possible to hide this in the KDE4_ADD_SOMETHING() macros.
What do you think ? Too much trouble for the speed gain ?
Another issue:
I think we should make kdesupport automoc mandatory ASAP. I won't be online a
lot next week. So if you feel like it is ready, can you please do that next
monday and remoev the old automoc from kdelibs at the same time ?
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Thursday 05 June 2008, Alexander Neundorf wrote:
On Thursday 29 May 2008, Matthias Kretz wrote:
On Thursday 29 May 2008, Alexander Neundorf wrote:
On Wednesday 28 May 2008, Matthias Kretz wrote:
I tried add_custom_target and it won't work in the automoc macros
because there needs to be a dependency from the main target to the
automoc target. And that cannot be added from the automoc macro
because the main target is not defined at this point.
add_custom_command(TARGET has the same problem.
It would be possible to use add_custom_target and require the user to
add the dependency between the two targets himself. In the KDE4_
macros we could do that...
Yes, there it wouldn't be a problem.
Except that it is a bit slower, right ?
It's hard to profile. But it certainly has to read and write a lot more files
if you double the number of targets in a project. It should be noticable on
big modules like kdelibs and kdebase. Small modules won't notice it, I think.
Do you think this would be acceptable for other projects ?
It being slower or the need to add a dependency rule for a target that fell
from the sky?
Hmm, perhaps the target could be made explicit:
add_automoc4_target(phonon_automoc phonon_SRCS)
add_library(phonon ${phonon_SRCS})
add_dependencies(phonon phonon_automoc)
kde4_add_library/executable/plugin would hide all that.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Thursday 29 May 2008, Matthias Kretz wrote: On Thursday 29 May 2008, Alexander Neundorf wrote: On Wednesday 28 May 2008, Matthias Kretz wrote: On Tuesday 27 May 2008, Christian Ehrlicher wrote: Alexander Neundorf schrieb: On Saturday 10 May 2008, Alexander Neundorf wrote: Hi, we moved automoc (the tool which does the automoc'ing) to kdesupport, so it can be used also by non-KDE apps (and maybe be integrated into cmake). I think we can make automoc from kdesupport required next week, and delete the one from kdelibs. Or is there anything speaking against this ? Yes, my problem with nmake :) Any news on this? I tried add_custom_target and it won't work in the automoc macros because there needs to be a dependency from the main target to the automoc target. And that cannot be added from the automoc macro because the main target is not defined at this point. add_custom_command(TARGET has the same problem. It would be possible to use add_custom_target and require the user to add the dependency between the two targets himself. In the KDE4_ macros we could do that... Yes, there it wouldn't be a problem. Except that it is a bit slower, right ? Do you think this would be acceptable for other projects ? I mean it's a bit ugly, a target is created automatically without the developer knowing it, and then the developer has to do something with the target. (we have something similar for kdeinit, and this is already not nice). Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On 04.06.08 13:35:30, David Faure wrote:
On Tuesday 03 June 2008, Brad King wrote:
David Faure wrote:
Currently the
only way to override what the NO_DEFAULT_PATH stuff finds is to set the
result variable in the cache by hand for each and every library. If you
(as a project dev) want to look in a set of default locations on the
users' behalf, they should be added to the search path variables by the
project. Then none of the find_* commands needs special arguments, only
one call to each is needed, and users can override things easily.
But that means modifying global variables, i.e. affecting all other calls to
find_library?
This doesn't sound right. When looking for libbz2 we surely don't want to
look into
${KDE4_LIB_INSTALL_DIR} ${KDE4_LIB_DIR} ${QT_LIBRARY_DIR} ...
Well, you can first add them and then remove them again.
If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
tell you where to find the library, why do you need to search for it in
default paths at all?
Because those are just hints. Maybe phonon is in the kde install dir, but
maybe it has
been installed into its own prefix instead. In the first case it should
be autodetected,
while in the latter case it's normal that the user has to specify a
prefix -- but that doesn't
work because of NO_DEFAULT_PATH (which is only there so that the
autodetection
prefers KDE4_LIB_INSTALL_DIR over /usr/lib, not to prevent users from
setting the right
path manually!).
Okay, so follow the above advice:
find_package(FOO REQUIRED)
# Foo tells me where I might find other stuff.
list(APPEND CMAKE_PREFIX_PATH ${FOO_INSTALL_PREFIX})
find_library(BAR_LIBRARY NAMES bar)
# tada! BAR_LIBRARY is found under foo-prefix/lib
Yes. However this means not using NO_DEFAULT_PATH, so this brings up this
orthogonal issue:
Imagine I have a /usr/lib/libphonon.so from kubuntu (so it's old, and was
compiled in release mode),
and I compile my own libphonon.so into my own prefix (say
/opt/phonon/lib/libphonon.so or whatever).
IIRC a call to find_library() would prefer the one in /usr/lib/libphonon.so
even when doing
find_library(PHONON_LIBRARY NAMES phonon PATHS /opt/phonon/lib)
because the system paths are checked first (right? I hope I don't remember
wrongly).
Right, but with that call you could set CMAKE_PREFIX_PATH and have your
phonon in /opt found.
Right Alex? This is the reason for the NO_DEFAULT_PATH in FindPhonon? Or is
the reason
rather that you wanted CMAKE_SYSTEM_LIBRARY_PATH to have more priority than
qt's [old] phonon?
(but that's a tough choice, they could both be too old :)
Removing NO_DEFAULT_PATH fixes my problem (phonon is found when setting
CMAKE_PREFIX_PATH correctly)
OK about this patch, Alex?
No, thats wrong, it breaks when one has phonon in /usr/lib and also in
install dir, but the latter one should be used. You should add a second
call to find_library without NO_DEFAULT_PATH after the first one. That
uses phonon from KDE paths+CMAKE_SYSTEM_LIBRARY_PATH+install dir if
available and else uses the one that it finds in the default paths,
including CMAKE_PREFIX_PATH and CMAKE_LIBRARY_PATH variables.
Andreas
--
You're growing out of some of your problems, but there are others that
you're growing into.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Wednesday 04 June 2008, Andreas Pakulat wrote:
But that means modifying global variables, i.e. affecting all other calls
to find_library?
This doesn't sound right. When looking for libbz2 we surely don't want to
look into
${KDE4_LIB_INSTALL_DIR} ${KDE4_LIB_DIR} ${QT_LIBRARY_DIR} ...
Well, you can first add them and then remove them again.
Before and after *every* single call to find_library? Hello? This isn't
autoconf anymore, we are looking
for _convenient_ solutions here :)
Yes. However this means not using NO_DEFAULT_PATH, so this brings up this
orthogonal issue:
Imagine I have a /usr/lib/libphonon.so from kubuntu (so it's old, and was
compiled in release mode),
and I compile my own libphonon.so into my own prefix (say
/opt/phonon/lib/libphonon.so or whatever).
IIRC a call to find_library() would prefer the one in /usr/lib/libphonon.so
even when doing
find_library(PHONON_LIBRARY NAMES phonon PATHS /opt/phonon/lib)
because the system paths are checked first (right? I hope I don't remember
wrongly).
Right, but with that call you could set CMAKE_PREFIX_PATH and have your
phonon in /opt found.
But the code already mentions /opt/phonon/lib, so it should find it there
automatically.
For this we -do- want autoconf-like behavior: autodetection whenever possible,
otherwise
every user would have to set a huge number of variables when configuring any
kde module.
Personally I am testing things with everything in its own prefix, but most
people don't do that,
they use the same prefix for everything (say /usr/local, or some kde-related
prefix), and any
lib in that prefix should be found automatically, without even the need to set
CMAKE_PREFIX_PATH,
as long as we can, in the cmake modules code, figure out that likely default
path
(which we do. but it should have priority over /usr/lib!).
Right Alex? This is the reason for the NO_DEFAULT_PATH in FindPhonon? Or is
the reason
rather that you wanted CMAKE_SYSTEM_LIBRARY_PATH to have more priority than
qt's [old] phonon?
(but that's a tough choice, they could both be too old :)
Removing NO_DEFAULT_PATH fixes my problem (phonon is found when setting
CMAKE_PREFIX_PATH correctly)
OK about this patch, Alex?
No, thats wrong, it breaks when one has phonon in /usr/lib and also in
install dir, but the latter one should be used.
This is exactly what's wrong about find_library IMHO.
We need a way to get the following priority order:
* user-specified prefix (CMAKE_PREFIX_PATH)
* likely default locations (kde lib install dir etc.)
* system fallback defaults (/usr)
You should add a second
call to find_library without NO_DEFAULT_PATH after the first one.
That's ugly and we don't want to do that - as Brad said.
That
uses phonon from KDE paths+CMAKE_SYSTEM_LIBRARY_PATH+install dir if
available and else uses the one that it finds in the default paths,
including CMAKE_PREFIX_PATH and CMAKE_LIBRARY_PATH variables.
Those last two are user-specified, surely they should have priority?
Otherwise there's no way to override the builtin-default-locations like kde
install dir
or /usr/lib (that's what CMAKE_SYSTEM_LIBRARY_PATH is, isn't it?).
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On 04.06.08 14:25:09, David Faure wrote: On Wednesday 04 June 2008, Andreas Pakulat wrote: Right Alex? This is the reason for the NO_DEFAULT_PATH in FindPhonon? Or is the reason rather that you wanted CMAKE_SYSTEM_LIBRARY_PATH to have more priority than qt's [old] phonon? (but that's a tough choice, they could both be too old :) Removing NO_DEFAULT_PATH fixes my problem (phonon is found when setting CMAKE_PREFIX_PATH correctly) OK about this patch, Alex? No, thats wrong, it breaks when one has phonon in /usr/lib and also in install dir, but the latter one should be used. This is exactly what's wrong about find_library IMHO. We need a way to get the following priority order: * user-specified prefix (CMAKE_PREFIX_PATH) * likely default locations (kde lib install dir etc.) * system fallback defaults (/usr) You should add a second call to find_library without NO_DEFAULT_PATH after the first one. That's ugly and we don't want to do that - as Brad said. Then you need to file a bugreport for CMake and wait with the change until KDE can require the CMake version that implements it. Sometimes you'll have to either write your own or use a workaround for a limitation in a given system. That uses phonon from KDE paths+CMAKE_SYSTEM_LIBRARY_PATH+install dir if available and else uses the one that it finds in the default paths, including CMAKE_PREFIX_PATH and CMAKE_LIBRARY_PATH variables. Those last two are user-specified, surely they should have priority? You can read about the order of things in man cmake (under find_library section), but yes those have priority over everything else, i.e. they are found first. Andreas -- Tomorrow, you can be anywhere. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Wednesday 04 June 2008, you wrote:
...
Imagine I have a /usr/lib/libphonon.so from kubuntu (so it's old, and was
compiled in release mode), and I compile my own libphonon.so into my own
prefix (say /opt/phonon/lib/libphonon.so or whatever). IIRC a call to
find_library() would prefer the one in /usr/lib/libphonon.so even when
doing find_library(PHONON_LIBRARY NAMES phonon PATHS /opt/phonon/lib)
because the system paths are checked first (right? I hope I don't remember
wrongly). This is the reason why we're using NO_DEFAULT_PATH everywhere --
but I agree, it's a workaround. Ideally we shouldn't have to use it. And
then setting CMAKE_PREFIX_PATH or cmake-2.4 similar vars would work.
Right Alex? This is the reason for the NO_DEFAULT_PATH in FindPhonon? Or is
the reason rather that you wanted CMAKE_SYSTEM_LIBRARY_PATH to have more
priority than qt's [old] phonon? (but that's a tough choice, they could
Hmm, today was the first time I had a look at that file.
Maybe Matthias copied this from FindAutomoc4.cmake, but there we have a very
special case (finding a non-library file in a library directory).
Usually I would do something like:
find_library(PHONON_LIBRARY NAMES phonon
PATHS ${KDE4_LIB_INSTALL_DIR}
NO_DEFAULT_PATH)
find_library(PHONON_LIBRARY NAMES phonon)
This would prefer libphonon.so in the kdelibs install dir. The next try would
be the location listed in CMAKE_PREFIX_PATH or CMAKE_LIBRARY_PATH, followed
by all the default dirs.
Would that work for you ?
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Wednesday 04 June 2008, Brad King wrote: David Faure wrote: On Wednesday 04 June 2008, Brad King wrote: 1.) CMAKE_PREFIX_PATH from environment 2.) CMAKE_PREFIX_PATH from cmake variable Interesting; shouldn't the cmake variable (e.g. specified on the command line) be preferred over the environment variable (which could be set in .bashrc, i.e. it's less specific and less explicit than cmake -DCMAKE_PREFIX_PATH=?). It's a tough call. The user could also do CMAKE_PREFIX_PATH=... cmake ../src for a one-shot tweak, or the project author could write set(CMAKE_PREFIX_PATH ...) Hehe, indeed. But both are very uncommon (everyone uses -D syntax when calling cmake, and a project author wouldn't know what to set CMAKE_PREFIX_PATH to IMHO, or only as a result of a previous autodetection, which itself would have to follow the rules of reading the user's settings first :) ) which is even less specific. However, I think the common use cases would be the env var in a .bashrc and the cmake var in the cache or on the command line. Additionally, a build script could set the cache variable to make it work independently of the user's environment if it were preferred. This argues in favor of switching the order. So, the overall preferred order for specificity is 1.) current build tree (CMAKE_PREFIX_PATH var) 2.) user environment (CMAKE_PREFIX_PATH env) 3.) current project source (PATHS option) 4.) system environment (PATH env) 5.) platform conventions (CMAKE_SYSTEM_PREFIX_PATH) Does this make sense? Indeed it does. Making this order work would require projects to avoid setting the CMAKE_PREFIX_PATH variable and instead use the PATHS option. This seems to be what everyone expects anyway. Yes, it makes the syntax much nicer, compared to storing, setting, and restoring CMAKE_PREFIX_PATH. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Wednesday 04 June 2008, David Faure wrote:
On Wednesday 04 June 2008, Andreas Pakulat wrote:
But that means modifying global variables, i.e. affecting all other
calls to find_library? This doesn't sound right. When looking for
libbz2 we surely don't want to look into ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${QT_LIBRARY_DIR} ...
Well, you can first add them and then remove them again.
Before and after *every* single call to find_library? Hello? This isn't
autoconf anymore, we are looking for _convenient_ solutions here :)
Sadly that was the exact same thought I had.
Huh. I remember doing stupid shit like that for JuK's configure.in.in
Regards,
- Michael Pyne
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On 04.06.08 18:06:00, Michael Pyne wrote:
On Wednesday 04 June 2008, David Faure wrote:
On Wednesday 04 June 2008, Andreas Pakulat wrote:
But that means modifying global variables, i.e. affecting all other
calls to find_library? This doesn't sound right. When looking for
libbz2 we surely don't want to look into ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${QT_LIBRARY_DIR} ...
Well, you can first add them and then remove them again.
Before and after *every* single call to find_library? Hello? This isn't
autoconf anymore, we are looking for _convenient_ solutions here :)
Sadly that was the exact same thought I had.
I guess I just don't have suffered enough from automake (rarely got in
touch with it so far except for the usual make -f Makefile.cvs+configure) :)
Also I never said that its a good idea to do that, I just raised an
option.
Andreas
--
Keep emotionally active. Cater to your favorite neurosis.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, Alexander Neundorf wrote:
BTW, what are ${CMAKE_SYSTEM_PREFIX_PATH} and ${CMAKE_SYSTEM_LIBRARY_PATH}?
cmake --help-variable doesn't know them.
Hmm, maybe they are internal and intentionally undocumented.
Well, if you have to use them when you write a FindFoo.cmake module, then maybe
they should be documented :)
No, I just tried and it also doesn't say anything about CMAKE_PREFIX_PATH and
CMAKE_LIBRARY_PATH.
They are documented in the FIND_LIBRARY() documentation. To make sure this
won't be forgotten it would be nice if you could file a bug report in the
cmake bugtracker for that.
Hmm. My old login failed to work. Grmbl. OK new account created...
Ok, I added the missing paths (CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH and
their
env. var equivalents) to the FIND_FILE() command in kdelibs/cmake/modules/.
If
that works fine we have to do the same in kdesupport/akonadi/ and phonon/.
Yes it works fine after copying FindAutomoc.cmake to phonon, please commit them
too.
So with cmake 2.4 you can now set the CMAKE_LIBRARY_PATH env. var to the lib
install dir of automoc.
Works.
With cmake 2.6 you can (and should) set the CMAKE_PREFIX_PATH env. var to all
your custom install prefixes.
Works too - nicer indeed.
Of course you can also manually set AUTOMOC4_CONFIG_FILE to the file, either
using -DAUTOMOC4_CONFIG_FILE or using cmake-gui.
Yeah, I could also run moc by hand :-P
P.S. the issue here is that I try to find a file which is not a library in a
subdir of the lib dirs, so FIND_LIBRARY() would be a good candidate, but
since it automatically adds prefixes and suffixes (lib and .so) that
doesn't work, so FIND_FILE() has to be used instead, and all paths where
FIND_LIBRARY() would search are added explicitely.
Maybe it would be easier to just use FIND_PROGRAM(automoc4) and then
check ../lib/automoc/ for the Automoc4Config.cmake file ?
Not really, since ../lib can be ../lib64 or ../lib32, and in theory one doesn't
have to
set things up that way at all...
A more standard solution (except on windows) would be a pkgconfig file I
guess...
But I'm fine with the way it is now, thanks for the fix.
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
Alexander Neundorf wrote: On Tuesday 03 June 2008, Brad King wrote: Finding lib/automoc4/Automoc4Config.cmake is the exact purpose of find_package(). The CMake 2.6 version is *much* more powerful than 2.4 and completely solves the problem. Please make sure that Automoc4Config.cmake is installed in a way that will work with find_package so that when CMake 2.6 is required it doesn't have to move. Yes, that works. But it also has to work with cmake 2.4, that's why I'm using that FIND_FILE() call. What I'm saying is that you should write it and get it working with find_package first and then go back and produce an approximation of it with find_file that is used for 2.4. That way the final design in a year when we require 2.6 is the right one and not a compatibility hack like the current foo_LIB_DEPENDS stuff. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, Alexander Neundorf wrote: Hmm. My old login failed to work. Grmbl. OK new account created... Done, http://public.kitware.com/Bug/view.php?id=7146 I guess blogging about this once wasn't enough... ...how could anybody not remember all details from the blog of some KDE developer... Blogging? What's that? I don't have time to read blogs -and- mailinglists and fix kde bugs, sorry :) Hmm, techbase... Yes -- and of course the cmake documentation itself (added CMAKE_PREFIX_PATH to report 7146...) A more standard solution (except on windows) would be a pkgconfig file I guess... If you install automoc to a custom location, you would also have to adjust the PKGCONFIG_PATH (or what the name is) env. var, so it doesn't help for the basic issue. Sure it would need to be set, but it would help because it's more standard, so more commonly known ;) I already do this to PKG_CONFIG_PATH: headCat PKG_CONFIG_PATH $DBUSDIR/lib/pkgconfig headCat PKG_CONFIG_PATH $QTDIR/lib/pkgconfig headCat PKG_CONFIG_PATH /d/other/inst/icecream/lib/pkgconfig headCat PKG_CONFIG_PATH /d/other/inst/lib/pkgconfig # for qca headCat PKG_CONFIG_PATH /d/kde/inst/kdesupport_trunk/lib/pkgconfig :) -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, David Faure wrote:
On Tuesday 03 June 2008, Alexander Neundorf wrote:
BTW, what are ${CMAKE_SYSTEM_PREFIX_PATH} and
${CMAKE_SYSTEM_LIBRARY_PATH}? cmake --help-variable doesn't know them.
Hmm, maybe they are internal and intentionally undocumented.
Well, if you have to use them when you write a FindFoo.cmake module, then
maybe they should be documented :)
No, I just tried and it also doesn't say anything about CMAKE_PREFIX_PATH
and CMAKE_LIBRARY_PATH.
They are documented in the FIND_LIBRARY() documentation. To make sure
this won't be forgotten it would be nice if you could file a bug report
in the cmake bugtracker for that.
Hmm. My old login failed to work. Grmbl. OK new account created...
Ok, I added the missing paths (CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH and
their env. var equivalents) to the FIND_FILE() command in
kdelibs/cmake/modules/. If that works fine we have to do the same in
kdesupport/akonadi/ and phonon/.
Yes it works fine after copying FindAutomoc.cmake to phonon, please commit
them too.
Will do.
So with cmake 2.4 you can now set the CMAKE_LIBRARY_PATH env. var to the
lib install dir of automoc.
Works.
With cmake 2.6 you can (and should) set the CMAKE_PREFIX_PATH env. var to
all your custom install prefixes.
Works too - nicer indeed.
I guess blogging about this once wasn't enough...
...how could anybody not remember all details from the blog of some KDE
developer...
Hmm, techbase...
Of course you can also manually set AUTOMOC4_CONFIG_FILE to the file,
either using -DAUTOMOC4_CONFIG_FILE or using cmake-gui.
Yeah, I could also run moc by hand :-P
P.S. the issue here is that I try to find a file which is not a library
in a subdir of the lib dirs, so FIND_LIBRARY() would be a good candidate,
but since it automatically adds prefixes and suffixes (lib and .so)
that doesn't work, so FIND_FILE() has to be used instead, and all paths
where FIND_LIBRARY() would search are added explicitely.
Maybe it would be easier to just use FIND_PROGRAM(automoc4) and then
check ../lib/automoc/ for the Automoc4Config.cmake file ?
Not really, since ../lib can be ../lib64 or ../lib32, and in theory one
doesn't have to set things up that way at all...
A more standard solution (except on windows) would be a pkgconfig file I
guess...
If you install automoc to a custom location, you would also have to adjust the
PKGCONFIG_PATH (or what the name is) env. var, so it doesn't help for the
basic issue.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, Brad King wrote: David Faure wrote: On Tuesday 03 June 2008, Alexander Neundorf wrote: Hmm. My old login failed to work. Grmbl. OK new account created... Done, http://public.kitware.com/Bug/view.php?id=7146 I guess blogging about this once wasn't enough... ...how could anybody not remember all details from the blog of some KDE developer... Blogging? What's that? I don't have time to read blogs -and- mailinglists and fix kde bugs, sorry :) Hmm, techbase... Yes -- and of course the cmake documentation itself (added CMAKE_PREFIX_PATH to report 7146...) From cmake --help-command find_library: 1. Search cmake specific environment variables. ... prefix/lib for each prefix in CMAKE_PREFIX_PATH ... 2. Search cmake variables with the same names as the cmake specific environment variables. ... prefix/lib for each prefix in CMAKE_PREFIX_PATH ... ...and similarly for the other find_* commands. Yes. This is nice for the cmake-code-writer, but not for the cmake user, who doesn't know find_library is involved in the first place. If someone tells that user just set CMAKE_PREFIX_PATH, he's going to do cmake --help-variable CMAKE_PREFIX_PATH, like I did :) What's cmake --help-variable good for, if it doesn't have all useful variables? Well, == http://public.kitware.com/Bug/view.php?id=7146 :) KDE developers, always complaining, I know :) But at least phonon compiles now so I'm happy :) -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR}
${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon
(correct syntax, right?)
doesn't work, because of the NO_DEFAULT_PATH. The reason why use
NO_DEFAULT_PATH almost everywhere
is simple: without it, libs in /usr/lib are preferred over those in the PATHS
specified to find_library.
Is there a way to get check those paths first, then fallback to the default
paths behavior, without duplicating
all the default paths in the find_library call?
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
David Faure wrote:
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR}
${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon
(correct syntax, right?)
doesn't work, because of the NO_DEFAULT_PATH. The reason why use
NO_DEFAULT_PATH almost everywhere
is simple: without it, libs in /usr/lib are preferred over those in the PATHS
specified to find_library.
The issue here is that we (cmake devs) view the PATHS argument as a list
of last resort paths (e.g. hard-coding c:/Python25), not preferred
paths. There are a whole bunch of user-controlled places that are
searched before /usr/lib.
If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
tell you where to find the library, why do you need to search for it in
default paths at all?
When CMake 2.6 is required everything should switch to using the
export/import feature:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets
along with the full power of find_package and this issue should go away
completely. CMake will then just load a file that tells it exactly
where libraries are located (i.e. full paths to the library files).
Is there a way to get check those paths first, then fallback to the default
paths behavior, without duplicating
all the default paths in the find_library call?
Yes, and it's mentioned in the find_library documentation:
find_library(FOO_LIBRARY NAMES foo
PATHS ${PATH1} ${PATH2} ... NO_DEFAULT_PATH)
find_library(FOO_LIBRARY NAMES foo)
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On 03.06.08 21:02:50, David Faure wrote:
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR}
${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon
(correct syntax, right?)
doesn't work, because of the NO_DEFAULT_PATH. The reason why use
NO_DEFAULT_PATH almost everywhere
is simple: without it, libs in /usr/lib are preferred over those in the PATHS
specified to find_library.
Is there a way to get check those paths first, then fallback to the default
paths behavior, without duplicating
all the default paths in the find_library call?
Yes there is, run find_library twice, first with NO_DEFAULT_PATH, then
without it. That way the directories that you list are preferred and you
can still easily search the standard system dirs if nothing is found in
the preferred dirs. Works because find_library doesn't search if the
variable it is supposed to fill is already filled with something that
doesn't end in -NOTFOUND.
Andreas
--
You will have a long and boring life.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, Brad King wrote:
David Faure wrote:
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR}
${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon
(correct syntax, right?)
doesn't work, because of the NO_DEFAULT_PATH. The reason why use
NO_DEFAULT_PATH almost everywhere
is simple: without it, libs in /usr/lib are preferred over those in the
PATHS specified to find_library.
The issue here is that we (cmake devs) view the PATHS argument as a list
of last resort paths (e.g. hard-coding c:/Python25), not preferred
paths. There are a whole bunch of user-controlled places that are
searched before /usr/lib.
This assumes that users specify all their lib locations as arguments. It's nice
to be able
to do that, but ideally things should just work out of the box, that's the
whole point
of that list of paths -- to try and autodetect where the stuff is installed, to
save the
user some work.
If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
tell you where to find the library, why do you need to search for it in
default paths at all?
Because those are just hints. Maybe phonon is in the kde install dir, but maybe
it has
been installed into its own prefix instead. In the first case it should be
autodetected,
while in the latter case it's normal that the user has to specify a prefix --
but that doesn't
work because of NO_DEFAULT_PATH (which is only there so that the autodetection
prefers KDE4_LIB_INSTALL_DIR over /usr/lib, not to prevent users from setting
the right
path manually!).
When CMake 2.6 is required everything should switch to using the
export/import feature:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets
along with the full power of find_package and this issue should go away
completely. CMake will then just load a file that tells it exactly
where libraries are located (i.e. full paths to the library files).
... as long as it finds that file in the first place, so I'm not sure this
changes anything, in fact.
Autodetection wanted when possible, manual setting of own prefix otherwise...
Is there a way to get check those paths first, then fallback to the
default paths behavior, without duplicating
all the default paths in the find_library call?
Yes, and it's mentioned in the find_library documentation:
find_library(FOO_LIBRARY NAMES foo
PATHS ${PATH1} ${PATH2} ... NO_DEFAULT_PATH)
find_library(FOO_LIBRARY NAMES foo)
Ah, right, I remember seeing this. It looks ugly and redundant, but ok :-)
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, you wrote: Alexander Neundorf wrote: On Tuesday 03 June 2008, Brad King wrote: Finding lib/automoc4/Automoc4Config.cmake is the exact purpose of find_package(). The CMake 2.6 version is *much* more powerful than 2.4 and completely solves the problem. Please make sure that Automoc4Config.cmake is installed in a way that will work with find_package so that when CMake 2.6 is required it doesn't have to move. Yes, that works. But it also has to work with cmake 2.4, that's why I'm using that FIND_FILE() call. What I'm saying is that you should write it and get it working with find_package first Using just plain FIND_PACKAGE(Automoc4) (i.e. without extra FindAutomoc4.cmake) works, I checked that before. Do you mean that or something different ? Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
Alexander Neundorf wrote: On Tuesday 03 June 2008, you wrote: Alexander Neundorf wrote: On Tuesday 03 June 2008, Brad King wrote: Finding lib/automoc4/Automoc4Config.cmake is the exact purpose of find_package(). The CMake 2.6 version is *much* more powerful than 2.4 and completely solves the problem. Please make sure that Automoc4Config.cmake is installed in a way that will work with find_package so that when CMake 2.6 is required it doesn't have to move. Yes, that works. But it also has to work with cmake 2.4, that's why I'm using that FIND_FILE() call. What I'm saying is that you should write it and get it working with find_package first Using just plain FIND_PACKAGE(Automoc4) (i.e. without extra FindAutomoc4.cmake) works, I checked that before. Do you mean that or something different ? That's all I meant. I just wanted to make sure. Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
David Faure wrote:
On Tuesday 03 June 2008, Brad King wrote:
The issue here is that we (cmake devs) view the PATHS argument as a list
of last resort paths (e.g. hard-coding c:/Python25), not preferred
paths. There are a whole bunch of user-controlled places that are
searched before /usr/lib.
This assumes that users specify all their lib locations as arguments. It's
nice to be able
to do that, but ideally things should just work out of the box, that's the
whole point
of that list of paths -- to try and autodetect where the stuff is installed,
to save the
user some work.
The motivation behind our view is that users should be able to set
CMAKE_PREFIX_PATH and have CMake find things there first. Currently the
only way to override what the NO_DEFAULT_PATH stuff finds is to set the
result variable in the cache by hand for each and every library. If you
(as a project dev) want to look in a set of default locations on the
users' behalf, they should be added to the search path variables by the
project. Then none of the find_* commands needs special arguments, only
one call to each is needed, and users can override things easily.
If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
tell you where to find the library, why do you need to search for it in
default paths at all?
Because those are just hints. Maybe phonon is in the kde install dir, but
maybe it has
been installed into its own prefix instead. In the first case it should be
autodetected,
while in the latter case it's normal that the user has to specify a prefix --
but that doesn't
work because of NO_DEFAULT_PATH (which is only there so that the autodetection
prefers KDE4_LIB_INSTALL_DIR over /usr/lib, not to prevent users from setting
the right
path manually!).
Okay, so follow the above advice:
find_package(FOO REQUIRED)
# Foo tells me where I might find other stuff.
list(APPEND CMAKE_PREFIX_PATH ${FOO_INSTALL_PREFIX})
find_library(BAR_LIBRARY NAMES bar)
# tada! BAR_LIBRARY is found under foo-prefix/lib
If the user specifies a custom CMAKE_PREFIX_PATH it will override what
FOO says. In practice the find_library will be in a find script or
something.
When CMake 2.6 is required everything should switch to using the
export/import feature:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets
along with the full power of find_package and this issue should go away
completely. CMake will then just load a file that tells it exactly
where libraries are located (i.e. full paths to the library files).
... as long as it finds that file in the first place, so I'm not sure this
changes anything, in fact.
Autodetection wanted when possible, manual setting of own prefix otherwise...
The idea is that that one file is found by find_package, which is
extremely powerful (more powerful than pkgconfig, in fact). It also
works well on Windows and OS X (with frameworks too).
Is there a way to get check those paths first, then fallback to the
default paths behavior, without duplicating
all the default paths in the find_library call?
Yes, and it's mentioned in the find_library documentation:
find_library(FOO_LIBRARY NAMES foo
PATHS ${PATH1} ${PATH2} ... NO_DEFAULT_PATH)
find_library(FOO_LIBRARY NAMES foo)
Ah, right, I remember seeing this. It looks ugly and redundant, but ok :-)
We don't really want this done so it's okay if it's ugly. See above.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
Brad King wrote: David Faure wrote: On Tuesday 03 June 2008, Brad King wrote: CMake will then just load a file that tells it exactly where libraries are located (i.e. full paths to the library files). ... as long as it finds that file in the first place, so I'm not sure this changes anything, in fact. Autodetection wanted when possible, manual setting of own prefix otherwise... The idea is that that one file is found by find_package, which is extremely powerful (more powerful than pkgconfig, in fact). It also works well on Windows and OS X (with frameworks too). Furthermore, the one file can tell CMake where to find all the libraries, headers, resources, etc. that come with the package. This avoids accidental mismatches of header files and libraries. Switching from one installation of the package to another requires only one cache variable to be changed. Unlike pkgconfig the one file can just be placed inside the package install tree instead of in a special location in the prefix. It can also do versioning (i.e. find version 4.1 of the package). -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
Hi David,
/me is still catching up with emails after LinuxTag...
On Thursday 29 May 2008, you wrote:
On Saturday 10 May 2008, Alexander Neundorf wrote:
Hi,
we moved automoc (the tool which does the automoc'ing) to kdesupport, so
it can be used also by non-KDE apps (and maybe be integrated into cmake).
When kdesupport is installed into its own prefix, how should automoc4 be
found? There's no pkgconfig file,
-DCMAKE_LIBRARY_PATH=/d/kde/inst/kdesupport_trunk/lib doesn't seem to
help
You are right, there was something missing.
FindAutomoc4.cmake says
find_file(AUTOMOC4_CONFIG_FILE NAMES Automoc4Config.cmake
PATH_SUFFIXES automoc4 lib/automoc4 lib64/automoc4
PATHS ${CMAKE_SYSTEM_PREFIX_PATH} ${CMAKE_SYSTEM_LIBRARY_PATH}
${CMAKE_INSTALL_PREFIX}/lib NO_DEFAULT_PATH )
-- how do I specify a path that isn't installprefix/lib for looking up
automoc4?
BTW, what are ${CMAKE_SYSTEM_PREFIX_PATH} and ${CMAKE_SYSTEM_LIBRARY_PATH}?
cmake --help-variable doesn't know them.
Hmm, maybe they are internal and intentionally undocumented.
No, I just tried and it also doesn't say anything about CMAKE_PREFIX_PATH and
CMAKE_LIBRARY_PATH.
They are documented in the FIND_LIBRARY() documentation. To make sure this
won't be forgotten it would be nice if you could file a bug report in the
cmake bugtracker for that.
Ok, I added the missing paths (CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH and their
env. var equivalents) to the FIND_FILE() command in kdelibs/cmake/modules/. If
that works fine we have to do the same in kdesupport/akonadi/ and phonon/.
So with cmake 2.4 you can now set the CMAKE_LIBRARY_PATH env. var to the lib
install dir of automoc.
With cmake 2.6 you can (and should) set the CMAKE_PREFIX_PATH env. var to all
your custom install prefixes.
Of course you can also manually set AUTOMOC4_CONFIG_FILE to the file, either
using -DAUTOMOC4_CONFIG_FILE or using cmake-gui.
Alex
P.S. the issue here is that I try to find a file which is not a library in a
subdir of the lib dirs, so FIND_LIBRARY() would be a good candidate, but
since it automatically adds prefixes and suffixes (lib and .so) that
doesn't work, so FIND_FILE() has to be used instead, and all paths where
FIND_LIBRARY() would search are added explicitely.
Maybe it would be easier to just use FIND_PROGRAM(automoc4) and then
check ../lib/automoc/ for the Automoc4Config.cmake file ?
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Saturday 10 May 2008, Alexander Neundorf wrote:
Hi,
we moved automoc (the tool which does the automoc'ing) to kdesupport, so it
can be used also by non-KDE apps (and maybe be integrated into cmake).
When kdesupport is installed into its own prefix, how should automoc4 be found?
There's no pkgconfig file,
-DCMAKE_LIBRARY_PATH=/d/kde/inst/kdesupport_trunk/lib doesn't seem to help
FindAutomoc4.cmake says
find_file(AUTOMOC4_CONFIG_FILE NAMES Automoc4Config.cmake
PATH_SUFFIXES automoc4 lib/automoc4 lib64/automoc4
PATHS ${CMAKE_SYSTEM_PREFIX_PATH} ${CMAKE_SYSTEM_LIBRARY_PATH}
${CMAKE_INSTALL_PREFIX}/lib
NO_DEFAULT_PATH )
-- how do I specify a path that isn't installprefix/lib for looking up
automoc4?
BTW, what are ${CMAKE_SYSTEM_PREFIX_PATH} and ${CMAKE_SYSTEM_LIBRARY_PATH}?
cmake --help-variable doesn't know them.
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Wednesday 28 May 2008, Matthias Kretz wrote:
On Tuesday 27 May 2008, Christian Ehrlicher wrote:
Alexander Neundorf schrieb:
On Saturday 10 May 2008, Alexander Neundorf wrote:
Hi,
we moved automoc (the tool which does the automoc'ing) to kdesupport,
so it can be used also by non-KDE apps (and maybe be integrated into
cmake).
I think we can make automoc from kdesupport required next week, and
delete the one from kdelibs.
Or is there anything speaking against this ?
Yes, my problem with nmake :)
Any news on this?
I tried add_custom_target and it won't work in the automoc macros because
there needs to be a dependency from the main target to the automoc target.
And that cannot be added from the automoc macro because the main target is
not defined at this point.
add_custom_command(TARGET has the same problem.
It would be possible to use add_custom_target and require the user to add
the dependency between the two targets himself. In the KDE4_ macros we
could do that...
Hmmm... then the target will just depend on this target, right ?
So if we had a macro which would be called after the actual target has been
created, like
add_executable(foo ${fooSrcs})
automoc4_target(foo ${fooSrcs})
would that work ?
In KDE we can hide this in the KDE4_ADD_xxx() macros.
automoc itself hasn't been released yet, so there is no problem.
What do you think ?
Will you be at LinuxTag ?
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Sunday 18 May 2008, Matthias Kretz wrote: automoc4 uses the include directories as specified by include_directory. At least that's what I wrote and expect the code to do. :-) Take a look at the generated target_automoc.cpp.files file. Its second line contains all the include directories as they'll get passed to moc. This line gets generated by the configure_files call in Automoc4.cmake. You mean the line under MOC_INCLUDES? Yes, it contains the path to kdebase/workspace/libs, but this doesn't change the fact that the installed one is taken and not the one from the kdebase source dir. Just lurk a little on #kde-devel and you will see how many run into this problem. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Monday 19 May 2008, Andras Mantia wrote: On Sunday 18 May 2008, Matthias Kretz wrote: automoc4 uses the include directories as specified by include_directory. At least that's what I wrote and expect the code to do. :-) Take a look at the generated target_automoc.cpp.files file. Its second line contains all the include directories as they'll get passed to moc. This line gets generated by the configure_files call in Automoc4.cmake. You mean the line under MOC_INCLUDES? Yes, it contains the path to kdebase/workspace/libs, but this doesn't change the fact that the installed one is taken and not the one from the kdebase source dir. My question was not whether it contains that path but whether the order in that file is correct or not. Because that tells you whether the error is in automoc or somewhere else. (i.e. correct order in that file = error in automoc4; incorrect order in the file = error in cmake scripts) Just lurk a little on #kde-devel and you will see how many run into this problem. That doesn't help to find the cause either. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Monday 19 May 2008, Matthias Kretz wrote:
You mean the line under MOC_INCLUDES? Yes, it contains the path to
kdebase/workspace/libs, but this doesn't change the fact that the
installed one is taken and not the one from the kdebase source dir.
My question was not whether it contains that path but whether the
order in that file is correct or not. Because that tells you whether
the error is in automoc or somewhere else. (i.e. correct order in
that file = error in automoc4; incorrect order in the file = error
in cmake scripts)
See here:
MOC_INCLUDES:
/data/development/sources/kde-trunk/kdebase;/data/development/build/kde-
trunk/kdebase;/opt/kde4/include;/opt/kde4/include/KDE;/opt/qt4
/include/phonon;/opt/qt4/include/QtXmlPatterns;/opt/qt4/include/QtWebKit;/opt/qt4/include/QtHelp;/opt/qt4/include/QtAssistant;/opt/qt4
/include/QtDBus;/opt/qt4/include/QtTest;/opt/qt4/include/QtUiTools;/opt/qt4/include/QtScript;/opt/qt4/include/QtSvg;/opt/qt4/include/Q
tXml;/opt/qt4/include/QtSql;/opt/qt4/include/QtOpenGL;/opt/qt4/include/QtNetwork;/opt/qt4/include/QtDesigner;/opt/qt4/include/Qt3Suppo
rt;/opt/qt4/include/QtGui;/opt/qt4/include/QtCore;/opt/qt4/include/Qt;/opt/qt4/mkspecs/default;/opt/qt4/include;/usr/include;/data/dev
elopment/build/kde-
trunk/kdebase/workspace;/data/development/sources/kde-
trunk/kdebase/workspace/kdm;/data/development/sources/kde-tru
nk/kdebase/workspace/libs;/data/development/sources/kde-
trunk/kdebase/workspace/libs/kworkspace;/usr/include/NetworkManager;/usr/inclu
de/glib-2.0;/usr/lib64/glib-2.0/include;/data/development/sources/kde-
trunk/kdebase/workspace/solid/networkmanager-0.7/dbus
So it has both /opt/kde4/include (my trunk installation) and
/usr/include (the system dir where KDE 4.0 is installed) before
/data/development/sources/kde-trunk/kdebase/workspace/libs
(where the updated .h files are and those should be used).
I even modified my CMakeList.txt to have kdebase/workspace/libs as the
first include dir:
include_directories(
${CMAKE_SOURCE_DIR}/workspace/libs
${NETWORKMANAGER_INCLUDE_DIRS}
${NM-UTIL_INCLUDE_DIRS}
${CMAKE_CURRENT_SOURCE_DIR}/dbus
${CMAKE_CURRENT_BUILD_DIR}
)
Just lurk a little on #kde-devel and you will see how many run into
this problem.
That doesn't help to find the cause either.
I was just pointing that this problem is far from being specific to my
system.
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Sunday 18 May 2008, Matthias Kretz wrote:
automoc4 uses the include directories as specified by include_directory.
Then it has to honour set(CMAKE_INCLUDE_CURRENT_DIR ON) too (as done by
KDE4Defaults.cmake), which
adds ${CMAKE_CURRENT_SOURCE_DIR} and ${CMAKE_CURRENT_BINARY} to the list
automatically everywhere.
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Monday 19 May 2008, Matthias Kretz wrote:
On Monday 19 May 2008, Alexander Neundorf wrote:
On Sunday 18 May 2008, Matthias Kretz wrote:
On Saturday 17 May 2008, Andras Mantia wrote:
On Sunday 11 May 2008 00:58:38 Alexander Neundorf wrote:
If you experience any problems with automoc, please let us know at
kde-buildsystem@kde.org (or here).
Here is a problem: kdebase fails to build if there are some older
include/solid/control/ifaces around.
The error is:
cd
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmana
ge r- 0. 7 /opt/kde4/bin/automoc4
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmana
ge r- 0. 7/solid_networkmanager07_automoc.cpp
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkma
na ge r- 0.7
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmana
ge r- 0. 7 /opt/qt4/bin/moc []
Generating
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmana
ge r- 0. 7/networkinterface.moc from
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkma
na ge r- 0.7/networkinterface.h
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkma
na ge r- 0.7/manager.h:35: Error: Undefined interface
[...]
automoc4: process
for
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmana
ge r- 0. 7/manager.moc failed: Unknown error
pid to wait for: 0
processes in queue: 11
The problem is this line in manager.h:
#include solid/control/ifaces/networkmanager.h
This picks up the installed networkmanager.h instead of the one from
kdebase/workspace/libs/solid/control/ifaces .
I tried to add
${CMAKE_SOURCE_DIR}/workspace/libs
to the include_directories, but seems that this is ignored or
searched after the system path.
So the solution to build kdebase is to remove your installed version
and build again.This also does not work if e.g you have KDE 4.0.x
installed in /usr like it is on openSUSE. So you have to:
- remove the old files (e.g from /opt/kde4/include if KDE trunk was
installed there)
- build AND install kdebase/workspace/libs/solid (so the correct
headers are installed to /opt/kde4)
- build now kdebase/workspace/solid
I find this behavior broken, automoc4 should find the header files
that are in kdebase/workspace/libs/solid/control/ifaces as specified
by the include_directory command.
automoc4 uses the include directories as specified by
include_directory. At least that's what I wrote and expect the code to
do. :-)
Take a look at the generated target_automoc.cpp.files file. Its
second line contains all the include directories as they'll get passed
to moc. This line gets generated by the configure_files call in
Automoc4.cmake.
CMake sorts the include dirs internally, so that in-project include dirs
are always before out-of-project include dirs.
(if CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE is true, done in
kdelibs/cmake/modules/KDE4Defaults.cmake)
Maybe this has to be added for automoc ?
Alex, could you take a look at this please? Automoc4Config.cmake uses
get_directory_property(_moc_incs INCLUDE_DIRECTORIES)
as the ordered include paths to pass to moc. Why does this not work? Or why
does this not work only in kdebase/workspace/solid/ ?
Testcase:
#enable/disable this line and see what happens
set(CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE ON)
include_directories(/opt/qt-copy/include /home/alex/src/tests/incdirtest2)
get_directory_property(incDirs INCLUDE_DIRECTORIES)
message(STATUS inc: ${incDirs})
add_executable(hello main.c)
GET_DIRECTORY_PROPERTY() returns the include dirs as they are, if
CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE is on they are ordered later on, but
that result isn't available.
So, automoc should also get ${CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE} and if
it is true, at first put all include dirs which are subdirs of the build dir,
then all include dirs which are subdirs of the source dir and finally all
other include dirs.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Saturday 17 May 2008, Andras Mantia wrote:
On Sunday 11 May 2008 00:58:38 Alexander Neundorf wrote:
If you experience any problems with automoc, please let us know at
kde-buildsystem@kde.org (or here).
Here is a problem: kdebase fails to build if there are some older
include/solid/control/ifaces around.
The error is:
cd
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7 /opt/kde4/bin/automoc4
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7/solid_networkmanager07_automoc.cpp
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-
0.7
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7 /opt/qt4/bin/moc []
Generating
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7/networkinterface.moc from
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-
0.7/networkinterface.h
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-
0.7/manager.h:35: Error: Undefined interface
[...]
automoc4: process
for
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7/manager.moc failed: Unknown error
pid to wait for: 0
processes in queue: 11
The problem is this line in manager.h:
#include solid/control/ifaces/networkmanager.h
This picks up the installed networkmanager.h instead of the one from
kdebase/workspace/libs/solid/control/ifaces .
I tried to add
${CMAKE_SOURCE_DIR}/workspace/libs
to the include_directories, but seems that this is ignored or searched
after the system path.
So the solution to build kdebase is to remove your installed version and
build again.This also does not work if e.g you have KDE 4.0.x installed in
/usr like it is on openSUSE. So you have to:
- remove the old files (e.g from /opt/kde4/include if KDE trunk was
installed there)
- build AND install kdebase/workspace/libs/solid (so the correct headers
are installed to /opt/kde4)
- build now kdebase/workspace/solid
I find this behavior broken, automoc4 should find the header files that are
in kdebase/workspace/libs/solid/control/ifaces as specified by the
include_directory command.
automoc4 uses the include directories as specified by include_directory. At
least that's what I wrote and expect the code to do. :-)
Take a look at the generated target_automoc.cpp.files file. Its second line
contains all the include directories as they'll get passed to moc. This line
gets generated by the configure_files call in Automoc4.cmake.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Sunday 11 May 2008 00:58:38 Alexander Neundorf wrote:
If you experience any problems with automoc, please let us know at
kde-buildsystem@kde.org (or here).
Here is a problem: kdebase fails to build if there are some older
include/solid/control/ifaces around.
The error is:
cd /data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.7
/opt/kde4/bin/automoc4
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.7/solid_networkmanager07_automoc.cpp
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-0.7
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.7
/opt/qt4/bin/moc
[]
Generating
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.7/networkinterface.moc
from
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-0.7/networkinterface.h
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-0.7/manager.h:35:
Error: Undefined interface
[...]
automoc4: process
for
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.7/manager.moc
failed: Unknown error
pid to wait for: 0
processes in queue: 11
The problem is this line in manager.h:
#include solid/control/ifaces/networkmanager.h
This picks up the installed networkmanager.h instead of the one from
kdebase/workspace/libs/solid/control/ifaces .
I tried to add
${CMAKE_SOURCE_DIR}/workspace/libs
to the include_directories, but seems that this is ignored or searched after
the system path.
So the solution to build kdebase is to remove your installed version and build
again.This also does not work if e.g you have KDE 4.0.x installed in /usr
like it is on openSUSE. So you have to:
- remove the old files (e.g from /opt/kde4/include if KDE trunk was installed
there)
- build AND install kdebase/workspace/libs/solid (so the correct headers are
installed to /opt/kde4)
- build now kdebase/workspace/solid
I find this behavior broken, automoc4 should find the header files that are in
kdebase/workspace/libs/solid/control/ifaces as specified by the
include_directory command.
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
