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
__________________________
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
