Alex Neundorf wrote: > On Thursday 09 June 2011, Rolf Eike Beer wrote: >> Clinton Stimpson wrote: >> > On Wednesday, June 08, 2011 12:59:36 pm Alexander Neundorf wrote:
>> 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? > > I didn't succeed in finding a more general picture. > > Automoc does: > -scan all given source files for special #includes Ok, so it has nothing to do with searching for Q_OBJECT. This just changes the "pattern" to be "whatever the generic include scanner does, and then filter for moc_* and *.moc in the filename". > -if such are found, run moc to create them > -make sure this happens before the including file is compiled > > So, the problem is, that at cmake time it is not known which files will > have to be generated, so I can't use add_custom_command() to create rules > for these files. > > Right now this is done by adding an extra target <targetname>_automoc to > every target. > If I added a custom command for every source file, which would create > basically a timestamp file, and run automoc just on this source file, I > would get the mocs generated, and automoc only rerun if the source file > changed, but > since the source file depends on the moc files which come from a rule > which depends on the source file, I would get a cyclic dependency I think: Wouldn't it be enough to just say the target depends on the source file? "make" does this sort of dependency checking anyway, so let them do this sort of stuff. > add_custom_command( > OUTPUT <filename>.automoc > COMMAND automoc file.cpp -o file.automoc (..and the yet unknwown > mocfiles) > DEPENDS file.cpp ) > > add_executable(hello main.cpp file.cpp file.automoc ) > > I can't remember whether we tried that approach too, but wouldn't his > produce > a cycle in the dependencies ? No idea. >> 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. > > But this has to happen at build time, not cmake time, since the #include > "moc" > can be added without touching the cmake files. Yes, sure. So that means the resulting CMake code needs to be parsed and executed by CMake on every build... uh-oh, I see a huge slowdown here :(. Otherwise CMake already generates all sort of scripts (like .bat files for MSVC) so this could just go there somehow. The point of this "CMake-code" was not that it has to be run at cmake time, but that we don't introduce yet another language here. Eike _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
