Re: [CMake] Project being (unnecessarily) relinked

2007-09-13 Thread Dizzy
On Wednesday 12 September 2007 15:45:52 Bill Hoffman wrote:
 Jesper Eskilson wrote:
  Really you should be using full paths to libraries and not
  LINK_DIRECTORIES anyway.
 
 
  Why not? Is that a general advice about LINK_DIRECTORIES?

 Yes, if cmake knows the full path to the library it can handle it much
 better.
 If you just specify the name of the directory and the library cmake does
 not know anything about the library.  But the problem should be the
 opposite of the one you are having.  It should rebuild less than it should
 when link_directories is used.

Sorry to drop in but how portable is this? Right now I too have 
some convenience libraries (libraries made with add_library but never 
installed to gather some code and be used from various targets) and to have 
target_link_libraries() see them I set first link_directories() to their 
locations. I do this because I worry about the portability of full library 
paths. How do I know what is the full library name on any cmake platform? I 
supose on mingw/gcc it is always libname.a (for a add_library(name ...)) but 
probably with msvc there is another name for it (as add_library() does not 
specify the full name but the platform independent name that translates to 
libname.a and so on) and with target_link_libraries() not using full paths 
one also specifies the platform independent name of it (just 
target_link_libraries(target name) and not 
target_link_libraries(target /path/to/libname.a)).

What am I missing? :)

Thanks!

-- 
Mihai RUSU  Email: [EMAIL PROTECTED]
GPG : http://dizzy.roedu.net/dizzy-gpg.txt  WWW: http://dizzy.roedu.net
Linux is obsolete -- AST
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Project being (unnecessarily) relinked

2007-09-12 Thread Jesper Eskilson

Jesper Eskilson wrote:

Mike Jackson wrote:



On Sep 11, 2007, at 3:03 AM, Jesper Eskilson wrote:


A related question: if I include an external project in my solution
using

include_external_msproject(Bar ../../Bar/Bar.vcproj)

can I later refer to this project using

target_link_libraries(Foo Bar)

More generally, what is the correct way to specify that a CMake
target should be linked with some external library?


It is this last question I would like to get an answer to.



Say you have  another project that produces a library called 
libBar.dll and that library is located in C:\Libs then you can refer 
to that library in CMake directly. In other words, the cmake code you 
have is absolutely correct:


Target_link_Libraries(Foo Bar)

with the following caveat: libBar.dll MUST be in a known directory 
that the linker will look in. You can make sure of this by adding the 
following cmake code above the target_link_libraries code:


 LINK_DIRECTORIES (C:\Libs)


Ah. So if libBar.dll and libBar.lib are in different directories, *both* 
directories must be added using LINK_DIRECTORIES(), right?


That should be documented somewhere (if it is, I've managed to miss it).



After testing this, it appears that I still get the same relinking behavior.

In this particular case, the import lib and the dll actually have 
different names:


libfoo-1.lib
libfoo-1_5_1.dll

In case that would make a difference.

--
/Jesper

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


Re: [CMake] Project being (unnecessarily) relinked

2007-09-12 Thread Jesper Eskilson

Jesper Eskilson wrote:

Jesper Eskilson wrote:

Mike Jackson wrote:



On Sep 11, 2007, at 3:03 AM, Jesper Eskilson wrote:


A related question: if I include an external project in my solution
using

include_external_msproject(Bar ../../Bar/Bar.vcproj)

can I later refer to this project using

target_link_libraries(Foo Bar)

More generally, what is the correct way to specify that a CMake
target should be linked with some external library?


It is this last question I would like to get an answer to.



Say you have  another project that produces a library called 
libBar.dll and that library is located in C:\Libs then you can refer 
to that library in CMake directly. In other words, the cmake code you 
have is absolutely correct:


Target_link_Libraries(Foo Bar)

with the following caveat: libBar.dll MUST be in a known directory 
that the linker will look in. You can make sure of this by adding the 
following cmake code above the target_link_libraries code:


 LINK_DIRECTORIES (C:\Libs)


Ah. So if libBar.dll and libBar.lib are in different directories, 
*both* directories must be added using LINK_DIRECTORIES(), right?


That should be documented somewhere (if it is, I've managed to miss it).



After testing this, it appears that I still get the same relinking 
behavior.


Well, that turned out to be a little hasty conclusion.

In case of linking with a DLL, having paths to both the dll and import 
lib in LINK_DIRECTORIES avoids relinking. So far, so good.


However, I still get relinks due to a dependency on a static library. In 
this case, I'm unable to add the path using LINK_DIRECTORIES since the 
path is different depending on the configuration. I'm currently adding 
the path using the LINK_FLAGS_{DEBUG, ...} target property (which 
probably is the cause of the relinking).


So, I would like to be able to do something like, given the debug 
version of MyStaticLib.lib is in lib/win32/debug:


LINK_DIRECTORIES_DEBUG(lib/win32/debug)
TARGET_LINK_LIBRARIES(Foo MyStaticLib)

To make things more difficult, I cannot do something like:

LINK_DIRECTORIES(lib/win32/$(ConfigurationName))

because the configurations available for the static library 
(MyStaticLib.lib) do not map cleanly on the values for $(ConfigurationName).


frustration
Argh! Why can't things every be simple?!
/frustration

Any hints on how to solve this?

--
/Jesper

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


Re: [CMake] Project being (unnecessarily) relinked

2007-09-12 Thread Jack Kelly

Jesper Eskilson wrote

Well, that turned out to be a little hasty conclusion.

In case of linking with a DLL, having paths to both the dll and import 
lib in LINK_DIRECTORIES avoids relinking. So far, so good.


However, I still get relinks due to a dependency on a static library. In 
this case, I'm unable to add the path using LINK_DIRECTORIES since the 
path is different depending on the configuration. I'm currently adding 
the path using the LINK_FLAGS_{DEBUG, ...} target property (which 
probably is the cause of the relinking).


So, I would like to be able to do something like, given the debug 
version of MyStaticLib.lib is in lib/win32/debug:


LINK_DIRECTORIES_DEBUG(lib/win32/debug)
TARGET_LINK_LIBRARIES(Foo MyStaticLib)

To make things more difficult, I cannot do something like:

LINK_DIRECTORIES(lib/win32/$(ConfigurationName))

because the configurations available for the static library 
(MyStaticLib.lib) do not map cleanly on the values for 
$(ConfigurationName).


Is there any reason why

IF(${CMAKE_BUILD_TYPE} STREQUAL Debug)
  LINK_DIRECTORIES(/path/to/debug/lib)
ELSE(${CMAKE_BUILD_TYPE} STREQUAL Debug)
  LINK_DIRECTORIES(/path/to/release/lib)
ENDIF(${CMAKE_BUILD_TYPE} STREQUAL Debug)

won't work for you?

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


Re: [CMake] Project being (unnecessarily) relinked

2007-09-12 Thread Bill Hoffman

Jesper Eskilson wrote


Well, that turned out to be a little hasty conclusion.

In case of linking with a DLL, having paths to both the dll and import 
lib in LINK_DIRECTORIES avoids relinking. So far, so good.


However, I still get relinks due to a dependency on a static library. 
In this case, I'm unable to add the path using LINK_DIRECTORIES since 
the path is different depending on the configuration. I'm currently 
adding the path using the LINK_FLAGS_{DEBUG, ...} target property 
(which probably is the cause of the relinking).


Something is really strange here.  I don't understand how this could 
happen.   It would be really good at this
point if you could create a small example project that shows this 
problem and post it so I can take a look.
Really you should be using full paths to libraries and not 
LINK_DIRECTORIES anyway.


Something like this:
target_link_libraries(foo optimized /full/path/to/relbuild/bar.lib debug 
/full/path/to/debugbuild/bar.lib)


The odd part is that if you do not use full paths then it should never 
relink because of a library
changing.   Something else is different in your cmakelist file.  Again, 
please create a complete

example that shows the problem.


-Bill

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


Re: [CMake] Project being (unnecessarily) relinked

2007-09-10 Thread Jesper Eskilson
Jesper Eskilson wrote:
 Mathieu Malaterre wrote:
 On 9/4/07, Jesper Eskilson [EMAIL PROTECTED] wrote:
 Hi!

 I've got a Visual Studio 8 solution generated by CMake where one of the
 projects is always being relinked everytime I build it, even when
 nothing in it has changed (i.e. if I try to build it twice, it always
 relinks the project the second time).

 I've studied the build logs, but they do not make me any wiser.

 Does anyone recognize this behavior?


 wild guess
 Circular dependencie ?
 /wild guess

 I am not sure if outputing the depencie graph with graphiz could show
 that, since it only output high level dep (libs/executable)
 
 I think I've located the problem. The project in question uses
 target_link_library() in a possibly non-kosher way:
 
 target_link_library(Foo Bar.lib)
 
 That is, the top-level target Foo should include Bar.lib on its
 command line. This seems to work insofar that it actually performs the
 link correctly, but for some reason it always relinks as well.
 
 A related question: if I include an external project in my solution using
 
 include_external_msproject(Bar ../../Bar/Bar.vcproj)
 
 can I later refer to this project using
 
 target_link_libraries(Foo Bar)
 
 More generally, what is the correct way to specify that a CMake target
 should be linked with some external library?


I'm still very much interested in an answer to this question.

--
/Jesper


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


Re: [CMake] Project being (unnecessarily) relinked

2007-09-06 Thread Jesper Eskilson

Mathieu Malaterre wrote:

On 9/4/07, Jesper Eskilson [EMAIL PROTECTED] wrote:

Hi!

I've got a Visual Studio 8 solution generated by CMake where one of the
projects is always being relinked everytime I build it, even when
nothing in it has changed (i.e. if I try to build it twice, it always
relinks the project the second time).

I've studied the build logs, but they do not make me any wiser.

Does anyone recognize this behavior?



wild guess
Circular dependencie ?
/wild guess

I am not sure if outputing the depencie graph with graphiz could show
that, since it only output high level dep (libs/executable)


I think I've located the problem. The project in question uses 
target_link_library() in a possibly non-kosher way:


target_link_library(Foo Bar.lib)

That is, the top-level target Foo should include Bar.lib on its 
command line. This seems to work insofar that it actually performs the 
link correctly, but for some reason it always relinks as well.


A related question: if I include an external project in my solution using

include_external_msproject(Bar ../../Bar/Bar.vcproj)

can I later refer to this project using

target_link_libraries(Foo Bar)

More generally, what is the correct way to specify that a CMake target 
should be linked with some external library?


--
/Jesper

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


Re: [CMake] Project being (unnecessarily) relinked

2007-09-05 Thread Mathieu Malaterre
On 9/4/07, Dizzy [EMAIL PROTECTED] wrote:
 On Tuesday 04 September 2007 17:28:31 Jesper Eskilson wrote:
  Hi!
 
  I've got a Visual Studio 8 solution generated by CMake where one of the
  projects is always being relinked everytime I build it, even when
  nothing in it has changed (i.e. if I try to build it twice, it always
  relinks the project the second time).
 
  I've studied the build logs, but they do not make me any wiser.
 
  Does anyone recognize this behavior?

 I have a similar problem but with Unix makefiles when I do make install it
 relinks everything again and then installs. But because it doesnt relink on a
 second make install I think the issues are separate.

IMHO this is because you are building with RPATH on. Thus when
installing shared libs, cmake need to make sure to remove those path
from your libs.
This is clearly not a bug, but one very good (if not the best) feature of CMake.

2 cents,
-- 
Mathieu
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Project being (unnecessarily) relinked

2007-09-05 Thread Mathieu Malaterre
On 9/4/07, Jesper Eskilson [EMAIL PROTECTED] wrote:

 Hi!

 I've got a Visual Studio 8 solution generated by CMake where one of the
 projects is always being relinked everytime I build it, even when
 nothing in it has changed (i.e. if I try to build it twice, it always
 relinks the project the second time).

 I've studied the build logs, but they do not make me any wiser.

 Does anyone recognize this behavior?


wild guess
Circular dependencie ?
/wild guess

I am not sure if outputing the depencie graph with graphiz could show
that, since it only output high level dep (libs/executable)

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


Re: [CMake] Project being (unnecessarily) relinked

2007-09-05 Thread Jack Kelly

Mathieu Malaterre wrote:

On 9/4/07, Jesper Eskilson [EMAIL PROTECTED] wrote:

Hi!

I've got a Visual Studio 8 solution generated by CMake where one of the
projects is always being relinked everytime I build it, even when
nothing in it has changed (i.e. if I try to build it twice, it always
relinks the project the second time).

I've studied the build logs, but they do not make me any wiser.

Does anyone recognize this behavior?


Could it be something to do with RPATH? Try building with 
CMAKE_SKIP_RPATH ON set in the cache. My guess would be that because you 
don't know where all the libs are until install time, you have to do a 
relink to ensure that the RPATH is being set correctly.


(Someone please correct me if I'm wrong.)

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


[CMake] Project being (unnecessarily) relinked

2007-09-04 Thread Jesper Eskilson

Hi!

I've got a Visual Studio 8 solution generated by CMake where one of the
projects is always being relinked everytime I build it, even when
nothing in it has changed (i.e. if I try to build it twice, it always
relinks the project the second time).

I've studied the build logs, but they do not make me any wiser.

Does anyone recognize this behavior?

-- 
/Jesper

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


Re: [CMake] Project being (unnecessarily) relinked

2007-09-04 Thread Dizzy
On Tuesday 04 September 2007 17:28:31 Jesper Eskilson wrote:
 Hi!

 I've got a Visual Studio 8 solution generated by CMake where one of the
 projects is always being relinked everytime I build it, even when
 nothing in it has changed (i.e. if I try to build it twice, it always
 relinks the project the second time).

 I've studied the build logs, but they do not make me any wiser.

 Does anyone recognize this behavior?

I have a similar problem but with Unix makefiles when I do make install it 
relinks everything again and then installs. But because it doesnt relink on a 
second make install I think the issues are separate.

-- 
Mihai RUSU  Email: [EMAIL PROTECTED]
Linux is obsolete -- AST
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake