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 <snar...@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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
