llvm dev - Jan 2009 - [LLVMdev] [cfe-dev] Testing and CMake

Hi Oscar,

For development, CMake is working great for me. I rarely get build  
errors related to the project file being out-of-date.

Is it true that CMake only generates absolute paths? Any idea on the  
difficulty of generating relative paths? I consider this a pretty big  
obstacle...

Thanks for all your hard work on this,

snaroff

On Jan 15, 2009, at 9:46 AM, Óscar Fuentes wrote:
> Douglas Gregor <dgregor at apple.com> writes:
>
>>>> Please, don't remove, I'm using!!!
>>>
>>> What's preventing you from using CMake?
>>>
>>> Is there some problem we can solve?
>>
>> At some point, we'll need to deal with the testing issue in the
CMake
>> build system. Clang, for example, uses some GNU make magic to run its
>> tests, which we'll need to replace with something more platform-
>> neutral in CMake.
>
> Testing was (is) the big roadblock for the LLVM CMake system. It is  
> not
> practical to duplicate the make-based system we have now, but I  
> think a
> good compromise can be achieved by invoking a script instead of
> `make'. The build could use this script for doing full testing, so
>
> "make all check"
>
> would keep working, although for partial testing the script would be
> mandatory. If this is not already working, is due to lack of time  
> here.
>
> OTOH, I haven't followed in detail all that discussion around a new
> testing framework (plus the introduction of C++ unit tests). I need to
> relearn was going on and see how that affects my plans.
>
>> That shouldn't prevent anyone who is using the current VS project
>> files from switching to CMake, though.
>
> Right. Current VS project files does not support testing at all.
>
> -- 
> Oscar
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

>
> Is it true that CMake only generates absolute paths? Any idea on the  
> difficulty of generating relative paths? I consider this a pretty big  
> obstacle...
>   
It is probably impossible, by design:

 From the CMake FAQ: http://www.cmake.org/Wiki/CMake_FAQ

Why does CMake use full paths, or can I copy my build tree?

CMake uses full paths because:
- configured header files may have full paths in them, and moving those 
files without re-configuring would cause upredictable behavior.
- because cmake supports out of source builds, if custom commands used 
relative paths to the source tree, they would not work when they are run 
in the build tree because the current directory would be incorrect.
- on Unix systems rpaths might be built into executables so they can 
find shared libraries at run time. If the build tree is moved old 
executables may use the old shared libraries, and not the new ones.

Can the build tree be copied or moved?
The short answer is NO. The reason is because full paths are used in 
CMake, see above. The main problem is that cmake would need to detect 
when the binary tree has been moved and rerun. Often when people want to 
move a binary tree it is so that they can distribute it to other users 
who may not have cmake in which case this would not work even if cmake 
would detect the move.
The workaround is to create a new build tree without copying or moving 
the old one.

Hi Steve,

On Thu, 15 Jan 2009, steve naroff wrote:
> For development, CMake is working great for me. I rarely get build
> errors related to the project file being out-of-date.
>
> Is it true that CMake only generates absolute paths? Any idea on the
> difficulty of generating relative paths? I consider this a pretty big
> obstacle...
I did not follow the full-thread, just reading this Email and I hope I'm 
getting it right:

We had the same problem (relative paths) and it turned out to be 
relatively (got the language joke here? ;)) easy, at least with cmake 2.6, 
in a local project.

set(CMAKE_USE_RELATIVE_PATHS ON)

It works well for vcproj-generation. In Linux I could not test it 
comprehensively yet (as to why it is possible to copy a repository and 
build it in its new place w/o re-cmaking.)

In addition we are setting

set(CMAKE_SUPPRESS_REGENERATION ON)

in order to not have a dependency on the CMakeLists when creating the 
vcproj-file.

HTH,
Patrick.

Patrick Boettcher <pb at linuxtv.org> writes:
>> For development, CMake is working great for me. I rarely get build
>> errors related to the project file being out-of-date.
>>
>> Is it true that CMake only generates absolute paths? Any idea on the
>> difficulty of generating relative paths? I consider this a pretty big
>> obstacle...
>
> I did not follow the full-thread, just reading this Email and I hope
I'm
> getting it right:
>
> We had the same problem (relative paths) and it turned out to be 
> relatively (got the language joke here? ;)) easy, at least with cmake 2.6, 
> in a local project.
>
> set(CMAKE_USE_RELATIVE_PATHS ON)
>
> It works well for vcproj-generation. In Linux I could not test it 
> comprehensively yet (as to why it is possible to copy a repository and 
> build it in its new place w/o re-cmaking.)
Hmmm...

  CMAKE_USE_RELATIVE_PATHS
       Use relative paths (May not work!).

       If this is set to TRUE, then the CMake will use relative paths between
       the source and binary tree.  This option does not work for more
       complicated projects, and relative paths are used when possible.  In
       general, it is not possible to move CMake generated makefiles to a
       different location regardless of the value of this variable.

> In addition we are setting
>
> set(CMAKE_SUPPRESS_REGENERATION ON)
>
> in order to not have a dependency on the CMakeLists when creating the 
> vcproj-file.
This looks like asking for trouble. Why are you doing this?

-- 
Oscar

Hello Steve.

steve naroff <snaroff at apple.com> writes:
> For development, CMake is working great for me. I rarely get build  
> errors related to the project file being out-of-date.
>
> Is it true that CMake only generates absolute paths? Any idea on the  
> difficulty of generating relative paths? I consider this a pretty big  
> obstacle...
Well, the fact that you didn't *still* noticed this limitation makes me
think that this is rarely needed :-)

Can you describe on which scenario do you require to move around build
trees?

-- 
Oscar

On Jan 15, 2009, at 11:40 AM, Óscar Fuentes wrote:
> Hello Steve.
>
> steve naroff <snaroff at apple.com> writes:
>
>> For development, CMake is working great for me. I rarely get build
>> errors related to the project file being out-of-date.
>>
>> Is it true that CMake only generates absolute paths? Any idea on the
>> difficulty of generating relative paths? I consider this a pretty big
>> obstacle...
>
> Well, the fact that you didn't *still* noticed this limitation makes  
> me
> think that this is rarely needed :-)
>
I haven't noticed it because I've been on the "development"
side
(where the absolute paths aren't a problem).
> Can you describe on which scenario do you require to move around build
> trees?
>
Sure...

As various clang features mature, we enter a "deployment" phase. As  
part of deployment, it is necessary to provide Apple's Build &  
Integration team a self-contained source tree that builds properly.  
This is where the rub is. It isn't appropriate to ask B&I engineers to  
use "cmake".

That said, I want to generate the VS solution files on my local  
machine and then copy them to a B&I machine and have everything "just  
work". For example:

snaroffBook% ls /Volumes/Data/WindowsShared/objc_translate-9/
llvm		vs2005-build

The VS solution files located in "vs2005-build" were built with the  
following command "cmake ../llvm". Since I am using a relative path on
the command line, I assumed it would use relative paths (my bad  
assumption).

Another point...I have no need to ever "move" the cmake generated  
build files away from the source tree. The source tree and the build  
tree will always move in lock step (which simplifies the problem I am  
looking to solve).

Thanks for any help with this,

snaroff
> -- 
> Oscar
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev