[CMake] control dependencies in cmake stage

Thu Mar 19 11:26:35 EDT 2015

Thank you Mark for hint about that solution. I think the losses may be
reduced by distributing #includes directives across many well known files
(as in  example: GenChunk.tar) Those chunks can be already compiled in
parallel.

Best regards, Tomasz.

2015-03-12 17:50 GMT+01:00 Mark Abraham <mark.j.abraham at gmail.com>:

> Hi,
>
> In that case, you could have the generator generate a master source file
> with a known name that #includes the real generated files. This means that
> the generation can have clean dependencies, but does lose any benefits from
> parallel make. It also keeps the intrinsic complexity of the generation
> close to itself, rather than unduly complicating the build system. Up to
> you.
>
> Mark
> On 11/03/2015 6:40 pm, "Tomasz Majchrowski" <contact at majchrowski.de>
> wrote:
>
>> Thank you Mark for information. The input for the generator is in-house
>> developed language. The decision what kind of files will be generated is
>> made based on the grammar of this language.
>>
>> In the current implementation of the generator the extraction of the file
>> list will take more or less the same time as execution of the generation
>> phase itself. Otherwise we will definitely use make phase.
>>
>> Best regards, Tomasz.
>>
>> 2015-03-11 0:15 GMT+01:00 Mark Abraham <mark.j.abraham at gmail.com>:
>>
>>> Hi,
>>>
>>> Sure, this is straightforward to do all at make time, if you're prepared
>>> to find out what the names of the generated files are. They must follow
>>> some pattern ;-). Solutions with make-time globbing are surely impossible,
>>> and Petr's IF idea seems brittle to me.
>>>
>>> See (for example)
>>> https://github.com/gromacs/gromacs/blob/master/src/gromacs/CMakeLists.txt#L154.
>>> The idea is that you have some target that does the generation, and you
>>> make the eventual library/executable depend on its output files. The target
>>> that contains the generation command has its own dependencies, so you don't
>>> have to re-generate if those don't go out of date. In that example,
>>> gmx_configure_version_file just wraps configure_file(), which sets up that
>>> dependency chain. You'd need an add_custom_command(), it seems, whose
>>> OUTPUT had the list of generated files. There's no problem to use
>>> add_library() with a file generated in the build tree - just mention it in
>>> an output.
>>>
>>> There are several much more complicated examples at
>>> https://github.com/gromacs/gromacs/blob/master/docs/CMakeLists.txt. For
>>> example, we build a gmx binary that writes the same text we display with
>>> "gmx topic -h" instead as topic.rst restructedText, which is then parsed
>>> with Sphinx to produce manpages that go in the tarball via CPack, or to
>>> produce HTML to go on our webpage. Helper scripts mostly live in
>>> https://github.com/gromacs/gromacs/tree/master/cmake
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>>
>>> On Tue, Mar 10, 2015 at 6:06 PM, Tomasz Majchrowski <
>>> usenet at majchrowski.de> wrote:
>>>
>>>> (sorry if you received this message twice)
>>>>
>>>> Hi Mark
>>>>
>>>> This is the  set of C++ source code files. This set will be compiled
>>>> during the make stage. Ideally will be to move generation to make stage.
>>>> Unfortunately I don't  know the name of the files that will be generated
>>>> before generation phase occurs.
>>>>
>>>> Therefore I can't use set_source_files_properties( foo.cxx PROPERTIES
>>>> GENERATED true) in cmake stage. Please drop a line if you know how to
>>>> bypass this limitation.
>>>>
>>>> Thanks, Tomasz.
>>>>
>>>> 2015-03-10 7:05 GMT+01:00 Mark Abraham <mark.j.abraham at gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> What are you generating that must be done at cmake time?
>>>>>
>>>>> Mark
>>>>> On 09/03/2015 5:36 pm, "Tomasz Majchrowski" <usenet at majchrowski.de>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm wondering if there is an easy way to control the dependencies in
>>>>>> the cmake stage. Basically I would like skip execution of some script run
>>>>>> over execute_process in case some input files didn't change.
>>>>>>
>>>>>> The regular way will be to use add_custom_command & add_custom_target
>>>>>> however those required targets, so the make stage.
>>>>>>
>>>>>> Please advice how to proceed in case there is need to control this
>>>>>> already in cmake stage?
>>>>>>
>>>>>> Thanks, Tomasz.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pozdrawiam/Best regards/Mit freundlichen Grüßen, Tomasz Majchrowski,
>>>>>> Information Technology and Services Consultant and Contractor
>>>>>>
>>>>>> --
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> --
>>>>>> Pozdrawiam/Best regards/Mit freundlichen Grüßen, Tomasz Majchrowski,
>>>>>> Information Technology and Services Consultant and Contractor
>>>>>>  <http://public.kitware.com/mailman/listinfo/cmake>
>>>>>
>>>>>
>>>
>>
>>
>> --
>> Pozdrawiam/Best regards/Mit freundlichen Grüßen, Tomasz Majchrowski,
>> Information Technology and Services Consultant and Contractor
>>
>> --
>> Pozdrawiam/Best regards/Mit freundlichen Grüßen, Tomasz Majchrowski,
>> Information Technology and Services Consultant and Contractor
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150319/b4fde8c7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GenChunk.tar
Type: application/x-tar
Size: 10240 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150319/b4fde8c7/attachment-0001.tar>