Re: [cmake-developers] Automoc in cmake
On 9/20/2011 1:26 AM, Alexander Neundorf wrote: set(CMAKE_INCLUDE_CURRENT_DIR ON) automatically adds the current source dir and the current binary dir for each directory which has a target as include directory. This is a bit more than necessary for automoc. For automoc for every target which needs moc'ing its current binary dir has to be added. I'd rather keep CMAKE_AUTOMOC and CMAKE_INCLUDE_CURRENT_DIR separate. When we add per-target include directories then we can document the AUTOMOC property to automatically add the target's binary directory to its include path. Until then it's not too bad to ask projects to set both options. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Sunday, September 18, 2011 07:11:58 PM Marcus D. Hanwell wrote: On Sun, Sep 18, 2011 at 6:39 AM, Alexander Neundorf neund...@kde.org wrote: On Saturday, September 17, 2011 07:16:28 PM Stephen Kelly wrote: Stephen Kelly steveire@... writes: Alexander Neundorf wrote: Would it be possible to make CMAKE_AUTOMOC imply CMAKE_INCLUDE_CURRENT_DIR? All the best, Steve. Is it still possible to consider this? It's not ideal that you have to do this: set(CMAKE_AUTOMOC ON) set(CMAKE_INCLUDE_CURRENT_DIR ON) instead of this: set(CMAKE_AUTOMOC ON) Don't know. I'm usually ok with having to set the include directories explicitely. What do others think ? It seems to me that if you always need to do both for it to work, then it should be a candidate for consolidation. set(CMAKE_INCLUDE_CURRENT_DIR ON) automatically adds the current source dir and the current binary dir for each directory which has a target as include directory. This is a bit more than necessary for automoc. For automoc for every target which needs moc'ing its current binary dir has to be added. So, I'm still not sure. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Saturday, September 17, 2011 07:16:28 PM Stephen Kelly wrote: Stephen Kelly steveire@... writes: Alexander Neundorf wrote: Would it be possible to make CMAKE_AUTOMOC imply CMAKE_INCLUDE_CURRENT_DIR? All the best, Steve. Is it still possible to consider this? It's not ideal that you have to do this: set(CMAKE_AUTOMOC ON) set(CMAKE_INCLUDE_CURRENT_DIR ON) instead of this: set(CMAKE_AUTOMOC ON) Don't know. I'm usually ok with having to set the include directories explicitely. What do others think ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Sun, Sep 18, 2011 at 6:39 AM, Alexander Neundorf neund...@kde.org wrote: On Saturday, September 17, 2011 07:16:28 PM Stephen Kelly wrote: Stephen Kelly steveire@... writes: Alexander Neundorf wrote: Would it be possible to make CMAKE_AUTOMOC imply CMAKE_INCLUDE_CURRENT_DIR? All the best, Steve. Is it still possible to consider this? It's not ideal that you have to do this: set(CMAKE_AUTOMOC ON) set(CMAKE_INCLUDE_CURRENT_DIR ON) instead of this: set(CMAKE_AUTOMOC ON) Don't know. I'm usually ok with having to set the include directories explicitely. What do others think ? It seems to me that if you always need to do both for it to work, then it should be a candidate for consolidation. Marcus ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Tuesday 16 August 2011, Alexander Neundorf wrote: On Tuesday 16 August 2011, Alexander Neundorf wrote: ... There is now a branch AutomocForQt on the cmake stage. Docs and a test are still missing. It has a test now. Docs are still missing. Now it also has docs. I haven't merged it to next yet. Any objections ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
2011/8/16 Alexander Neundorf neund...@kde.org: On Tuesday 16 August 2011, Alexander Neundorf wrote: On Tuesday 16 August 2011, Alexander Neundorf wrote: ... There is now a branch AutomocForQt on the cmake stage. Docs and a test are still missing. It has a test now. Docs are still missing. Now it also has docs. I haven't merged it to next yet. Any objections ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers Brad and I just read through some of your recent commits. In the Tests/CMakeLists.txt there's logic that looks like this: IF(NOT QT4_FOUND) FIND_PACKAGE(Qt4) IF(QT4_FOUND) ... ENDIF() ENDIF() Could you change it to this? IF(NOT QT4_FOUND) FIND_PACKAGE(Qt4) ENDIF() IF(QT4_FOUND) ... ENDIF() That way, when we have builds of CMake where Qt is on (to build cmake-gui) it will run the test. As it stands now, looks like it will not run the test when we already *know* we have Qt available... After that, go ahead and merge to 'next' and see how it looks on the dashboard. Thanks, Dave ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Tuesday 16 August 2011, David Cole wrote: 2011/8/16 Alexander Neundorf neund...@kde.org: On Tuesday 16 August 2011, Alexander Neundorf wrote: On Tuesday 16 August 2011, Alexander Neundorf wrote: ... There is now a branch AutomocForQt on the cmake stage. Docs and a test are still missing. It has a test now. Docs are still missing. Now it also has docs. I haven't merged it to next yet. Any objections ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers Brad and I just read through some of your recent commits. In the Tests/CMakeLists.txt there's logic that looks like this: IF(NOT QT4_FOUND) FIND_PACKAGE(Qt4) IF(QT4_FOUND) ... ENDIF() ENDIF() Could you change it to this? IF(NOT QT4_FOUND) FIND_PACKAGE(Qt4) ENDIF() IF(QT4_FOUND) ... ENDIF() That way, when we have builds of CMake where Qt is on (to build cmake-gui) it will run the test. As it stands now, looks like it will not run the test when we already *know* we have Qt available... Hmm, yes. Not sure what I thought when writing this. After that, go ahead and merge to 'next' and see how it looks on the dashboard. Done. Can a merge to next actually also be undone ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Tue, Aug 16, 2011 at 5:47 PM, Alexander Neundorf neund...@kde.org wrote: On Tuesday 16 August 2011, David Cole wrote: 2011/8/16 Alexander Neundorf neund...@kde.org: On Tuesday 16 August 2011, Alexander Neundorf wrote: On Tuesday 16 August 2011, Alexander Neundorf wrote: ... There is now a branch AutomocForQt on the cmake stage. Docs and a test are still missing. It has a test now. Docs are still missing. Now it also has docs. I haven't merged it to next yet. Any objections ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers Brad and I just read through some of your recent commits. In the Tests/CMakeLists.txt there's logic that looks like this: IF(NOT QT4_FOUND) FIND_PACKAGE(Qt4) IF(QT4_FOUND) ... ENDIF() ENDIF() Could you change it to this? IF(NOT QT4_FOUND) FIND_PACKAGE(Qt4) ENDIF() IF(QT4_FOUND) ... ENDIF() That way, when we have builds of CMake where Qt is on (to build cmake-gui) it will run the test. As it stands now, looks like it will not run the test when we already *know* we have Qt available... Hmm, yes. Not sure what I thought when writing this. After that, go ahead and merge to 'next' and see how it looks on the dashboard. Done. Can a merge to next actually also be undone ? Alex No need for that unless you really want to get rid of a previous commit... Just continue the topic, making further changes, push it to the stage and merge again. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Tuesday 16 August 2011, Alexander Neundorf wrote: ... There is now a branch AutomocForQt on the cmake stage. Docs and a test are still missing. It has a test now. Docs are still missing. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Wednesday 08 June 2011, Brad King wrote: On 6/8/2011 2:59 PM, Alexander Neundorf wrote: The two things are - BSD licensing, we did that 3 years ago: http://quickgit.kde.org/?p=automoc.gita=commith=78fdba1e2d96bc455125317 48ffb770cb1124798 -and porting to STL+cmsys, we did that now Great. Please push a topic to the stage for review. Don't merge it to 'next' yet though. It's not that far yet. You can see current automoc without Qt here: https://projects.kde.org/projects/kdesupport/automoc/repository/show?rev=no-qt It is a standalone executable, and to create an executable with automoc you have to use one of the macros provided in Automoc4Config.cmake: https://projects.kde.org/projects/kdesupport/automoc/repository/revisions/no- qt/entry/Automoc4Config.cmake i.e. automoc4_add_library() or automoc4_add_executable(). This creates a custom target for the respective target, and writes a file which contains the list of course files, include dirs, etc. When integrating it in cmake, it could simply stay that way, or it could be integrated better :-) At cmake time it needs to know: -the list of source files -the target it belongs to With that, it can generat for buildtime -the list of source files -the include directories -the definitions -maybe the directory for the target in CMakefiles/ for helper files This information somehow then at buildtime needs to get into the automoc. Currently this is a plain text file. If integrated, it might make more sense to put that in a cmake script file, so we don't need extra parsing functions. From the interface for the user, it could be an AUTOMOC argument for add_executable/add_library(), or new macros qt[45]_add_executable/library() could be created. This can be done in C++ or cmake script, both should be ok. At build time, the logic is complex enough and it also has to be really fast so that this should IMO be done in the C++. It could either be a -E automoc infofile option, or a -P CMakeAutomoc.cmake script, which then calls a new automoc() function. This then needs to go through the list of source files, and if the file is newer than the associated stamp-file or if no stamp-file exists, it needs to parse the source file for a #include-moc statement, and if found, execute moc to generate this include file. And we need to make sure it is at least flexible enough for future Qt/moc changes. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Thursday 09 June 2011, Alexander Neundorf wrote: ... At build time, the logic is complex enough and it also has to be really fast so that this should IMO be done in the C++. It could either be a -E automoc infofile option, or a -P CMakeAutomoc.cmake script, which then calls a new automoc() function. This then needs to go through the list of source files, and if the file is newer than the associated stamp-file or if no stamp-file exists, it needs to parse the source file for a #include-moc statement, It does even more that that. Some comments from the implementation: // the program goes through all .cpp files to see which moc files are // included. It is not really interesting how the moc file is named, but what // file the moc is created from. Once a moc is included the same moc may not // be included in the _automoc.cpp file anymore. OTOH if there's a // header containing Q_OBJECT where no corresponding moc file is included // anywhere a moc_filename.cpp file is created and included in the // _automoc.cpp file. ... // If the moc include is of the moc_foo.cpp style we expect the Q_OBJECT class // declaration in a header file. // If the moc include is of the foo.moc style we need to look for a Q_OBJECT // macro in the current source file, if it contains the macro we generate the // moc file from the source file, else from the header. Which the moc-scanner still could do. The interface I talked about is basically to allow CMake to filter noise away from the scanners so they don't get called for things they don't care about at all. What the scanner later does with the files it get's passed is only his point. Eike ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 6/9/2011 4:12 AM, Alexander Neundorf wrote: AFAIK depending on generated files via the #include does not work/is not reliable (that's why generated files need to be added to the target). For the Makefile generators, each target builds in three steps: (1) Generate all custom command outputs (2) Run implicit dependency scanning (#include) (3) Compile source files This ensures that any generated sources are available in time to be picked up as dependencies of the compilation step. However, this all depends on knowing at CMake time what custom command outputs will be needed and adding them to the target so they show up in step (1). -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 6/9/2011 8:47 AM, Alexander Neundorf wrote: So, if I would create a dummy foo.automoc file from automoc, and added this to the target, this would make sure that any files created as side-effects of this custom command would already exist when any source files are compiled ? Yes. I cannot say off the top of my head how that would work for the non-Makefile generators though. But this still means that custom commands cannot be triggered via the implicit dependency scanning, right ? Custom commands will not be drawn into a target by CMake if the only reference to their output is implicit in source file content. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Thursday, June 09, 2011 01:23:09 am Alexander Neundorf wrote: On Wednesday 08 June 2011, Brad King wrote: On 6/8/2011 2:59 PM, Alexander Neundorf wrote: The two things are - BSD licensing, we did that 3 years ago: http://quickgit.kde.org/?p=automoc.gita=commith=78fdba1e2d96bc4551253 17 48ffb770cb1124798 -and porting to STL+cmsys, we did that now Great. Please push a topic to the stage for review. Don't merge it to 'next' yet though. It's not that far yet. You can see current automoc without Qt here: https://projects.kde.org/projects/kdesupport/automoc/repository/show?rev=no -qt It is a standalone executable, and to create an executable with automoc you have to use one of the macros provided in Automoc4Config.cmake: https://projects.kde.org/projects/kdesupport/automoc/repository/revisions/n o- qt/entry/Automoc4Config.cmake i.e. automoc4_add_library() or automoc4_add_executable(). This creates a custom target for the respective target, and writes a file which contains the list of course files, include dirs, etc. When integrating it in cmake, it could simply stay that way, or it could be integrated better :-) At cmake time it needs to know: -the list of source files -the target it belongs to With that, it can generat for buildtime -the list of source files -the include directories -the definitions -maybe the directory for the target in CMakefiles/ for helper files This information somehow then at buildtime needs to get into the automoc. Currently this is a plain text file. If integrated, it might make more sense to put that in a cmake script file, so we don't need extra parsing functions. From the interface for the user, it could be an AUTOMOC argument for add_executable/add_library(), or new macros qt[45]_add_executable/library() could be created. I'd like to see us go towards qt_* instead of having qt[45]_*. This can be done in C++ or cmake script, both should be ok. At build time, the logic is complex enough and it also has to be really fast so that this should IMO be done in the C++. It could either be a -E automoc infofile option, or a -P CMakeAutomoc.cmake script, which then calls a new automoc() function. This then needs to go through the list of source files, and if the file is newer than the associated stamp-file or if no stamp-file exists, it needs to parse the source file for a #include-moc statement, and if found, execute moc to generate this include file. And we need to make sure it is at least flexible enough for future Qt/moc changes. I'm just curious if trying to put automoc in Qt has been pursued, and maybe changing qmake to use automoc. It seems that would guarantee maintenance/compatibility for future versions of Qt. And if a future version of Qt could be compiled using CMake, having automoc on the Qt side would fit with having Qt-config.cmake and macros. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Monday, June 06, 2011 03:37:16 PM Brad King wrote:
On 06/06/2011 03:56 AM, Alexander Neundorf wrote:
On Saturday, June 04, 2011 10:24:52 AM Alexander Neundorf wrote:
Hi,
one feature which all KDE developers are used to and which is also used
by qmake when building Qt is automoc.
This means that you don't have to write
qt4_wrap_cpp(srcs ${filesToBeMoced})
but instead you simply do
kde4_add_executable(hello ${srcs})
and everything including moc is handled automatically.
I agree with Nico's response that this is too specific to integrate into
CMake itself. That level of automagic processing puts too much inside
the add_executable and add_library commands. This kind of customization
belongs in macros.
Yesterday we finished porting our automoc away from Qt to pure STL/cmsys.
It is now a small executable of 300kb and linking to nothing special.
It is also BSD-licensed.
Great! I suggest you package this in a distribution that provides the
executable and CMake macros to use it:
That's already the current state, and developers are not happy with it.
They don't know about it or adding yet another dependency to the build is a
problem for them, e.g. due to strict policies at work.
I do not make this up, people come to me and complain that cmake doesn't do
it.
Everybody I talked to who is used to automoc from KDE or from qmake wants to
have it available directly in cmake.
Even the one Gnome guy who was in Randa was not happy with cmake for some Qt
projects he had because it didn't do automoc. So he felt cmake is too
complicated and stayed with qmake.
The same for about every KDE developer, i.e. hundreds.
We (me, you, Bill, Matthias Kretz, Andreas Hartmetz) talked about this
before, in march 2008. In a mail from March 18, 2008, you write:
--88--8-
Alexander Neundorf wrote:
in kdelibs we have a tool automoc, which is used to handle the moc files
of Qt automatically, i.e. it parses the source files for Q_OBJECT etc. and
runs moc as required.
It is written using Qt 4 (QtCore only AFAIK).
In order to make this usable also for Qt-only applications we (KDE) would
like to move automoc out of kdelibs, the first step would be a separate svn
module, or ideally directly into cmake.
Adding automoc would be a great motivation for people to use CMake for
Qt-based stuff.
...
If those two things were met, would you accept it in cmake cvs as an
additional tool or maybe also as a built-in command line command (as -E copy
etc.) ?
If it is not too much code I'm not against accepting it. Bill?
...
-Brad
--88--8-
The two things are
- BSD licensing, we did that 3 years ago:
http://quickgit.kde.org/?p=automoc.gita=commith=78fdba1e2d96bc45512531748ffb770cb1124798
-and porting to STL+cmsys, we did that now
Beside that, I didn't ask explicitely, but I'm sure without automoc cmake is
out of the game for becoming the buildsystem for Qt5 (because in Qt4 they do
automoc in qmake).
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 6/8/2011 2:59 PM, Alexander Neundorf wrote: The two things are - BSD licensing, we did that 3 years ago: http://quickgit.kde.org/?p=automoc.gita=commith=78fdba1e2d96bc45512531748ffb770cb1124798 -and porting to STL+cmsys, we did that now Beside that, I didn't ask explicitely, but I'm sure without automoc cmake is out of the game for becoming the buildsystem for Qt5 (because in Qt4 they do automoc in qmake). Alex I think it would be a good idea to have automoc support in CMake. -Bill ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 6/8/2011 3:33 PM, Clinton Stimpson wrote: It seems an extra tool is needed at build time to handle qrc files correctly, and I'm wondering if a generic tool could handle both this and the autmoc. It is not possible to implement custom build-time dependency scanning in VS IDE projects without creating some kind of VS plugin that defines a new language. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 6/8/2011 2:59 PM, Alexander Neundorf wrote: The two things are - BSD licensing, we did that 3 years ago: http://quickgit.kde.org/?p=automoc.gita=commith=78fdba1e2d96bc45512531748ffb770cb1124798 -and porting to STL+cmsys, we did that now Great. Please push a topic to the stage for review. Don't merge it to 'next' yet though. Thanks, -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 06/08/2011 09:24 PM, Bill Hoffman wrote: On 6/8/2011 2:59 PM, Alexander Neundorf wrote: The two things are - BSD licensing, we did that 3 years ago: http://quickgit.kde.org/?p=automoc.gita=commith=78fdba1e2d96bc45512531748ffb770cb1124798 -and porting to STL+cmsys, we did that now Beside that, I didn't ask explicitely, but I'm sure without automoc cmake is out of the game for becoming the buildsystem for Qt5 (because in Qt4 they do automoc in qmake). Alex I think it would be a good idea to have automoc support in CMake. -Bill Although this is not really my call, here my thoughts: While I share some of the concerns that this is a very specialist tool of little use in general, but considering the importance of Qt, the strong coupling between KDE and CMake and finally the possibility of CMake becoming the QMake replacement, I think this makes a strong case for an exception here. So, +1 from me. Michael ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Wed, Jun 8, 2011 at 1:35 PM, Brad King brad.k...@kitware.com wrote: On 6/8/2011 3:33 PM, Clinton Stimpson wrote: It seems an extra tool is needed at build time to handle qrc files correctly, and I'm wondering if a generic tool could handle both this and the autmoc. It is not possible to implement custom build-time dependency scanning in VS IDE projects without creating some kind of VS plugin that defines a new language. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers I'm just hearing about this automoc thing. I'm wondering if whatever mechanism that is used to handle the dependency generation could be used for FindCUDA.cmake. Currently I have to compute the dependencies using 'nvcc -M' and then adding those dependencies explicitly through the add_custom_command that generates the output from the CUDA source. Any thoughts? James ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
Clinton Stimpson wrote:
On Wednesday, June 08, 2011 12:59:36 pm Alexander Neundorf wrote:
Beside that, I didn't ask explicitely, but I'm sure without automoc
cmake
is out of the game for becoming the buildsystem for Qt5 (because in Qt4
they do automoc in qmake).
What if this was a generic tool that could scan code to handle custom
dependencies, with the ability to do two things: (re)generated dependent
files or (re)generate the file with dependencies (sounds like a make tool
;) ). Don't some Visual Studio users do this type of custom build
phases/steps/thingy by creating an Add-In?
Would that be an automoc equivalent if there was a macro that gave it the
rules for generating the dependencies?
Also, (a long outstanding bug), a Qt .qrc file has dependencies specified in
xml, which should be handled at build time.
Isn't there already a build-time scanner to add dependencies? Those C/C++ files
need to be scanned to identify header dependencies which may change between
build runs also, no? So isn't this all about the same stuff? And for automoc
it's basically only a special case of this since this is also an include, just
one with a special pattern that adds additional dependencies.
I'm all in favor of a generic solution. So maybe we could step back and look
from a slightly greater distance at this. What would such a scanner need to
know? And what does it need to tell CMake to run properly?
Tell CMake:
-which source types it wants to pass (C/C++/Java/ASM/other/*)
-if it cares for header files
-to avoid tokenizing all files in all scanners a pattern to look for. If that
pattern is empty every file is passed to the scanner, otherwise only those
where at least one matches that pattern
-a flag if only matching lines should be send to the scanner (greatly reducing
computation time)
What it would return:
-for every file passed a list of files this one would depend on (testcases to
reject: file depending on itself, introducing simple loops)
That would work out for the qrc and header scanner as the files they depend on
are usually already there or defined by some target. This would not be enough
for the automoc case since someone needs to create the targets that generates
the moc_foo.cxx or foo.moc. So the scanner needs to be able to return
additional CMake code that would be parsed and used as if it was defined right
before the library/executable we try to create.
The next step would be to think about how people could come up with additions.
Say I want to write a scanner for some language. Must it be C++ code? Or can
this somehow be hooked into CMake just as CMake script? How would that go?
This way we could implement the whole automoc stuff just this way.
Alex, would this be a sufficient description for automoc?
language: C++
header files: only
pattern: Q_OBJECT
result files: none (will be handled by the usual include scanner of the C++
file)
result code: ADD_CUSTOM_TARGET(... ${QT_MOC_EXECUTABLE} ...)
Eike
signature.asc
Description: This is a digitally signed message part.
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Saturday, June 04, 2011 10:24:52 AM Alexander Neundorf wrote:
Hi,
one feature which all KDE developers are used to and which is also used by
qmake when building Qt is automoc.
This means that you don't have to write
qt4_wrap_cpp(srcs ${filesToBeMoced})
but instead you simply do
kde4_add_executable(hello ${srcs})
and everything including moc is handled automatically.
Yesterday we finished porting our automoc away from Qt to pure STL/cmsys. It
is now a small executable of 300kb and linking to nothing special.
It is also BSD-licensed.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 06/06/2011 03:56 AM, Alexander Neundorf wrote:
On Saturday, June 04, 2011 10:24:52 AM Alexander Neundorf wrote:
Hi,
one feature which all KDE developers are used to and which is also used by
qmake when building Qt is automoc.
This means that you don't have to write
qt4_wrap_cpp(srcs ${filesToBeMoced})
but instead you simply do
kde4_add_executable(hello ${srcs})
and everything including moc is handled automatically.
I agree with Nico's response that this is too specific to integrate into
CMake itself. That level of automagic processing puts too much inside
the add_executable and add_library commands. This kind of customization
belongs in macros.
Yesterday we finished porting our automoc away from Qt to pure STL/cmsys.
It is now a small executable of 300kb and linking to nothing special.
It is also BSD-licensed.
Great! I suggest you package this in a distribution that provides the
executable and CMake macros to use it:
find_package(Automoc) # substitute better name here?
Automoc_add_executable(...)
-Brad
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Automoc in cmake
Hi,
one feature which all KDE developers are used to and which is also used by
qmake when building Qt is automoc.
This means that you don't have to write
qt4_wrap_cpp(srcs ${filesToBeMoced})
but instead you simply do
kde4_add_executable(hello ${srcs})
and everything including moc is handled automatically.
This is done so that in your foo.cpp file you include the moc-file e.g. at the
end:
---
Foo::Foo()
:QObject()
{
}
...
void Foo::doSomething()
{
}
#include foo.moc
What needs to be done for this is to parse all source files for such include
lines at build time (because such a line may have been inserted without
changing anything in CMakeLists.txt) and if such a line is found, moc has to
be started and the file has to be generated.
Currently this is done by the tool automoc4 which is a separate package.
It consists of a binary automoc4 and a macro
automoc_add_executable().
What this macro basically does is to add for each target foo an additional
target foo_automoc, and make the target foo depend on foo_automoc. So
foo_automoc is always built before foo.
The custom target foo_automoc basically runs the automoc4 executable, which
checks for all source files whether they have changed, and whether they
contain moc-include statements, and if so, it runs moc.
So, we'd like to have that available in cmake.
I see two ways how to do it:
1) keep the mechanism as it is, but integrate the functionality of the automoc
executable into cmake, so that the custom target would do cmake --automoc or
something like this.
This would still need an additional macro, which would then probably be
qt_add_executable().
When doing automoc, the list of source files has to be known, the include
directories and the defines.
This is currently written into a file which is then loaded by automoc4.
When integrating it this way, this would probably stay more or less like this.
2) Integrate it fully into cmake, i.e. add arguments to add_executable() and
add_library(), so I can do
add_executable(foo AUTOMOC ${srcs} )
Advantages of this would be that it doesn't need an extra macro and extra
custom target to be set up, and that the information like the list of files
and include directories is directly available in cmAddExecutable, so it
doesn't have to be written in a separate file which is read later on.
So, we'd really like to have that integrated in cmake.
What do you think ? Which way would you prefer ? I think I'm favouring option
2).
I'll work in the next days on porting current automoc away from using Qt to
plain STL (and kwsys), so that it becomes ready for inclusion. It is also
already BSD licensed.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
Hi,
IMHO, both proposals are too Qt/KDE specific to be integrated into
cmake this way. Maybe cmake could provide a more generic approach
like allowing you to run whatever dependency scanner at some stage in
the build process.
-Nico
On Saturday, June 4, 2011, Alexander Neundorf neund...@kde.org wrote:
Hi,
one feature which all KDE developers are used to and which is also used by
qmake when building Qt is automoc.
This means that you don't have to write
qt4_wrap_cpp(srcs ${filesToBeMoced})
but instead you simply do
kde4_add_executable(hello ${srcs})
and everything including moc is handled automatically.
This is done so that in your foo.cpp file you include the moc-file e.g. at the
end:
---
Foo::Foo()
:QObject()
{
}
...
void Foo::doSomething()
{
}
#include foo.moc
What needs to be done for this is to parse all source files for such include
lines at build time (because such a line may have been inserted without
changing anything in CMakeLists.txt) and if such a line is found, moc has to
be started and the file has to be generated.
Currently this is done by the tool automoc4 which is a separate package.
It consists of a binary automoc4 and a macro
automoc_add_executable().
What this macro basically does is to add for each target foo an additional
target foo_automoc, and make the target foo depend on foo_automoc. So
foo_automoc is always built before foo.
The custom target foo_automoc basically runs the automoc4 executable, which
checks for all source files whether they have changed, and whether they
contain moc-include statements, and if so, it runs moc.
So, we'd like to have that available in cmake.
I see two ways how to do it:
1) keep the mechanism as it is, but integrate the functionality of the automoc
executable into cmake, so that the custom target would do cmake --automoc or
something like this.
This would still need an additional macro, which would then probably be
qt_add_executable().
When doing automoc, the list of source files has to be known, the include
directories and the defines.
This is currently written into a file which is then loaded by automoc4.
When integrating it this way, this would probably stay more or less like this.
2) Integrate it fully into cmake, i.e. add arguments to add_executable() and
add_library(), so I can do
add_executable(foo AUTOMOC ${srcs} )
Advantages of this would be that it doesn't need an extra macro and extra
custom target to be set up, and that the information like the list of files
and include directories is directly available in cmAddExecutable, so it
doesn't have to be written in a separate file which is read later on.
So, we'd really like to have that integrated in cmake.
What do you think ? Which way would you prefer ? I think I'm favouring option
2).
I'll work in the next days on porting current automoc away from using Qt to
plain STL (and kwsys), so that it becomes ready for inclusion. It is also
already BSD licensed.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--
Nicolas Desprès
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
