[CMake] Copying cmake generated files to another machine

[Michael Wild]

On 7. Dec, 2009, at 18:31 , steve naroff wrote:

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


Honestly, CMake is no big deal. You don't have to "install" CMake in  
the traditional sense (like in /usr/bin or /usr/local/bin, or  
wherever). You can either download a binary version from www.cmake.org  
or build one yourself, and just dump it into anyplace you like.

I could imagine that something like the following works for you:

- you distribute a pure source-tarball
- included are instructions (and possibly a script) to fetch a  
prebuilt CMake
   (if not installed already) and put it in a special place in the  
source tree
- use a script to drive CMake, possibly using the -C flag to  
initialize the cache

Once llvm/clang is built and installed, people can dispose of the  
binary tree and the source tree, removing all traces of CMake.

Michael