On Tuesday 20 July 2010, Michael Jansen wrote:
Hi
I just noticed this line in automoc
if(NOT _generated AND NOT _skip)
Which means .h and .cpp files are ignored if they are generated and not
automocced (?). Which i can't eyplain myself why and which bites me a bit.
I try to
Hi
I just noticed this line in automoc
if(NOT _generated AND NOT _skip)
Which means .h and .cpp files are ignored if they are generated and not
automocced (?). Which i can't
eyplain myself why and which bites me a bit. I try to automoc generated sources.
If i give some
On 1 Mar 2010, at 22:03, Alexander Neundorf wrote:
is -F included in INCLUDE_DIRECTORIES ?
Nope but you can work it out from MOC_DIRECTORIES.
If not, if on Mac, we need to check whether -F is in the link libraries. Hmm,
but the target does not yet exist at this point. Hmm. Maybe automoc4
not yet exist at this point. Hmm. Maybe automoc4
could check the location of the QtCore library and use this to determine
whether and where Qt is installed as frameworks ?
I've attached a patch for this. It should add all the needed frameworks.
Seems to work for me. Can you review it and if it's
On 15 Mar 2010, at 21:32, Alexander Neundorf wrote:
Hmm, I cannot really test it here, but it looks like it makes sense.
So no objections from my side.
Great, I'll commit then.
Where ?
Do you mean in trunk or in a branch or in git ?
Whereever you prefer :-)
CMake just switched to git.
On Monday 15 March 2010, Mike Arthur wrote:
On 15 Mar 2010, at 21:32, Alexander Neundorf wrote:
...
If you do it in trunk, you can be sure people will scream as soon as you
break something ;-)
The KDE developers can be my unit tests ;)
Well, actually, due to the big number of developers we
On 26 Feb 2010, at 21:16, Alexander Neundorf wrote:
Here I have include/QtGui/QGraphicsObject, so this looks correct.
Where is this header on your system ? Is Qt installed as frameworks ?
It's lib/QtGui.framework/Versions/4/Headers/QGraphicsObject for me. Yes I'm
using frameworks on OSX 10.6
On Mon, Mar 1, 2010 at 12:32 PM, Mike Arthur m...@mikearthur.co.uk wrote:
On 26 Feb 2010, at 21:16, Alexander Neundorf wrote:
Here I have include/QtGui/QGraphicsObject, so this looks correct.
Where is this header on your system ? Is Qt installed as frameworks ?
It's
On 1 Mar 2010, at 17:34, Benjamin Reed wrote:
As long as your -F's are right, then
lib/QtGui.framework/Versions/4/Headers/QGraphicsObject should work
with:
#include QtGui/QGraphicsObject
Yeh, it does work fine at compile time, it's automoc4 that's not finding it
properly.
--
Cheers
On Monday 01 March 2010, Mike Arthur wrote:
On 1 Mar 2010, at 17:34, Benjamin Reed wrote:
As long as your -F's are right, then
lib/QtGui.framework/Versions/4/Headers/QGraphicsObject should work
with:
#include QtGui/QGraphicsObject
Yeh, it does work fine at compile time, it's automoc4
On 1 Mar 2010, at 21:31, Alexander Neundorf wrote:
Does automoc4 get the -F passed ?
If so, then somebody needs to add support for -F to automoc...
I would bet money that it doesn't get it passed.
Also, re: automoc qt -stdc port, where should this be done?
--
Cheers,
Mike Arthur
http
On Monday 01 March 2010, Mike Arthur wrote:
On 1 Mar 2010, at 21:31, Alexander Neundorf wrote:
Does automoc4 get the -F passed ?
If so, then somebody needs to add support for -F to automoc...
I would bet money that it doesn't get it passed.
From kdesupport/automoc/Automoc4Config.cmake
On Wednesday 24 February 2010, Mike Arthur wrote:
Got more problems with Automoc4 on OSX unfortunately.
I had to commit revision 1095725 to fix a bug. Without it I get this:
[ 93%] Built target kcmremotewidgetshelper
Generating applethandle_p.moc
/Users/mike/Documents/KDE/KDELibs/plasma
On 25 Feb 2010, at 02:46, Pavel Heimlich, a.k.a. hajma wrote:
he meant
to:
#include QGraphicsObject
http://websvn.kde.org/branches/KDE/4.4/kdelibs/plasma/private/applethandle_p.h?r1=1095725r2=1095724pathrev=1095725
Sorry, it was late and made a stupid typo. Pavel is correct, thanks!
--
Got more problems with Automoc4 on OSX unfortunately.
I had to commit revision 1095725 to fix a bug. Without it I get this:
[ 93%] Built target kcmremotewidgetshelper
Generating applethandle_p.moc
/Users/mike/Documents/KDE/KDELibs/plasma/private/applethandle_p.h:42: Error:
Undefined interface
On Wednesday 24 February 2010 19:56:01 Mike Arthur wrote:
To fix it I had to change:
#include QtGui/QGraphicsObject
to:
#include QtGui/QGraphicsObject
Isn't that the same line?
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
2010/2/25 Raphael Kubo da Costa kub...@gmail.com:
On Wednesday 24 February 2010 19:56:01 Mike Arthur wrote:
To fix it I had to change:
#include QtGui/QGraphicsObject
to:
#include QtGui/QGraphicsObject
Isn't that the same line?
he meant
to:
#include QGraphicsObject
On Tuesday 24 March 2009 19:36:19 Helio Chissini de Castro wrote:
4 - w.cpp have an internal Q_OBJECT class and includes w.h with other class
with Q_OBJECT but have no moc includes.
Not sure I understand. If the class declaration is in w.cpp but no moc
included how do you compile a moc file
#include QObject
class W : public QObject
{
Q_OBJECT;
public:
W();
};
-
So, as you see, both header and cpp have no moc includes
automoc4 test, see that aren't any includes, enter in the first
Hi
Since i finished the port of qt-creator build, i'm trying to identify why
automoc4 wasn't been able to build without patches adding moc_* in some codes
but qmake can.
DFaure helped a lot to identify the issue, and we have four corner cases to be
treated:
1 - w.cpp have an internal
finished the port of qt-creator build, i'm trying to identify why
automoc4 wasn't been able to build without patches adding moc_* in some
codes but qmake can.
DFaure helped a lot to identify the issue, and we have four corner cases to
be treated:
1 - w.cpp have an internal Q_OBJECT class
On Segunda-feira 09 Março 2009, David Faure wrote:
On Monday 09 March 2009, Alexander Neundorf wrote:
From your blog I assume you found the problem.
What was wrong ?
First, was the guy who are trying to compile the thing :-)
But yes, thanks to DFaure explanations was all solved
He had
Hello,
When I tried to compile quanta from svn, I got error after executing cmake:
CMake Error: File /automoc4.files.in does not exist
CMake Error at /usr/lib/automoc4/Automoc4Config.cmake:243 (_add_automoc4_target)
/usr/share/apps/cmake/modules/KDE4Macros.cmake:817
to make a cmake build for a Qt only application, in this case
qt- creator
One of the plugins, main one called coreplugin have some .ui forms too, and
i'm trying to use automoc4 to generate the plugin, but the above error
happens.
From your blog I assume you found the problem.
What was wrong
.
Is there something missing ?
Ok, David asked to to explain better the issue
I'm trying to make a cmake build for a Qt only application, in this case
qt- creator
One of the plugins, main one called coreplugin have some .ui forms too, and
i'm trying to use automoc4 to generate
called coreplugin have some .ui forms too, and
i'm trying to use automoc4 to generate the plugin, but the above error
happens.
Hope this helps to explain
--
Helio Chissini de Castro
Mandriva Research and Development
___
Kde-buildsystem mailing list
Kde
Hi,
I have problem with the current svn and looks to be automoc4 related.
This is a 64bit distro that uses /usr/lib64 for 64bit libs I have distro
supplied automoc4 (0.9.84) in /usr/bin and the cmake modules for it in
/usr/lib64/automoc4. cmake fails with:
CMake Error at cmake/modules
Hi,
for all the automoc4 users that cannot use KDE4Macros.cmake I'd like to add
the following two macros:
macro(ADD_AUTOMOC4_EXECUTABLE _target_NAME)
set(_SRCS ${ARGN})
set(_add_executable_param)
foreach(_argName WIN32 MACOSX_BUNDLE EXCLUDE_FROM_ALL)
list(GET _SRCS 0 _arg
On Tuesday 29 July 2008, Matthias Kretz wrote:
Hi,
for all the automoc4 users that cannot use KDE4Macros.cmake I'd like to add
the following two macros:
The names should be AUTOMOC4_ADD_EXECUTABLE() and AUTOMOC4_ADD_LIBRARY(), so
they conform to the cmake modules style guide.
macro
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)
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
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:
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
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}
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
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
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
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
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
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
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
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
() 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
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...
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}
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}
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
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
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
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
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.
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
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
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
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
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
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
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
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
/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
/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
/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
.
into /usr/lib/..., and then create a CMakeLists.txt which just
contains find_package(Automoc4)
This should find the file automatically (if not check with strace).
Please let me know how it works.
So how should I test automoc4? Do I need to clean the build dir of kde*
modules
On Saturday 10 May 2008, Alexander Neundorf wrote:
Do you mean testing if it is found automatically ?
I mean if it is found by the rest of KDE. I build and install everything
into /opt/kde4, including kdesupport. The question is if I need to clear
the build dir/install dir prior to testing, or
if I can make it so that automoc4 is optional for
a few weeks and if it's not found the one from kdelibs is used. This way
developers will have more time to update.
So please don't commit this one yet.
Yes, I considered my patch good enough for testing, not more.
I considered the removal
about the KDE4_SET/GET_TARGET_PROPERTY(), I don't think
anybody else uses them.
But anyway, I want to see if I can make it so that automoc4 is optional
for a few weeks and if it's not found the one from kdelibs is used. This
way developers will have more time to update.
So please don't
On Thursday 08 May 2008, Matthias Kretz wrote:
On Wednesday 07 May 2008, Alexander Neundorf wrote:
On Tuesday 06 May 2008, Dirk Mueller wrote:
On Tuesday 29 April 2008, Alexander Neundorf wrote:
Matthias: if we want to keep the option to get it at some point into
cmake, we (you) need
On Thursday 08 May 2008, Alexander Neundorf wrote:
Oh, and what about FindAutomoc4.cmake? Currently it only exists in
kdesupport/akonadi/cmake/modules...
This will of course also be in kdelibs then.
I thought it could perhaps ship with automoc4 itself. That would then be the
one and only
it easy to run automoc4 manually
Yes, something like automoc4 --clean or something like this which
does that for the current dir and maybe all subdirs would be nice to
have.
How about the following:
- automoc, when done, writes an empty file target_automoc.notclean
On Tuesday 29 April 2008, Alexander Neundorf wrote:
Matthias: if we want to keep the option to get it at some point into cmake,
we (you) need to relicense it to BSD. Can you do that ?
can we add a version number and make a formal release of it? I can do the
tarballing and uploading etc if
generated moc files or something like that ?
Alternatives:
1. add a new target (I'd like to avoid that because it would add a lot
of I/O on a cmake run)
2. make it easy to run automoc4 manually
Yes, something like automoc4 --clean or something like this which does
on those files but didn't write into the Makefile how the .moc
files are created.
Alternatives:
1. add a new target (I'd like to avoid that because it would add a lot
of I/O on a cmake run)
2. make it easy to run automoc4 manually
Yes, something like automoc4 --clean or something like
Hi,
now that automoc4 is in kdesupport and used by akonadi, I think we'll enable
it next week or so also for the rest of KDE (with a transition period where
the one from kdelibs is still used if automoc4 is not found).
I think we have to do some things now:
-write at least some documentation
73 matches
Mail list logo
