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.git&a=commit&h=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
