[CMake] Generated files?

Fri Jan 30 10:40:58 EST 2015

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 <petr.kmoch at gmail.com> 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 <cxjohnson at gmail.com>
> 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 <petr.kmoch at gmail.com> 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 <cxjohnson at gmail.com>
>>> 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 <kgt at lanl.gov> 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:cmake-bounces at cmake.org] *On Behalf Of *Chris
>>>>> Johnson
>>>>> *Sent:* Thursday, January 29, 2015 8:09 AM
>>>>> *To:* cmake at cmake.org
>>>>> *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
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150130/abe68f05/attachment-0001.html>