[CMake] Copying cmake generated files to another machine

steve naroff snaroff at apple.com
Mon Dec 7 12:31:45 EST 2009


On Dec 7, 2009, at 9:17 AM, Eric Noulard wrote:

> 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?
>

Hi Eric,

With all due respect, I'd like to avoid any explanation. You'll just  
have to trust me on this - llvm/clang is being deployed within  
organizations that don't have cmake installed (and don't want to add  
it to their list of dependencies).

 From my perspective, not being able to use relative paths just seems  
'broken'. The reason for this limitation is totally unclear to someone  
like me (who is an 'end user' of cmake). I'd love to hear a thoughtful  
list of reasons why relative paths are so hard for cmake to cope with  
(from one of the lead developers, if possible). If I understood more  
of the technical rationale, I'd likely be more sympathetic to the  
limitation (and apparent desire to deprecate the feature entirely).

Thanks for your engagement on this topic,

snaroff

> <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