[cmake-developers] Compile targets affected by changeset

[Robert Patterson via cmake-developers]

Greetings,My company has a large, predominately C++ codebase, with hundreds of targets, both for product and unit tests.  In an effort to improve the compile and test time for developers, which utilizes a continuous integration infrastructure, it is desirable to compile only the targets that are affected by developer's change sets.Our approach leverages the cmake target source file information, along with the dependency graph, to identify which targets are directly affected by the changeset, and then trace the dependency graph to find all targets which depend on these files. We use 'make', so cmake does not analyze header information, so we must have a preprocessing step (makedepend or gcc -M) to identify which source files may be affected by the header files in the change set. These indirectly changed sources are fed back into the file changeset.'make' has a limitation where if 'make target1 target2 target3' is invoked, target1, target2, and target3 are built serially, not in parallel. To get around this, we decided that the best option was to dynamically create a new [cmake] target which depends on the affected targets. This is where we could use some guidance as we have two possible approaches: 1. This could either be implemented in cmake code; by supplying a command line argument, specifying the "dynamic" target which in turn would create a target during the generation process. 2. Explicitly specify the "dynamic" target in our project's CMakeLists.txt file, and allow cmake to simply add the affected targets as a dependency to the dynamic target.Our current (attached) patch adds an option (--change-set=) for to cmake to read a (newline separated with absolute paths) file which contains the list of files in the changeset. cmake parses the file and outputs the set of affected targets and then exits before makefile generation.We would like your opinions on how to best implement this. Would it be better to handle the creation of the dummy target in CMakeLists.txt, or to handle it in cmake code?  Additionally, would you be interested in adopting these changes upstream?option 1:cmake --change-set=mychanges.txt >> targets.txtcreate dummy target in CMakeLists.txtcmake (parses targets.txt and adds dependencies to dummy-target)make dummy-target pros: simple, small addition to cmakecons: less general, complexity moved to build scriptsoption 2:cmake --change-set=mychanges.txt >> targets.txtcmake --dependencies=targets.txt --dynamic-target=dummy-targetmake dummy-targetoption 3:cmake --change-set=mychanges.txt --dynamic-target=dummy-targetmake dummy-targetpros: more generalcons: more complexity introduced to cmake codeI appreciate your time and look forward to your feedback.--Robert Patterson

compile-changeset.patch
Description: Binary data
-- 

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

[cmake-developers] Making your regular expression engine more reliable

[Alan W. Irwin]

I have just discovered a long-standing regular expression bug (see
) that has been
around since at least 3.0.2.

So your unit tests for regular expressions obviously missed at least
this issue. I have no idea what those unit tests are (or even if they
exist), but one possibility for attempting to wring most of the bugs out
of your regular expression processor is to adapt some other project's
regexp test suite. See

for a rather large list of such test suites.

Another possibility is simply to forget supporting your own regexp
engine and adopt someone else's very well regarded regexp engine (such
as libprng).  I vaguely recall that has been suggested before, but
since that hasn't happened I presume inertia or NIH syndrome won or
else there was some strong reason why you didn't go that route.


From my perspective as a strongly interested CMake user (but not a

CMake developer or regexp guru) that wants a completely reliable
regular expression engine for CMake, I don't care which of these two
approaches you use to achieve that goal.  But I hope my starting
this topic here will facilitate reaching that goal.

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