[cmake-developers] Automoc in cmake

[Rolf Eike Beer]

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