[CMake] Copying cmake generated files to another machine

Eric Noulard eric.noulard at gmail.com
Mon Dec 7 09:17:27 EST 2009


2009/12/7 steve naroff <snaroff at apple.com>:
>> As Eric pointed out, you must add CMake to your compiler build chain.
>> It's one more tool (and with no third-party dependencies), like the C
>> preprocessor, the C compiler and the linker. We did that at work and
>> it's no big deal, people are so happy with the pro's of CMake over our
>> former buildsystem (Visual C++ projects for Windows and Makefiles for
>> Unix, which required twice the amount of maintainance work), they are
>> not looking back.
>>
>
> As I said in my initial post, we love CMake for development (since
> llvm/clang are cross platform). Developers understand the benefits of
> 'cmake'. Unfortunately, developers aren't the only clients building
> llvm/clang.

Could you explain that part?
Who else is building LLVM/clang besides developers?
And what are the reason they give for not wanting to install CMake
with their compiler?

<half-joke-mode>
May be the solution would be to propose the compiler vendor to include
CMake in its product, that way they would get CMake "out-of-the-box" :-)
<half-joke-mode/>

> In any event, maybe adding CMake to our build chain isn't such a big deal.
>
> Just trying to get the collective wisdom of this group before we make any
> changes.

Like Pau said I think that if CMake developer (like Bill) do advise
to give up "relative path" they must be thinking that with good reason.

You are right too, the range of cross-portability targeted by CMake
and by llvm/clang may not be the same, and "may be" you can constrain yourself
with a subset of CMake current features which makes it possible to do
what you want:
no CMake use after first generation, only relative path.

After that, the question is, is the seeked goal worth the [CMake]
feature you loose?


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org


More information about the CMake mailing list