Petr, thanks. That makes a lot of sense. Now I am struggling with causing all of these files to be generated when I do the default build target, e.g. just "make" in the build directory. That is, I want myprog to be compiled, and then all of the files processed by it with just one build command. I assume that's possible, but have not quite yet been able to make it happen.
On Fri, Jan 30, 2015 at 9:11 AM, Petr Kmoch <[email protected]> wrote: > As you say, **make** is fairly powerful at this. Other build tools may not > be, it might even be an alien concept to them. AFAIK, Ninja requires an > explicit list of files & dependencies, for example. Visual Studio solutions > can only contain explicitly listed files too. > > CMake projects are supposed to work with all generators which CMake > supports (within reason). There are some generator-specific features in > CMake, but the intent is to keep the set of these to a minimum. > > The list of CMake commands which directly create build-time "commands" > (such as Makefile rules) is rather short: > > add_custom_command() > add_custom_target() > add_executable() > add_library() > > Other commands modify the buildsystem (e.g. add_definitions(), > target_link_libraries(), or setting properties such as COMPILE_OPTIONS), > but they don't really add "commands" to it. > > Petr > > > On Fri, Jan 30, 2015 at 3:27 PM, Chris Johnson <[email protected]> > wrote: > >> That does clarify a few things yes. Thank you. >> >> By "configure" time I had meant the first two items you listed as >> Configure and Generate. By "run" time I had meant what you called Build. >> >> One place I am unclear on is exactly which commands in CMakeLists.txt get >> translated into Build time commands in buildsystem files (in my case, >> make). For example, make is fairly powerful at generating substitution >> file names, e.g. creating prog.o from prog.cpp, or file1.out from >> file1.in. Make is also capable of running full shell scripts within a >> makefile. But there's no obvious way to drive any kind of automation from >> CMake that make is capable of. >> >> As a programmer, my first thought when having to process a large list of >> files is to do it through some sort of automation, rather than generate a >> brute force solution. It appears that with CMake, the best one can hope >> for is to automate the creation of the brute-force solution. >> >> -- >> Cheers, >> ..chris >> >> On Fri, Jan 30, 2015 at 4:32 AM, Petr Kmoch <[email protected]> wrote: >> >>> It's not clear to me what you mean with "run" time. There are the >>> following "times" involved in a CMake-based project: >>> >>> * Configure time: >>> CMake is parsing CMakeLists.txt files and files included from those and >>> executing ALL CMake commands found in them. Variables expansion takes >>> place. Data structures in CMake's memory are filled. >>> >>> * Generate time: >>> CMake processes the data structures in its memory to write buildsystem >>> files (Makefiles, solutions etc.) to disk. Generator expressions are >>> expanded. Files are generated from data specified in file(GENERATE ...) >>> commands. cmake_install.cmake file is written based on the contents of data >>> structures filled by install() commands. >>> >>> * Build time: >>> CMake is not running (except for driving the build if you do that with >>> `cmake --build`). The build tool (make, ninja, devenv, msbuild, ...) is >>> running, processing the buildsystem files and generating compiled binaries. >>> At this time, commands which were set up by add_custom_command() and >>> add_custom_target() are executed as driven by the build tool. >>> >>> * Install time (optional): >>> Running `make install` or similarly triggering the install process >>> causes CMake to run in installation mode. This CMake reads the >>> cmake_install.cmake file and executes the commands there. These are mainly >>> file() commands which copy files to the desired location. >>> >>> CMake commands in CMakeLists.txt and included files are all executed >>> during configure time, as the files are parsed and processed by CMake. Some >>> of these commands have immediate effects on the outside environment (e.g. >>> file(WRITE), execute_process(), try_compile()), some affect the CMake >>> processing control flow (e.g. include(), foreach()), some fill in or modify >>> CMake's data structures (e.g. set(), add_executable(), install(), >>> add_custom_command()). >>> >>> So there are no CMake commands executed after configure time. The value >>> specified in a COMMAND argument of add_custom_command() executes at build >>> time (driven by the build system), but the add_custom_command() itself >>> executes at CMake time. >>> >>> I hope I've clarified it a little bit. >>> >>> Petr >>> >>> >>> >>> On Thu, Jan 29, 2015 at 9:36 PM, Chris Johnson <[email protected]> >>> wrote: >>> >>>> Thanks; I appreciate the suggestions. >>>> >>>> One thing that jumped out is the thought that foreach() is executed at >>>> "configuration" time, not "run" time. To me, that was counter-intuitive, >>>> but makes more sense once more thoroughly considered. >>>> >>>> But I have to admit, I've never seen anything in the documentation >>>> which lists all of the commands which execute at configuration time, and >>>> which are executed at run time. Is there such documentation? A link to it >>>> would be great. >>>> >>>> On Thu, Jan 29, 2015 at 9:51 AM, Thompson, KT <[email protected]> wrote: >>>> >>>>> Hi Chris, >>>>> >>>>> >>>>> >>>>> Why not use a foreach loop? Something like this… >>>>> >>>>> >>>>> >>>>> add_executable(myprog myprog.cpp) >>>>> >>>>> set( files file001 fiile002 …) >>>>> >>>>> foreach( file in files) >>>>> >>>>> add_custom_command(OUTPUT ${file}.out >>>>> >>>>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/${file}.in . >>>>> >>>>> COMMAND myprog ${file}.in ${file}.out >>>>> >>>>> DEPENDS ${file}.in myprog.cpp >>>>> >>>>> ) >>>>> >>>>> endforeach() >>>>> >>>>> >>>>> >>>>> For portability, you might want to use ‘${CMAKE_COMMAND} –E >>>>> copy_if_different’ in place of ‘/bin/cp’ and CMAKE_CURRENT_BINARY_DIR in >>>>> place of ‘.’ >>>>> >>>>> >>>>> >>>>> -kt >>>>> >>>>> >>>>> >>>>> *From:* CMake [mailto:[email protected]] *On Behalf Of *Chris >>>>> Johnson >>>>> *Sent:* Thursday, January 29, 2015 8:09 AM >>>>> *To:* [email protected] >>>>> *Subject:* [CMake] Generated files? >>>>> >>>>> >>>>> >>>>> I am looking for suggestions on how to solve the following problem. >>>>> I need a solution which is easy to understand and safe from future >>>>> maintenance errors. >>>>> >>>>> >>>>> >>>>> There is a project directory with one C++ program and a large number >>>>> of "input" data files. >>>>> >>>>> >>>>> >>>>> The C++ program needs to be compiled, and then run against each of the >>>>> input files to generate an output file of the same base name but with a >>>>> different output suffix. E.g. from the command line it might be: >>>>> >>>>> >>>>> >>>>> % myprog file001.in file001.out >>>>> >>>>> >>>>> >>>>> Finally, the output files need to be installed in the proper location. >>>>> >>>>> >>>>> >>>>> For one input file, it might look like this: >>>>> >>>>> >>>>> >>>>> add_executable(myprog myprog.cpp) >>>>> >>>>> add_custom_command(OUTPUT file001.out >>>>> >>>>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . >>>>> >>>>> COMMAND myprog file001.in file001.out >>>>> >>>>> DEPENDS files001.in myprog.cpp >>>>> >>>>> ) >>>>> >>>>> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out DESTINATION >>>>> share/docs) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Listing all of the input files in my CMakeLists.txt file is not a >>>>> problem, but it would be nice to avoid having to list the corresponding >>>>> output files. >>>>> >>>>> >>>>> >>>>> How can I build a CMakeLists.txt file which will succinctly handle >>>>> this situation? >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> >>>>> ..chris >>>>> >>>> >>>> >>>> -- >>>> >>>> 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 >>>> >>> >>> >> >
-- 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
