Re: [CMake] Link directories order

[Renaud Detry]

On 08 Nov 2007, at 17:52, Bill Hoffman wrote:


Renaud Detry wrote:
You should be using FIND_LIBRARY to find the things you want to  
link in, or at least finding the directory with a FIND_FILE,  
and then using LINK_DIRECTORIES. LDFLAGS is a bad idea because  
your users will also have to set this to get it to work.
I don't really agree here. Users can decide to install in a  
standard

directory (e.g. /usr/local is standard for headers and libs in many
linux distros) and it will work right away. Or users can choose to
install in a non-standard directory like $HOME/usr, and it's their
responsibility to keep their CPPFLAGS & LDFLAGS up to date.
The FIND_* primitives are neat when used with a restricted scope
(cf. CMAKE_LIBRARY_PATH), and I'm ok with keeping the env vars
CMAKE_*_PATH up-to-date. However, I need to keep link dirs in  
LDFLAGS
anyway because that's what other build systems expect. The point  
is,

IMHO CMake should:
- Either *ignore* LDFLAGS, and optionally get linker flags other  
than

  -L from an env var like CMAKE_LINK_FLAGS;
- Either use LDFLAGS, but parse it with respect its content.
For this reason, I think I should report this issue as a bug rather
than a feature request.
Ok, create a bug report.  It still is not the CMake way of doing  
things. CMake should be told the full path to libraries you want  
to use.  That way it knows exactly what you are trying to do.   
Parsing compiler specific flags out of LDFLAGS to add path  
information was not what I had in mind when I used LDFLAGS.   
Perhaps I should not have used it at all, or used a different  
variable.  When I added the ability to use LDFLAGS, I think I was  
adding support for 64 bit IRIX builds, needed -64 as a linker  
flag.  Although at this point, I can not remove it because of  
backwards compatibility, so I guess I am stuck with parsing it  
for -L.  But, if you want your stuff to work with a release  
cmake, you might want to consider doing something different.

Ok, I'm sure I'll find a way. CMake is a great tool anyway, thanks!


Thanks, for the good attitude!  :)

You did bring up a use case that I had not anticipated.  If you  
could create a bug report, it would be a good idea to at least look  
for -L in the linker flags in my order directory stuff.   Someone  
could just as easily added a -L flag via CMAKE_LINKER_FLAGS or some  
other cmake variable that ends up in the link line.


Ok, I'll look into that, next week.

Cheers,
Renaud.


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Link directories order

[Renaud Detry]

OK, CMake does not know what you are doing here.  It is treating  
LDFLAGS like some linker flag.  The idea was something like -64  
or some other linker specific flag for a platform.

Ok.
If you inject directories into the link line, you are sort of out  
of luck.  Why are you doing it this way?

What other way could I do it?
- There's no official definition of what should be found in LDFLAGS,
  but most of the software that use LDFLAGS (in particular autotools)
  expect you to put non-standard link directories in there.
You should be using FIND_LIBRARY to find the things you want to  
link in, or at least finding the directory with a FIND_FILE, and  
then using LINK_DIRECTORIES. LDFLAGS is a bad idea because your  
users will also have to set this to get it to work.


I don't really agree here. Users can decide to install in a standard
directory (e.g. /usr/local is standard for headers and libs in many
linux distros) and it will work right away. Or users can choose to
install in a non-standard directory like $HOME/usr, and it's their
responsibility to keep their CPPFLAGS & LDFLAGS up to date.

The FIND_* primitives are neat when used with a restricted scope
(cf. CMAKE_LIBRARY_PATH), and I'm ok with keeping the env vars
CMAKE_*_PATH up-to-date. However, I need to keep link dirs in LDFLAGS
anyway because that's what other build systems expect. The point is,
IMHO CMake should:

- Either *ignore* LDFLAGS, and optionally get linker flags other than
  -L from an env var like CMAKE_LINK_FLAGS;

- Either use LDFLAGS, but parse it with respect its content.

For this reason, I think I should report this issue as a bug rather
than a feature request.


Renaud.

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking problem

[Renaud Detry]

On 07 Nov 2007, at 11:35, Salvatore Iovene wrote:


On 11/7/07, Renaud Detry <[EMAIL PROTECTED]> wrote:


On 07 Nov 2007, at 11:04, Salvatore Iovene wrote:


On 11/7/07, Renaud Detry <[EMAIL PROTECTED]> wrote:


On 07 Nov 2007, at 09:59, Salvatore Iovene wrote:


On 11/7/07, Brandon Van Every <[EMAIL PROTECTED]> wrote:

On Nov 7, 2007 2:12 AM, Salvatore Iovene
<[EMAIL PROTECTED]> wrote:

Hi,
I'm not 100% sure this is really a CMake related question, but
I'll
fire it up anyway:

I'm building a series of static libraries, name them liba.a,
libb.a
and libc.a, and linking them into a shared library libfoo.so.

Then I'm building libx.a liby.a and libz.a and linking them
into the
shared libbar.so.

Then I have an executable whatever.exe that's linked to to
libfoo.so
and libbar.so. The linking of the executable fails  
complaining of

certain missing simbols. Some symbols from liba.a are missing in
libbar.so.


Let's say that there's a symbol S in liba.a, that S is the only
symbol
in its object, and that S is not used by libfoo. In Darwin, S will
not
be included in libfoo, and the result you get is expectable. I  
don't

know if this simple explanation translates to Linux.


I don't know either, but that seems to be the case. Any ideas on
how to fix it?


IMHO, you shouldn't use symbols from liba in libbar if libbar doesn't
link against liba.

I think you could do either of

1.- make all your static libs dynamic, and link libbar against  
liba if

 libbar uses symbols from liba.

2.- link neither libfoo nor libbar to liba, but link whatever.exe to
 liba. This will require an extra flag about undefined symbols
 under Darwin, but I don't think ld will complain under Linux.

Option (1) seems far nicer to me.

Hope this helps.
Renaud.


Thanks. Your options seem very reasonable. The thing is, though, that
the various liba, libb, libc were meant to be only used to build a
bigger library called libfoo.


Then why don't you build all objects from foo, a, b, c to be PIC and
pack them all together in foo? Or if you really want intermediate
archives, maybe you can build the objects of a, b, c to be PIC,
archive them in .a archives, and use ld to put them together. But this
is not the same thing as linking foo to a, b, c using gcc and -la -lb
-lc, which means to only fetch needed symbols.

The bottom line is, what you mean to do is probably not very common,
and I don't think there will be a high-level CMake primitive that will
do that for you.

This is just my opinion though :-)

Renaud.

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking problem

[Renaud Detry]

On 07 Nov 2007, at 11:04, Salvatore Iovene wrote:


On 11/7/07, Renaud Detry <[EMAIL PROTECTED]> wrote:


On 07 Nov 2007, at 09:59, Salvatore Iovene wrote:


On 11/7/07, Brandon Van Every <[EMAIL PROTECTED]> wrote:

On Nov 7, 2007 2:12 AM, Salvatore Iovene
<[EMAIL PROTECTED]> wrote:

Hi,
I'm not 100% sure this is really a CMake related question, but  
I'll

fire it up anyway:

I'm building a series of static libraries, name them liba.a,  
libb.a

and libc.a, and linking them into a shared library libfoo.so.

Then I'm building libx.a liby.a and libz.a and linking them  
into the

shared libbar.so.

Then I have an executable whatever.exe that's linked to to  
libfoo.so

and libbar.so. The linking of the executable fails complaining of
certain missing simbols. Some symbols from liba.a are missing in
libbar.so.


Let's say that there's a symbol S in liba.a, that S is the only  
symbol
in its object, and that S is not used by libfoo. In Darwin, S will  
not

be included in libfoo, and the result you get is expectable. I don't
know if this simple explanation translates to Linux.


I don't know either, but that seems to be the case. Any ideas on  
how to fix it?


IMHO, you shouldn't use symbols from liba in libbar if libbar doesn't
link against liba.

I think you could do either of

1.- make all your static libs dynamic, and link libbar against liba if
libbar uses symbols from liba.

2.- link neither libfoo nor libbar to liba, but link whatever.exe to
liba. This will require an extra flag about undefined symbols
under Darwin, but I don't think ld will complain under Linux.

Option (1) seems far nicer to me.

Hope this helps.
Renaud.

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking problem

[Renaud Detry]

On 07 Nov 2007, at 09:59, Salvatore Iovene wrote:


On 11/7/07, Brandon Van Every <[EMAIL PROTECTED]> wrote:

On Nov 7, 2007 2:12 AM, Salvatore Iovene
<[EMAIL PROTECTED]> wrote:

Hi,
I'm not 100% sure this is really a CMake related question, but I'll
fire it up anyway:

I'm building a series of static libraries, name them liba.a, libb.a
and libc.a, and linking them into a shared library libfoo.so.

Then I'm building libx.a liby.a and libz.a and linking them into the
shared libbar.so.

Then I have an executable whatever.exe that's linked to to libfoo.so
and libbar.so. The linking of the executable fails complaining of
certain missing simbols. Some symbols from liba.a are missing in
libbar.so.


Let's say that there's a symbol S in liba.a, that S is the only symbol
in its object, and that S is not used by libfoo. In Darwin, S will not
be included in libfoo, and the result you get is expectable. I don't
know if this simple explanation translates to Linux.

Renaud.



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Link directories order

[Renaud Detry]

OK, CMake does not know what you are doing here.  It is treating  
LDFLAGS like some linker flag.  The idea was something like -64 or  
some other linker specific flag for a platform.


Ok.

If you inject directories into the link line, you are sort of out  
of luck.  Why are you doing it this way?


What other way could I do it?

- There's no official definition of what should be found in LDFLAGS,
  but most of the software that use LDFLAGS (in particular autotools)
  expect you to put non-standard link directories in there.

- Isn't it the most standard way (in unix) to tell a build system to  
look

  for libraries in non-standard places?

Renaud.

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Link directories order

[Renaud Detry]

Renaud Detry wrote:

Did you build it using ADD_LIBRARY?
If yes:
PROJECT(HELLO)
ADD_LIBRARY(Hello foo.c)
ADD_EXECUTABLE(HelloBin bar.c)
TARGET_LINK_LIBRARIES(HelloBin Hello)

This is exactly what I have.
ADD_LIBRARY defines the TARGET "Hello" in the above lines. That  
should link to the local libHello even if you have another  
version in the system.

This is what I thought, too. Unfortunately it doesn't.


This sounds like a bug.   Can you send the output of make VERBOSE=1?


Here's the term output (at the end), and a word about the build context:

[...]

I understand cmake smart-orders link directory flags. However, flags
coming from the shell env LDFLAGS don't seem to be taken into account
in this smart sort.

To illustrate the issue, I slightly modified the example code from

  http://www.cmake.org/HTML/cmakeExample.tar.gz

The only change is in

  cmakeExample.tar.gz:CMakeExample/Hello/CMakeLists.txt

which becomes

# Create a library called "Hello" which includes the source file  
"hello.cxx".
# The extension is already found.  Any number of sources could be  
listed here.

add_library (Hello hello.cxx)

INSTALL(TARGETS Hello
RUNTIME DESTINATION bin
ARCHIVE DESTINATION lib
LIBRARY DESTINATION lib)

As one can see in the attached terminal output, the linker for Demo
looks in /tmp/lib before looking in the build dir:

  /usr/bin/c++ -headerpad_max_install_names -fPIC -L/tmp/lib
  "CMakeFiles/helloDemo.dir/demo.o"
  "CMakeFiles/helloDemo.dir/demo_b.o" -o helloDemo
  -L/Volumes/Data/Users/detryr/tmp/CMakeExample/Hello -lHello

As a result, Demo is linked against an obsolete installed version of
Hello, instead of the local fresh one.

Note that /tmp/lib was empty when I ran cmake.

[EMAIL PROTECTED] $ export LDFLAGS=-L/tmp/lib   [~/tmp/ 
CMakeExample]
[EMAIL PROTECTED] $ rm /tmp/lib/libHello.a  [~/tmp/ 
CMakeExample]

rm: /tmp/lib/libHello.a: No such file or directory
[EMAIL PROTECTED] $ cmake -DCMAKE_INSTALL_PREFIX=/tmp   [~/tmp/ 
CMakeExample]

-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Check size of void*
-- Check size of void* - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Configuring done
-- Generating done
-- Build files have been written to: /Volumes/Data/Users/detryr/tmp/ 
CMakeExample
[EMAIL PROTECTED] $ make VERBOSE=1  [~/tmp/ 
CMakeExample]
/usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -H/Volumes/Data/ 
Users/detryr/tmp/CMakeExample -B/Volumes/Data/Users/detryr/tmp/ 
CMakeExample --check-build-system CMakeFiles/Makefile.cmake 0

Clearing dependencies in "Hello/CMakeFiles/Hello.dir/depend.make".
Clearing dependencies in "Hello/CMakeFiles/Hello.dir/depend.internal".
Clearing dependencies in "Demo/CMakeFiles/helloDemo.dir/depend.make".
Clearing dependencies in "Demo/CMakeFiles/helloDemo.dir/ 
depend.internal".
/usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -E  
cmake_progress_start /Volumes/Data/Users/detryr/tmp/CMakeExample/ 
CMakeFiles 3

make -f CMakeFiles/Makefile2 all
make -f Hello/CMakeFiles/Hello.dir/build.make Hello/CMakeFiles/ 
Hello.dir/depend

Scanning dependencies of target Hello
cd /Volumes/Data/Users/detryr/tmp/CMakeExample && /usr/local/ 
cmake-2.4.7-Darwin-universal/bin/cmake -E cmake_depends "Unix  
Makefiles" /Volumes/Data/Users/detryr/tmp/CMakeExample /Volumes/Data/ 
Users/detryr/tmp/CMakeExample/Hello /Volumes/Data/Users/detryr/tmp/ 
CMakeExample /Volumes/Data/Users/detryr/tmp/CMakeExample/Hello / 
Volumes/Data/Users/detryr/tmp/CMakeExample/Hello/CMakeFiles/Hello.dir/ 
DependInfo.cmake
make -f Hello/CMakeFiles/Hello.dir/build.make Hello/CMakeFiles/ 
Hello.dir/build
/usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -E  
cmake_progress_report /Volumes/Data/Users/detryr/tmp/CMakeExample/ 
CMakeFiles 1

[ 33%] Building CXX object Hello/CMakeFiles/Hello.dir/hello.o
/usr/bin/c++-o Hello/CMakeFiles/Hello.dir/hello.o -c /Volumes/ 
Data/Users/detryr/tmp/CMakeExample/Hello/hello.cxx

Linking CXX static library libHello.a
cd /Volumes/Data/Users/detryr/tmp/CMakeExample/Hello && /usr/local/ 
cmake-2.4.7-Darwin-universal/bin/cmake -P CMakeFiles/Hello.dir/ 
cmake_clean_target.cmake
cd /Volumes/Data/Users/detryr/tmp/CMakeExample/Hello && /usr/local/ 
cmake-2.4.7-Darwin-universal/bin/cmake -E cmake_link_script  
CMakeFiles/Hello.dir/link.txt --verbose=1

/usr/bin/ar cr libHello.a  "CMakeFiles/Hello.dir/hello.o"
/usr/bin/ranlib libHello.a
/usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -E  
cmake_progress_report /Volumes/Data/Users/detryr/tmp/CMakeExample/ 
CMakeFiles  1

[ 33%] Built target Hello
make -f Demo/CMakeFiles/helloDemo.dir/build.make Demo/CMakeFiles/ 
helloDemo.dir/depend

Scanning dependencies of target helloDemo
cd /Volumes/Dat

Re: [CMake] Link directories order

[Renaud Detry]

Did you build it using ADD_LIBRARY?
If yes:
PROJECT(HELLO)
ADD_LIBRARY(Hello foo.c)
ADD_EXECUTABLE(HelloBin bar.c)
TARGET_LINK_LIBRARIES(HelloBin Hello)


This is exactly what I have.

ADD_LIBRARY defines the TARGET "Hello" in the above lines. That  
should link to the local libHello even if you have another version  
in the system.


This is what I thought, too. Unfortunately it doesn't.

Renaud.



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Link directories order

[Renaud Detry]

Did you try to give the whole path to the lib instead of seperate  
library name and path?


Can that be done without writing the lib suffix explicitly (not cross- 
platform)?


And since you build the lib yourself with a cmake TARGET, the  
TARGET name should be used as link dependency.


I don't see what you mean, could you make this explicit please?

Does this have something to do with the INSTALL statement? If not, it
is the online example that should be changed.

OTOH: why do you shoot yourself in the foot and define linker flags  
that do not express what you actually want?


I defined linker flags that express what I want. I have software
installed in non-standard directories like /sw/lib and /usr/local/lib,
and I do want CMake to look there (cf. LDFLAGS). However, I want CMake
to look in the local directory *first* to link the executable
helloDemo against the lib Hello that has just been built.

Thanks for your help,

Renaud.

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Link directories order

[Renaud Detry]

Hi all,

I posted an issue about link dir order a week ago, but it seems nobody
has replied to it :-/ Is there a reason like "one should not use env
var, but FindXXX scripts instead", or did it simply slip through
unnoticed?

The initial post follows.

Thanks,
Renaud.


Hello,

I'm having trouble with cmake LINK_DIRECTORIES order. I understand
cmake smart-orders link directory flags. However, flags coming from
the shell env LDFLAGS don't seem to be taken into account in this
smart sort. Is this a feature or a bug?

To illustrate the issue, I slightly modified the example code from

  http://www.cmake.org/HTML/cmakeExample.tar.gz

The only change is in

  cmakeExample.tar.gz:CMakeExample/Hello/CMakeLists.txt

which becomes

# Create a library called "Hello" which includes the source file  
"hello.cxx".
# The extension is already found.  Any number of sources could be  
listed here.

add_library (Hello hello.cxx)

INSTALL(TARGETS Hello
RUNTIME DESTINATION bin
ARCHIVE DESTINATION lib
LIBRARY DESTINATION lib)

As one can see in the attached terminal output, the linker for Demo
looks in /tmp/lib before looking in the build dir:

  /usr/bin/c++ -headerpad_max_install_names -fPIC -L/tmp/lib
  "CMakeFiles/helloDemo.dir/demo.o"
  "CMakeFiles/helloDemo.dir/demo_b.o" -o helloDemo
  -L/Volumes/Data/Users/detryr/tmp/CMakeExample/Hello -lHello

As a result, Demo is linked against an obsolete installed version of
Hello, instead of the local fresh one.

Here's the terminal output (note that /tmp/lib was empty when I ran  
cmake):


[EMAIL PROTECTED] $ export LDFLAGS=-L/tmp/lib   [~/tmp/ 
CMakeExample]
[EMAIL PROTECTED] $ rm /tmp/lib/libHello.a  [~/tmp/ 
CMakeExample]

rm: /tmp/lib/libHello.a: No such file or directory
[EMAIL PROTECTED] $ cmake -DCMAKE_INSTALL_PREFIX=/tmp   [~/tmp/ 
CMakeExample]

  [...]
[EMAIL PROTECTED] $ make VERBOSE=1  [~/tmp/ 
CMakeExample]

  [...]
cd /Volumes/Data/Users/detryr/tmp/CMakeExample/Demo && /usr/bin/c+ 
+ -headerpad_max_install_names -fPIC -L/tmp/lib "CMakeFiles/ 
helloDemo.dir/demo.o" "CMakeFiles/helloDemo.dir/demo_b.o"   -o  
helloDemo  -L/Volumes/Data/Users/detryr/tmp/CMakeExample/Hello -lHello

  [...]

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPPFLAGS

[Renaud Detry]

Hello,

CMake takes many variables from the shell env (CC, CXX, CFLAGS,
CXXFLAGS, LDFLAGS, ...) but CPPFLAGS seems to be ignored, forcing
-I in CFLAGS/CXXFLAGS. I'm using
cmake-2.4.7-Darwin-universal. Is this intentional?

Thanks,
Renaud.

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Link directories order

[Renaud Detry]

Hello,

I'm having trouble with cmake LINK_DIRECTORIES order. I understand
cmake smart-orders link directory flags. However, flags coming from
the shell env LDFLAGS don't seem to be taken into account in this
smart sort. Is this a feature or a bug?

To illustrate the issue, I slightly modified the example code from

  http://www.cmake.org/HTML/cmakeExample.tar.gz

The only change is in

  cmakeExample.tar.gz:CMakeExample/Hello/CMakeLists.txt

which becomes

# Create a library called "Hello" which includes the source file  
"hello.cxx".
# The extension is already found.  Any number of sources could be  
listed here.

add_library (Hello hello.cxx)

INSTALL(TARGETS Hello
RUNTIME DESTINATION bin
ARCHIVE DESTINATION lib
LIBRARY DESTINATION lib)

As one can see in the attached terminal output, the linker for Demo
looks in /tmp/lib before looking in the build dir:

  /usr/bin/c++ -headerpad_max_install_names -fPIC -L/tmp/lib
  "CMakeFiles/helloDemo.dir/demo.o"
  "CMakeFiles/helloDemo.dir/demo_b.o" -o helloDemo
  -L/Volumes/Data/Users/detryr/tmp/CMakeExample/Hello -lHello

As a result, Demo is linked against an obsolete installed version of
Hello, instead of the local fresh one.

Note that /tmp/lib was empty when I ran cmake.

Cheers,
Renaud.



[EMAIL PROTECTED] $ export LDFLAGS=-L/tmp/lib   [~/tmp/ 
CMakeExample]
[EMAIL PROTECTED] $ rm /tmp/lib/libHello.a  [~/tmp/ 
CMakeExample]

rm: /tmp/lib/libHello.a: No such file or directory
[EMAIL PROTECTED] $ cmake -DCMAKE_INSTALL_PREFIX=/tmp   [~/tmp/ 
CMakeExample]

-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Check size of void*
-- Check size of void* - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Configuring done
-- Generating done
-- Build files have been written to: /Volumes/Data/Users/detryr/tmp/ 
CMakeExample
[EMAIL PROTECTED] $ make VERBOSE=1  [~/tmp/ 
CMakeExample]
/usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -H/Volumes/Data/ 
Users/detryr/tmp/CMakeExample -B/Volumes/Data/Users/detryr/tmp/ 
CMakeExample --check-build-system CMakeFiles/Makefile.cmake 0

Clearing dependencies in "Hello/CMakeFiles/Hello.dir/depend.make".
Clearing dependencies in "Hello/CMakeFiles/Hello.dir/depend.internal".
Clearing dependencies in "Demo/CMakeFiles/helloDemo.dir/depend.make".
Clearing dependencies in "Demo/CMakeFiles/helloDemo.dir/ 
depend.internal".
/usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -E  
cmake_progress_start /Volumes/Data/Users/detryr/tmp/CMakeExample/ 
CMakeFiles 3

make -f CMakeFiles/Makefile2 all
make -f Hello/CMakeFiles/Hello.dir/build.make Hello/CMakeFiles/ 
Hello.dir/depend

Scanning dependencies of target Hello
cd /Volumes/Data/Users/detryr/tmp/CMakeExample && /usr/local/ 
cmake-2.4.7-Darwin-universal/bin/cmake -E cmake_depends "Unix  
Makefiles" /Volumes/Data/Users/detryr/tmp/CMakeExample /Volumes/Data/ 
Users/detryr/tmp/CMakeExample/Hello /Volumes/Data/Users/detryr/tmp/ 
CMakeExample /Volumes/Data/Users/detryr/tmp/CMakeExample/Hello / 
Volumes/Data/Users/detryr/tmp/CMakeExample/Hello/CMakeFiles/Hello.dir/ 
DependInfo.cmake
make -f Hello/CMakeFiles/Hello.dir/build.make Hello/CMakeFiles/ 
Hello.dir/build
/usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -E  
cmake_progress_report /Volumes/Data/Users/detryr/tmp/CMakeExample/ 
CMakeFiles 1

[ 33%] Building CXX object Hello/CMakeFiles/Hello.dir/hello.o
/usr/bin/c++-o Hello/CMakeFiles/Hello.dir/hello.o -c /Volumes/ 
Data/Users/detryr/tmp/CMakeExample/Hello/hello.cxx

Linking CXX static library libHello.a
cd /Volumes/Data/Users/detryr/tmp/CMakeExample/Hello && /usr/local/ 
cmake-2.4.7-Darwin-universal/bin/cmake -P CMakeFiles/Hello.dir/ 
cmake_clean_target.cmake
cd /Volumes/Data/Users/detryr/tmp/CMakeExample/Hello && /usr/local/ 
cmake-2.4.7-Darwin-universal/bin/cmake -E cmake_link_script  
CMakeFiles/Hello.dir/link.txt --verbose=1

/usr/bin/ar cr libHello.a  "CMakeFiles/Hello.dir/hello.o"
/usr/bin/ranlib libHello.a
/usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -E  
cmake_progress_report /Volumes/Data/Users/detryr/tmp/CMakeExample/ 
CMakeFiles  1

[ 33%] Built target Hello
make -f Demo/CMakeFiles/helloDemo.dir/build.make Demo/CMakeFiles/ 
helloDemo.dir/depend

Scanning dependencies of target helloDemo
cd /Volumes/Data/Users/detryr/tmp/CMakeExample && /usr/local/ 
cmake-2.4.7-Darwin-universal/bin/cmake -E cmake_depends "Unix  
Makefiles" /Volumes/Data/Users/detryr/tmp/CMakeExample /Volumes/Data/ 
Users/detryr/tmp/CMakeExample/Demo /Volumes/Data/Users/detryr/tmp/ 
CMakeExample /Volumes/Data/Users/detryr/tmp/CMakeExample/Demo / 
Volumes/Data/Users/detryr/tmp/CMakeExample/Demo/CMakeFiles/ 
helloDemo.dir/DependInfo.cmake
make -f Demo/CMakeFiles/helloDemo.dir/build.make Demo/CMakeFiles/ 
helloDemo.dir/build
/usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -E  
cmake_progress_report /Volumes/Data/Users/detryr/tmp/CMake