[CMake] Building a tool immediately so it can be used later in same CMake run

Craig Scott craig.scott at crascit.com
Thu Apr 14 08:17:20 EDT 2016


Sorry, forgot to follow up on this response. Re-using the same build
directory is a key part of the technique to avoid having to build the same
thing twice. So far, the only real problem I've seen is that the Xcode
generator is potentially less suited to this arrangement in that it seems
very hard to avoid building it twice even when using the same build
directory. It all still works, just not necessarily as efficiently as I
think it could. Haven't had time to delve deeper into the Xcode side yet to
investigate further.

The install targets option sounds like a good suggestion. I might play with
that in the coming months. Cheers.


On Sun, Apr 3, 2016 at 2:09 AM, Tamás Kenéz <tamas.kenez at gmail.com> wrote:

> Craig,
>
> I'm sorry for my previous answer which I wrote in haste. Now I've read
> your SO post and realized the question is a bit more complex then "is
> execute_process safe instead of ExternalProject".
>
> Anyway I still think your approach is basically correct. I have the
> following comments:
>
> - I wouldn't re-use the current build dir and would build mycomp always in
> it's own build dir. Also, I'd always use the plain default cmake generator
> (which is a must when crosscompiling anyway). No need to forward any
> settings to it from the superbuild. Also, I'd always build the Release
> config for mycomp.
>
> - You could "install(TARGETS mycomp DESTINATION bin)" in your EARLY_BUILD
> then later use "find_program(mycomp_EXECUTABLE mycomp ...) later to save
> guessing the executable's name.
>
> Tamas
>
> On Fri, Apr 1, 2016 at 9:25 PM, Tamás Kenéz <tamas.kenez at gmail.com> wrote:
>
>> Craig,
>>
>> My cmake-based build system in my company's CI framework works exactly
>> that way: there's a generic cmake script[1] (invoked with cmake -P) that
>> reads in a file which contains repo-urls and build parameters for 50+
>> projects and builds them for 3 platforms (linux, win, mac) 5 compilers
>> (cross-compilers, too) invoking child cmake builds with execute_process.
>> This is done after each push and one daily clean build.
>>
>> I've never had any problems with that approach.
>>
>> On the other hand, the system was originally designed with
>> ExternalProject and I had many problems.
>>
>> [1]: https://github.com/tamaskenez/centralbuilder
>>
>> Tamas
>>
>>
>>
>> On Fri, Apr 1, 2016 at 1:53 AM, Craig Scott <craig.scott at crascit.com>
>> wrote:
>>
>>> All,
>>>
>>> I originally planned to ask this question directly on this mailing list,
>>> but it got a bit more involved, so I posted it to stackoverflow instead.
>>> I'm interested if anyone can shed some more authoritative light on the
>>> proposed method for the following question:
>>>
>>> http://stackoverflow.com/q/36084785/1938798
>>>
>>> *Short version*: invoke a nested cmake-and-build immediately within the
>>> main CMake run to build a specific target via execute_process(). This makes
>>> that tool available for use still within the same (main) CMake run. An
>>> ExternalProject-based technique would normally be a better solution, but in
>>> this particular case, that wasn't possible.
>>>
>>> I'd be interested if anyone can confirm whether the suggested approach
>>> is guaranteed to be safe for all generators and platforms, or whether there
>>> are other factors I have not considered in the proposed technique.
>>>
>>> Cheers
>>>
>>> --
>>> Craig Scott
>>> Melbourne, Australia
>>> http://crascit.com
>>>
>>> --
>>>
>>> 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
>>>
>>
>>
>


-- 
Craig Scott
Melbourne, Australia
http://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160414/5bbcfd09/attachment-0001.html>


More information about the CMake mailing list