[cmake-developers] Current deficiencies of automoc

[Alan W. Irwin]

On 2016-10-22 19:49+0200 Sebastian Holtermann wrote:

> Actually I made an implementation in 3.6.0 that generated the moc files
> in the a build tree subdirectory correspoding to the header path.
> But that blew up on some projects because the generated paths got too long 
> for some compiĺers. That implementation was theefore reverted.
> In 3.7  there is a new approatch that generates the moc files in
> ${CMAKE_BINARY_DIR}/
>    ${TARGETNAME}_automoc.dir/
>        ${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp
> This ensures that the paths don't get too long and that there won't be any 
> name collisions.

Hi Sebastian:

Now that I have thought a bit more about this, you do need to
distinguish by target since those can have different automoc options,
and even if that is the same for the two targets, you would not want
multiple moc commands on the same header to generate the same output
file at the same time.  So this looks like an excellent naming scheme
that will avoid all such collisions.

However, I see no sign of this new approach in my recent compilation
of 3.7.0-rc2, nor in the automoc documentation for the master branch
tip (or next branch tip).  So is it really going to get into 3.7.0
(including the automoc documentation of this new approach)?

Also, I tested the simple test case modified to add an additional
target using the same source code and CMake-3.7.0-rc2.  That currently
does generate the same filename for the two different moc output
results, and I was also surprised (considering the 3.7.0-rc2 automoc
documentation that states there would be a diagnostic warning of moc
output collisions) there was no collision diagnostic for this
particular case of two targets in the same directory. But your above
approach (once it gets into 3.7) should avoid all such collisions (and
thus make collision diagnostics moot).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________