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

Tamás Kenéz tamas.kenez at gmail.com
Sat Apr 2 11:09:06 EDT 2016


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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160402/d97015dc/attachment.html>


More information about the CMake mailing list