Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake

[Michael Hertling]

On 11/12/2011 01:39 PM, David Cole wrote:
> For reference, the bug Mike refers to is this one:
> 
>   http://public.kitware.com/Bug/view.php?id=11258
> 
> I always use the manual technique of shutting down VS, running CMake,
> and then re-opening VS. It's really not that bad, once you get used to
> it.
> 
> 
> David C.

Is it possibly an alternative to use "cmake --build" within an already
configured build tree, provided the VS IDE is not strictly necessary?
E.g., when porting a project from *nix to Windows, I usually open the
VS shell, run CMake on the project's source tree from within a build
directory and finally "cmake --build .". For last-minute changes, I
use the editor of my choice and invoke "cmake --build ." again.

With Makefiles on *nix, this approach works as expected, but with VS,
I noticed the following issue: The project is correctly rebuilt after
a change in a source file, but a change in a CMakeLists.txt file only
results in a regeneration of the solution and project files *without*
recompiling or relinking anything, i.e. it is solely the ZERO_CHECK
project which is rebuilt. In order to rebuild the actual targets, I
need to specify the "--clean-first" option to "cmake --build .". It
seems as if a changed VS project file doesn't make VS recompile the
affected source files, even if this is clearly necessary, e.g. due
to changed preprocessor definitions. Is this behavior intended or
VS-immanent, or should it be taken for buggy? Perhaps, a VS expert
could shed some light on this matter; it'd be greatly appreciated.

Regards,

Michael

> On Fri, Nov 11, 2011 at 5:48 PM, Michael Jackson
>  wrote:
>> It is worse and better.
>>
>> 1: CMake will generate the VS projects and solutions every time it needs to 
>> run. DO NOT EDIT the generated VS projects and solutions. Add the 
>> requirements to the CMake files.
>>
>> 2: If you are on VS2007/VS2008 and you do a "git pull" and then switch to VS 
>> and click build a cmake check is run FIRST. If anything is different the new 
>> solution and project files are generated and then the build continues. You 
>> will get a dialog asking if you want to reload all of the projects. Things 
>> are pretty nice.
>>
>> 3: If you are on VS2010 there is now a long standing bug that seems to have 
>> no solution where you basically have to do the following:
>>  Close the VS solution
>>  git pull
>>  run cmake to regenerate the solution and projects
>>  Open the Solution and Compile.
>>
>> Yep. Sucks. Purchased VS2010 last year and have yet to use it because of 
>> that bug. If we (the cmake community**) were to actually figure out how to 
>> solve the problem then VS2010 would be as seamless as VS2008. Here is hoping 
>> for the future.
>>
>> ** I have kept track of the bug. Kitware and others have put a lot of time 
>> into trying to fix the bug. It just seams to be one of those elusive fixes 
>> that there just may not be a solution to.
>> --
>> Mike Jackson 
>>
>> On Nov 11, 2011, at 5:30 PM, David Doria wrote:
>>
>>> I typically work in KDevelop which has CMake support, so if another
>>> developer pushes some new files and changes to the CMakeLists.txt of
>>> my project, I simply 'git pull' the project and then click "Build" and
>>> it knows exactly what to do - it runs CMake and then builds the
>>> project.
>>>
>>> However, when working with Visual Studio, do I have to 'git pull',
>>> then go open cmake-gui from the VS2010E terminal, re-configure and
>>> re-generate the project, then reimport the VS2010E project, then
>>> build? This seems horribly awkward. And the reverse appears to have
>>> the same problem - if working inside VS I add a file to the VS
>>> project, how do I 'export' this addition back to the git repo?
>>>
>>> Thanks,
>>>
>>> David
--

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

[CMake] Problem with LINK_DIRECTORIES

[Arunmozhi]

Hi,

For a static library target, I used TARGET_LINK_LIBRARIES and LINK_DIRECTORIES 
to link with a third party library. As we can see that in cmake, this linking 
information is propagated and used only in an executable/shared library target 
which depends on the former static library. But the issue is that only the 
TARGET_LINK_LIBRARIES is propagated and not the LINK_DIRECTORIES. This fails 
the linking of the executable/shared library target because it could not find 
the third party library.


I found this problem when generating for visual studio 2005. The problem might 
be there in other platforms also.

I feel that this behavior is an issue. Or am I missing something? Please let me 
know.

Regards,
Arun
--

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

Re: [CMake] Problem with LINK_DIRECTORIES

[Michael Wild]

On 11/14/2011 11:46 AM, Arunmozhi wrote:
> Hi,
> 
> For a static library target, I used TARGET_LINK_LIBRARIES and
> LINK_DIRECTORIES to link with a third party library. As we can see that
> in cmake, this linking information is propagated and used only in an
> executable/shared library target which depends on the former static
> library. But the issue is that only the TARGET_LINK_LIBRARIES is
> propagated and not the LINK_DIRECTORIES. This fails the linking of the
> executable/shared library target because it could not find the third
> party library.
> 
> I found this problem when generating for visual studio 2005. The problem
> might be there in other platforms also.
> 
> I feel that this behavior is an issue. Or am I missing something? Please
> let me know.
> 
> Regards,
> Arun
> 

Hi Arun

Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost.
Just pass the full path to the static library directly to
TARGET_LINK_LIBRARIES. This is much more robust and will avoid these
weird effects you are seeing.

HTH

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

Re: [CMake] Problem with LINK_DIRECTORIES

[Robert Dailey]

On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild  wrote:

> Hi Arun
>
> Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost.


I don't really agree with this advice. There are circumstances where
link_directories() is absolutely necessary, so advocating to completely
avoid it isn't really a one size fits all scenario.

What I've done is make sure that link_directories() is called from a parent
level directory, so that all projects inherit the directories. In cases
where you do not have a hierarchy setup like this, then call
link_directories() once with the same directories before each call to
add_executable, add_library, etc.

Also one unrelated note, but static libraries do not require any
dependencies to be linked in when it is built. You only need your third
party libraries in your shared library or executable that links against the
static library in question.

Hope this helps.
--

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

Re: [CMake] Problem with LINK_DIRECTORIES

[Michael Wild]

On 11/14/2011 03:36 PM, Robert Dailey wrote:
> On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild  > wrote:
> 
> Hi Arun
> 
> Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost.
> 
> 
> I don't really agree with this advice. There are circumstances where
> link_directories() is absolutely necessary, so advocating to completely
> avoid it isn't really a one size fits all scenario.

Pray tell, what scenario would that be? I'm really curious, because I
can't think of any...

> 
> What I've done is make sure that link_directories() is called from a
> parent level directory, so that all projects inherit the directories. In
> cases where you do not have a hierarchy setup like this, then call
> link_directories() once with the same directories before each call to
> add_executable, add_library, etc.
> 
> Also one unrelated note, but static libraries do not require any
> dependencies to be linked in when it is built. You only need your third
> party libraries in your shared library or executable that links against
> the static library in question.

The OP is talking about such a setup

a/CMakelists.txt:

add_library(a STATIC a.c)
# a uses foo internally, but doesn't expose this fact in its interface.
# clients of a should not need to know about a's implementation details,
# which is why we declare this dependency here and let CMake handle the
# rest.
target_link_libraries(a foo)

b/CMakeLists.txt
-
add_executable(b b.c)
target_link_libraries(b a)


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

Re: [CMake] CMake single-configuration makefiles

[Michael Hertling]

On 11/13/2011 11:30 PM, Eric Noulard wrote:
> 2011/11/13 Robert Dailey :
>> I understand that currently Makefiles generated by CMake are
>> single-configuration by-design. In other words, you can't issue a "debug" or
>> "release" command to make, you have to regenerate for a different
>> configuration.
> 
> For this purpose you can use 2 build trees that use the same source tree
> 
> cd /path/to/source
> mkdir dbuild
> cd dbuild
> cmake -DCMAKE_BUILD_TYPE=Debug ..
> cd ..
> mkdir rbuild
> cd rbuild
> cmake -DCMAKE_BUILD_TYPE=Release ..
> 
> now to build debug
> cd dbuild; make
> 
> and to build release
> cd rbuild; make
> 
>> Can someone explain the reason for this design?
> 
> Don't know in the past I used makefile that can deal with multiple config,
> everytime it was a "re-entrant" makefile scheme. May be this should be
> avoided in order to produce 'portable' makefiles?
> 
>> Are there any plans to  change it?
> 
> Don't know.
> But may be it would be nice to have a way to create
> "several build trees" at one time for that and produce a unifying
> top level makefile that drive them all.

One can nearly achieve this by now; see the following example:

# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(MULTICONFIG C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
# -->
IF(CMAKE_CONFIGURATION_TYPES)
ADD_CUSTOM_TARGET(configs)
ADD_CUSTOM_TARGET(builds)
FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES)
FILE(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/${i})
ADD_CUSTOM_TARGET(config-${i}
COMMAND ${CMAKE_COMMAND} ${PROJECT_SOURCE_DIR}
-DCMAKE_BUILD_TYPE=${i}
-DCACHE_DIR=${PROJECT_BINARY_DIR}
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/${i})
ADD_DEPENDENCIES(configs config-${i})
ADD_CUSTOM_TARGET(build-${i}
COMMAND ${CMAKE_COMMAND} --build ${PROJECT_BINARY_DIR}/${i})
ADD_DEPENDENCIES(builds build-${i})
ENDFOREACH()
FOREACH(i IN LISTS FORWARD)
ADD_CUSTOM_TARGET(${i}
COMMAND ${CMAKE_COMMAND} --build \${CONFIG} --target ${i})
ENDFOREACH()
ADD_CUSTOM_TARGET(world ALL
COMMAND ${CMAKE_COMMAND} --build \${CONFIG})
RETURN()
ENDIF()
IF(DEFINED CACHE_DIR)
LOAD_CACHE(${CACHE_DIR}
EXCLUDE CMAKE_BUILD_TYPE CMAKE_CONFIGURATION_TYPES)
ENDIF()
# <--
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS_DEBUG DEBUG
COMPILE_DEFINITIONS_RELEASE RELEASE)

/* main.c: */
int main(void){return 0;}

The part to add in order to enable multiple build trees is between
"-->" and "<--". The basic idea is: If CMAKE_CONFIGURATION_TYPES is
defined, create a build tree for each entry along with a custom target
which configures that tree with the correct CMAKE_BUILD_TYPE. Also, add
a custom target which builds that tree via "cmake --build". These build
trees' configurations must be a separate step - therefore, driven by a
custom target - because the top-level configuration has to be finished
to enable the several build trees to load the cache via LOAD_CACHE();
otherwise, the initial -D settings would not be forwarded. For these
reasons, we need the CACHE_DIR variable, and the RETURN() statement
disables the actual part of the CMakeLists.txt file in the top-level
configuration. Obviously, CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPES
must not be loaded from the cache to the build trees. A downside is
that you must implement your own, say, "target forwarding" if you
want to be able to say "main  CONFIG=debug"; the FORWARD
variable with a list of targets to be forwarded is used for this
purpose. To see the project in action, go to an empty top-level
build directory and issue, e.g.:

cmake  \
-DCMAKE_CONFIGURATION_TYPES="debug;release;custom" \
-DCMAKE_C_FLAGS_CUSTOM="-DCUSTOM" \
-DFORWARD="main"

This will create the subdirectories {debug,release,custom}; now

make configs

to configure the different build trees and load the cache from the
top-level configuration. Subsequently, you can say "make builds" to
build all configurations, or "cmake --build " to build only
one, or "make main CONFIG=" or even "make CONFIG=".

Anyway, although the addition to mimic the behavior of a real multi-
configuration generator to the Makefiles ones is no big deal, I'm
in doubt if it's worth the effort. Personally, I'm fine with the
Makefiles generators' single-configuration limitation.

Regards,

Michael

>> I'm new to Makefiles so I'm curious to learn as much as possible
>> about it.
> 
> If you are new to makefile may be you can have a look at
> the chapter 4 of this book
> http://www.informit.com/store/product.aspx?isbn=0130091154
> 
> it is about GNU make but it contains valuable introduction to "makefile"
> and the book may downloaded:
> http://ptgmedia.pearsoncmg.com/images/0130091154/downloads/0130091154.zip
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep mes

Re: [CMake] CMAKE_RUNTIME_OUTPUT_DIRECTORY best practice for Windows and Visual Studio

[Mateusz Łoskot]

On 13 November 2011 19:51, Niels Dekker - address until 2014
 wrote:
> Mateusz Loskot wrote:
>> On Windows, I use Visual Studio for development, so I have
>> CMake-generated .sln with projects. loaded into the IDE. I build.
>> Then, I'd like to run one of executables (e.g. test.exe) which links against 
>> the DLLs also
>> built by the project. Obviously, it is necessary to deal with the run-time 
>> search path.
>>
>> At the moment, I simplify things by outputting all .exe and .dll
>> binaries to common directory, so programs can find required DLLs:
>>
>> set(MYPRJOUTDIR ${PROJECT_BINARY_DIR}/bin/${CMAKE_BUILD_TYPE})
>> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${MYPRJOUTDIR})
>
> On Windows, it looks fine to me to have all the DLL's built by the project
> together with the executable that links against them, in one and the same
> CMAKE_RUNTIME_OUTPUT_DIRECTORY.

Good, I'm glad it's nothing weird neither wrong in this approach.

> The alternative of setting the PATH looks
> less reliable to me, because the PATH may easily be overruled by other
> locations (current directory, system directory or Windows directory),
> depending on that rather complicated "Dynamic-Link Library Search Order"
> thing, http://msdn.microsoft.com/en-us/site/ms682586  And eventually I guess
> you don't want your application to depend on the PATH at the end user machine.

Yes, you are right.
I have some projects configured in such way they try to generate
.vcproj.user file
which defines PATH with pointers to location of run-time dependencies.
For example: https://github.com/libLAS/libLAS/tree/master/cmake

> However, I haven't yet tried to build an "isolated application"
> according to your reference [3]
> (http://msdn.microsoft.com/en-us/library/aa375190%28VS.85%29.aspx).
> Would you recommend doing so?

Niels, I haven't tried it myself neither. I don't have experience with
this technique,
so I can't say if it is recommended.
Actually, I hoped to receive a related piece of advice here, from CMake users.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
--

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

Re: [CMake] Problem with LINK_DIRECTORIES

[David Cole]

On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey  wrote:
> On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild  wrote:
>>
>> Hi Arun
>> Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost.
>
> I don't really agree with this advice. There are circumstances where
> link_directories() is absolutely necessary, so advocating to completely
> avoid it isn't really a one size fits all scenario.

I agree with the advice entirely. link_directories is completely
*un*necessary if you follow the other advice which is to always use
full path names to library files (or CMake target names) when calling
target_link_libraries.

I never use link_directories.


> What I've done is make sure that link_directories() is called from a parent
> level directory, so that all projects inherit the directories. In cases
> where you do not have a hierarchy setup like this, then call
> link_directories() once with the same directories before each call to
> add_executable, add_library, etc.
> Also one unrelated note, but static libraries do not require any
> dependencies to be linked in when it is built. You only need your third
> party libraries in your shared library or executable that links against the
> static library in question.
> Hope this helps.
> --
>
> 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
>
--

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

Re: [CMake] Problem with LINK_DIRECTORIES

[Robert Dailey]

On Mon, Nov 14, 2011 at 11:00 AM, David Cole  wrote:

> On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey  wrote:
> > On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild  wrote:
> >>
> >> Hi Arun
> >> Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost.
> >
> > I don't really agree with this advice. There are circumstances where
> > link_directories() is absolutely necessary, so advocating to completely
> > avoid it isn't really a one size fits all scenario.
>
> I agree with the advice entirely. link_directories is completely
> *un*necessary if you follow the other advice which is to always use
> full path names to library files (or CMake target names) when calling
> target_link_libraries.
>
> I never use link_directories.


Well maybe you can tell me I'm doing this wrong then, but based on how I am
currently setting up my third party libraries, it is required.

So basically all third party libraries we use are not installed
individually, instead we have a server on our intranet that contains
precompiled versions of all libraries in a specific and consistent
hierarchy. For this reason, it doesn't make sense to use find_library(),
which would normally always give you absolute paths to your library files
and thus link_directories() would not be needed.

Instead I have a script in CMake that iterates each third party library and
adds its lib link directory to a list. When done I take this whole list of
link directories and pass it to link_directories() in my top level
CMakeLists file, this way each and every project will include all of the
third party library lib directories to have access to them.

For each target I simply create a list of my libs, like so:

set( libraries zlib libbdb47 )

I pass each one of these to target_link_libraries() and I leave it up to
the compiler to search for where to find the file in the provided link
directories.
--

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

Re: [CMake] Problem with LINK_DIRECTORIES

[Mateusz Łoskot]

On 14 November 2011 17:17, Robert Dailey  wrote:
> So basically all third party libraries we use are not installed
> individually, instead we have a server on our intranet that contains
> precompiled versions of all libraries in a specific and consistent
> hierarchy. For this reason, it doesn't make sense to use find_library(),
> which would normally always give you absolute paths to your library files
> and thus link_directories() would not be needed.

A typical Linux user can say the same: I have all my libraries in /usr/lib
so it does not make sense to use find_library.
No point arguing if it would make sense or not.
Simply, find_library is a unified convention used by CMake, it works regardless
user-specific filesystem structure.

Simply, it would not hurt to use find_library().
Then, you can follow the CMake convention, without a need of custom
scripts, etc.

> I pass each one of these to target_link_libraries() and I leave it up to the
> compiler to search for where to find the file in the provided link
> directories.

IMO, you don't buy anything with this customisation.
Either CMake finds library and tells compiler "look, it's here"
or CMake + custom script approximates library location
and lets linker to find it.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
--

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

Re: [CMake] Adding a new language

[Stefan Monnier]

> "If the -c option is given, specify the name of the 
> object file produced for the next source file that appears on the 
> command line."

> So if the help says that -o is supposed to do something sensible when used
> with -c but it doesn't, I'd suggest to file a bug. Note that the order of
> arguments may be important.

Duh!  Thanks for insisting: it works!
I'd still like to know how to explain to cmake that the command produces
2 files, but at least I can get rid of my hack.


Stefan "happier"

--

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

[CMake] Libraries with custom build command

[Mathias Gaunard]

What is the recommended way to define libraries with custom build commands?

This trick seems to be the only way:

if(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp)
  file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp)
endif()
add_library(foo dummy.cpp)
add_custom_command(TARGET foo POST_BUILD
   COMMAND my command to replace the dummy libfoo
  )

Is it normal that kind of thing is not possible with IMPORTED libraries?
--

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

Re: [CMake] Problem with LINK_DIRECTORIES

[Michael Hertling]

On 11/14/2011 06:17 PM, Robert Dailey wrote:
> On Mon, Nov 14, 2011 at 11:00 AM, David Cole  wrote:
> 
>> On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey  wrote:
>>> On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild  wrote:

 Hi Arun
 Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost.
>>>
>>> I don't really agree with this advice. There are circumstances where
>>> link_directories() is absolutely necessary, so advocating to completely
>>> avoid it isn't really a one size fits all scenario.
>>
>> I agree with the advice entirely. link_directories is completely
>> *un*necessary if you follow the other advice which is to always use
>> full path names to library files (or CMake target names) when calling
>> target_link_libraries.
>>
>> I never use link_directories.
> 
> 
> Well maybe you can tell me I'm doing this wrong then, but based on how I am
> currently setting up my third party libraries, it is required.
> 
> So basically all third party libraries we use are not installed
> individually, instead we have a server on our intranet that contains
> precompiled versions of all libraries in a specific and consistent
> hierarchy. For this reason, it doesn't make sense to use find_library(),
> which would normally always give you absolute paths to your library files
> and thus link_directories() would not be needed.
> 
> Instead I have a script in CMake that iterates each third party library and
> adds its lib link directory to a list. When done I take this whole list of
> link directories and pass it to link_directories() in my top level
> CMakeLists file, this way each and every project will include all of the
> third party library lib directories to have access to them.

Instead of populating a list with the libraries' directories, you might
set up one variable for each library containing the latter's full path,
e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
files and, thus, will be known wherever they are needed in your project.

> For each target I simply create a list of my libs, like so:
> 
> set( libraries zlib libbdb47 )

SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})

> I pass each one of these to target_link_libraries() and I leave it up to
> the compiler to search for where to find the file in the provided link
> directories.

An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
especially with numerous directories, there's a growing probability
that the -L option will lure the linker into a wrong directory some
day. There're even situations which can't be resolved with -L/-l at
all: Suppose you have a directory x with liba.so and libb.so, and a
directory y with different versions of lib{a,b}.so. Suppose further
you want to link against x/liba.so and y/libb.so. How do you achieve
this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
insisting on the use of LINK_DIRECTORIES() limits the possibilities
how to organize the libraries on your intranet server. IMO, these
are actual drawbacks. OTOH, you must know the libaries' locations
to use LINK_DIRECTORIES(), and the libraries must be known anyway,
so why not join the locations to the libraries and use full paths?

Regards,

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

Re: [CMake] Problem with LINK_DIRECTORIES

[Robert Dailey]

On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling wrote:

> On 11/14/2011 06:17 PM, Robert Dailey wrote:
> > Well maybe you can tell me I'm doing this wrong then, but based on how I
> am
> > currently setting up my third party libraries, it is required.
> >
> > So basically all third party libraries we use are not installed
> > individually, instead we have a server on our intranet that contains
> > precompiled versions of all libraries in a specific and consistent
> > hierarchy. For this reason, it doesn't make sense to use find_library(),
> > which would normally always give you absolute paths to your library files
> > and thus link_directories() would not be needed.
> >
> > Instead I have a script in CMake that iterates each third party library
> and
> > adds its lib link directory to a list. When done I take this whole list
> of
> > link directories and pass it to link_directories() in my top level
> > CMakeLists file, this way each and every project will include all of the
> > third party library lib directories to have access to them.
>
> Instead of populating a list with the libraries' directories, you might
> set up one variable for each library containing the latter's full path,
> e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
> CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
> files and, thus, will be known wherever they are needed in your project.
>
> > For each target I simply create a list of my libs, like so:
> >
> > set( libraries zlib libbdb47 )
>
> SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
>
> > I pass each one of these to target_link_libraries() and I leave it up to
> > the compiler to search for where to find the file in the provided link
> > directories.
>
> An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
> especially with numerous directories, there's a growing probability
> that the -L option will lure the linker into a wrong directory some
> day. There're even situations which can't be resolved with -L/-l at
> all: Suppose you have a directory x with liba.so and libb.so, and a
> directory y with different versions of lib{a,b}.so. Suppose further
> you want to link against x/liba.so and y/libb.so. How do you achieve
> this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
> insisting on the use of LINK_DIRECTORIES() limits the possibilities
> how to organize the libraries on your intranet server. IMO, these
> are actual drawbacks. OTOH, you must know the libaries' locations
> to use LINK_DIRECTORIES(), and the libraries must be known anyway,
> so why not join the locations to the libraries and use full paths?


Problem is, if I end up using find_library(), I will have to provide hint
search directories for each and every single library, and there are about
20 of them. This to me is the same as just generating a list of directories
and including those directly, and a lot less trouble.

find_library() is great and I really wanted to use it for this, but to me
the benefits of using it diminish when we are not using third party
libraries installed in a non deterministic location. If a user installs the
third party libraries in different locations on each of their machines, and
different versions, it makes more sense to use it in that case.

Why should I let CMake search & find a library when I already know where it
is? Simply to get absolute paths to those libraries? If I want absolute
paths I can think of much better ways to do it, preferably through string
concatenation.

Another issue is that 80% of the libraries we use do not have a
pre-packaged Find module provided by CMake. This means I'd end up writing
80% of the find modules myself. This is a lot of work for no perceived
benefit.

With my points made and circumstances explained, can you still give me a
good reason to use find_library?

I understand and agree with the issues that come with using
link_directories(), however I haven't run into those issues yet and our
consistent organization of third party libraries on our intranet server are
carry over from our legacy build system that I'm replacing.
--

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

Re: [CMake] Problem with LINK_DIRECTORIES

[Alexander Neundorf]

On Monday 14 November 2011, Robert Dailey wrote:
> On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling 
wrote:
> > On 11/14/2011 06:17 PM, Robert Dailey wrote:
> > > Well maybe you can tell me I'm doing this wrong then, but based on how
> > > I
> > 
> > am
> > 
> > > currently setting up my third party libraries, it is required.
> > > 
> > > So basically all third party libraries we use are not installed
> > > individually, instead we have a server on our intranet that contains
> > > precompiled versions of all libraries in a specific and consistent
> > > hierarchy. For this reason, it doesn't make sense to use
> > > find_library(), which would normally always give you absolute paths to
> > > your library files and thus link_directories() would not be needed.
> > > 
> > > Instead I have a script in CMake that iterates each third party library
> > 
> > and
> > 
> > > adds its lib link directory to a list. When done I take this whole list
> > 
> > of
> > 
> > > link directories and pass it to link_directories() in my top level
> > > CMakeLists file, this way each and every project will include all of
> > > the third party library lib directories to have access to them.
> > 
> > Instead of populating a list with the libraries' directories, you might
> > set up one variable for each library containing the latter's full path,
> > e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
> > CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
> > files and, thus, will be known wherever they are needed in your project.
> > 
> > > For each target I simply create a list of my libs, like so:
> > > 
> > > set( libraries zlib libbdb47 )
> > 
> > SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
> > 
> > > I pass each one of these to target_link_libraries() and I leave it up
> > > to the compiler to search for where to find the file in the provided
> > > link directories.
> > 
> > An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
> > especially with numerous directories, there's a growing probability
> > that the -L option will lure the linker into a wrong directory some
> > day. There're even situations which can't be resolved with -L/-l at
> > all: Suppose you have a directory x with liba.so and libb.so, and a
> > directory y with different versions of lib{a,b}.so. Suppose further
> > you want to link against x/liba.so and y/libb.so. How do you achieve
> > this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
> > insisting on the use of LINK_DIRECTORIES() limits the possibilities
> > how to organize the libraries on your intranet server. IMO, these
> > are actual drawbacks. OTOH, you must know the libaries' locations
> > to use LINK_DIRECTORIES(), and the libraries must be known anyway,
> > so why not join the locations to the libraries and use full paths?
> 
> Problem is, if I end up using find_library(), I will have to provide hint
> search directories for each and every single library, and there are about
> 20 of them. This to me is the same as just generating a list of directories
> and including those directly, and a lot less trouble.


You can set CMAKE_PREFIX_PATH, and cmake will automatically look in the lib/ 
and include/ subdirectories of those.

Alex
--

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

Re: [CMake] Problem with LINK_DIRECTORIES

[David Cole]

If you already know where all the libraries are, please just use the
full paths to those libraries, and do not use find_library.


On Mon, Nov 14, 2011 at 3:15 PM, Robert Dailey  wrote:
> On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling 
> wrote:
>>
>> On 11/14/2011 06:17 PM, Robert Dailey wrote:
>> > Well maybe you can tell me I'm doing this wrong then, but based on how I
>> > am
>> > currently setting up my third party libraries, it is required.
>> >
>> > So basically all third party libraries we use are not installed
>> > individually, instead we have a server on our intranet that contains
>> > precompiled versions of all libraries in a specific and consistent
>> > hierarchy. For this reason, it doesn't make sense to use find_library(),
>> > which would normally always give you absolute paths to your library
>> > files
>> > and thus link_directories() would not be needed.
>> >
>> > Instead I have a script in CMake that iterates each third party library
>> > and
>> > adds its lib link directory to a list. When done I take this whole list
>> > of
>> > link directories and pass it to link_directories() in my top level
>> > CMakeLists file, this way each and every project will include all of the
>> > third party library lib directories to have access to them.
>>
>> Instead of populating a list with the libraries' directories, you might
>> set up one variable for each library containing the latter's full path,
>> e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
>> CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
>> files and, thus, will be known wherever they are needed in your project.
>>
>> > For each target I simply create a list of my libs, like so:
>> >
>> > set( libraries zlib libbdb47 )
>>
>> SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
>>
>> > I pass each one of these to target_link_libraries() and I leave it up to
>> > the compiler to search for where to find the file in the provided link
>> > directories.
>>
>> An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
>> especially with numerous directories, there's a growing probability
>> that the -L option will lure the linker into a wrong directory some
>> day. There're even situations which can't be resolved with -L/-l at
>> all: Suppose you have a directory x with liba.so and libb.so, and a
>> directory y with different versions of lib{a,b}.so. Suppose further
>> you want to link against x/liba.so and y/libb.so. How do you achieve
>> this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
>> insisting on the use of LINK_DIRECTORIES() limits the possibilities
>> how to organize the libraries on your intranet server. IMO, these
>> are actual drawbacks. OTOH, you must know the libaries' locations
>> to use LINK_DIRECTORIES(), and the libraries must be known anyway,
>> so why not join the locations to the libraries and use full paths?
>
> Problem is, if I end up using find_library(), I will have to provide hint
> search directories for each and every single library, and there are about 20
> of them. This to me is the same as just generating a list of directories and
> including those directly, and a lot less trouble.
> find_library() is great and I really wanted to use it for this, but to me
> the benefits of using it diminish when we are not using third party
> libraries installed in a non deterministic location. If a user installs the
> third party libraries in different locations on each of their machines, and
> different versions, it makes more sense to use it in that case.
> Why should I let CMake search & find a library when I already know where it
> is? Simply to get absolute paths to those libraries? If I want absolute
> paths I can think of much better ways to do it, preferably through string
> concatenation.
> Another issue is that 80% of the libraries we use do not have a pre-packaged
> Find module provided by CMake. This means I'd end up writing 80% of the find
> modules myself. This is a lot of work for no perceived benefit.
> With my points made and circumstances explained, can you still give me a
> good reason to use find_library?
> I understand and agree with the issues that come with using
> link_directories(), however I haven't run into those issues yet and our
> consistent organization of third party libraries on our intranet server are
> carry over from our legacy build system that I'm replacing.
> --
>
> 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
>
--

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 lin

Re: [CMake] Adding a new language

[Alan W. Irwin]

On 2011-11-14 13:30-0500 Stefan Monnier wrote:


I'd still like to know how to explain to cmake that the command produces
2 files, but at least I can get rid of my hack.


That (assuming just a simple object file is produced by compilation)
is one of several general limitations with CMake language support. For
example, my understanding is this issue has been taken care of for
Fortran 95 (where compilation produces both object and module files)
with Fortran-95 specific changes to the C++ cmake code.  But I would far
prefer to see a generic mechanism for this to not only to deal with
the Fortran 95 module issue, but also the compilation-generated Ada
library identification (*.ali) files, and also the similar issue for
OCaml compiler generated files that you have described.

Because of this and other struggles I had trying to implement Ada
language support for CMake, I didn't even consider implementing CMake
language support for OCaml for the PLplot OCaml bindings.  Instead we
currently use (many!) custom commands and targets for that case, but
I would be happy to change to your CMake OCaml language support
if/when that works.

Here is what I suggest you do to move forward with that project. 
Present a complete summary of your OCaml compilation needs for the

CMake developers.  That is, state what commands are used to build
libraries, what commands are used to build executables, what kinds of
files are generated for each stage of each kind of build, and what
directories need to be identified at each stage of the build to gain
access to files generated in previous stages of the build process.
Furthermore, a complicating factor with OCaml is there are two kinds
of executables (and libraries?) based on whether ocamlc or ocamlopt is
used to respectively produce bytecode executable files that are
executed with the OCaml interpreter (ocamlrun) or native executable
files that are executed with the ordinary run-time loader. If there
are different generic build needs for ocamlc versus ocamlopt be sure
to include those differences in your summary.

If you are willing to make such an OCaml summary, I would be willing
to do the same thing for Ada to make our joint case to the CMake
developers of what kind of additional generic language support is
needed by CMake to deal with the complicated build needs of languages
such as OCaml and Ada (and Fortran 95) in a completely generic way.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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

[CMake] Circular dependencies because of file names?

[Jookia]

I have the following code:

# -- DOXYGEN

find_package(Doxygen)

set(docsDir "${CMAKE_BINARY_DIR}/docs/")

add_custom_command(OUTPUT ${docsDir}
  COMMAND ${CMAKE_COMMAND} "-E" "make_directory"
  ${docsDir} VERBATIM)

add_custom_target("docs"
  COMMAND "${DOXYGEN_EXECUTABLE}"
  "${CMAKE_SOURCE_DIR}/../doxygen/doxyfile"
  WORKING_DIRECTORY ${docsDir}
  DEPENDS ${docsDir})

set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
  "${docsDir}")

Which causes a circular conflict. But when I change the docsDir to 
"${CMAKE_BINARY_DIR}/docs2/", I no longer get the error.


Is there a way to fix this?
--

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

Re: [CMake] Problem with LINK_DIRECTORIES

[Clinton Stimpson]

That's what I do sometimes.  To make that easier, CMake gives some convenience 
variables for library prefixes and suffixes if you are on multiple platforms.

Clint

On Monday, November 14, 2011 01:20:29 pm David Cole wrote:
> If you already know where all the libraries are, please just use the
> full paths to those libraries, and do not use find_library.
> 
> On Mon, Nov 14, 2011 at 3:15 PM, Robert Dailey  wrote:
> > On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling 
> > 
> > wrote:
> >> On 11/14/2011 06:17 PM, Robert Dailey wrote:
> >> > Well maybe you can tell me I'm doing this wrong then, but based on how
> >> >I
> >> >
> >> > am
> >> > currently setting up my third party libraries, it is required.
> >> > 
> >> > So basically all third party libraries we use are not installed
> >> > individually, instead we have a server on our intranet that contains
> >> > precompiled versions of all libraries in a specific and consistent
> >> > hierarchy. For this reason, it doesn't make sense to use
> >> > find_library(), which would normally always give you absolute paths
> >> > to your library files
> >> > and thus link_directories() would not be needed.
> >> > 
> >> > Instead I have a script in CMake that iterates each third party
> >> > library and
> >> > adds its lib link directory to a list. When done I take this whole
> >> > list of
> >> > link directories and pass it to link_directories() in my top level
> >> > CMakeLists file, this way each and every project will include all of
> >> > the third party library lib directories to have access to them.
> >> 
> >> Instead of populating a list with the libraries' directories, you might
> >> set up one variable for each library containing the latter's full path,
> >> e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
> >> CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
> >> files and, thus, will be known wherever they are needed in your project.
> >> 
> >> > For each target I simply create a list of my libs, like so:
> >> > 
> >> > set( libraries zlib libbdb47 )
> >> 
> >> SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
> >> 
> >> > I pass each one of these to target_link_libraries() and I leave it up
> >> > to the compiler to search for where to find the file in the provided
> >> > link directories.
> >> 
> >> An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
> >> especially with numerous directories, there's a growing probability
> >> that the -L option will lure the linker into a wrong directory some
> >> day. There're even situations which can't be resolved with -L/-l at
> >> all: Suppose you have a directory x with liba.so and libb.so, and a
> >> directory y with different versions of lib{a,b}.so. Suppose further
> >> you want to link against x/liba.so and y/libb.so. How do you achieve
> >> this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
> >> insisting on the use of LINK_DIRECTORIES() limits the possibilities
> >> how to organize the libraries on your intranet server. IMO, these
> >> are actual drawbacks. OTOH, you must know the libaries' locations
> >> to use LINK_DIRECTORIES(), and the libraries must be known anyway,
> >> so why not join the locations to the libraries and use full paths?
> > 
> > Problem is, if I end up using find_library(), I will have to provide hint
> > search directories for each and every single library, and there are about
> > 20 of them. This to me is the same as just generating a list of
> > directories and including those directly, and a lot less trouble.
> > find_library() is great and I really wanted to use it for this, but to me
> > the benefits of using it diminish when we are not using third party
> > libraries installed in a non deterministic location. If a user installs
> > the third party libraries in different locations on each of their
> > machines, and different versions, it makes more sense to use it in that
> > case.
> > Why should I let CMake search & find a library when I already know where
> > it is? Simply to get absolute paths to those libraries? If I want
> > absolute paths I can think of much better ways to do
> > it, preferably through string concatenation.
> > Another issue is that 80% of the libraries we use do not have a
> > pre-packaged Find module provided by CMake. This means I'd end up
> > writing 80% of the find modules myself. This is a lot of work for no
> > perceived benefit.
> > With my points made and circumstances explained, can you still give me a
> > good reason to use find_library?
> > I understand and agree with the issues that come with using
> > link_directories(), however I haven't run into those issues yet and our
> > consistent organization of third party libraries on our intranet server
> > are carry over from our legacy build system that I'm replacing.
> > --
> > 
> > Powered by www.kitware.com
> > 
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> > 

Re: [CMake] Problem with LINK_DIRECTORIES

[Robert Dailey]

What is the difference between CMAKE_LINK_LIBRARY_SUFFIX and
CMAKE_IMPORT_LIBRARY_SUFFIX? Which should I use?

-
Robert Dailey


On Mon, Nov 14, 2011 at 2:49 PM, Clinton Stimpson wrote:

>
> That's what I do sometimes.  To make that easier, CMake gives some
> convenience
> variables for library prefixes and suffixes if you are on multiple
> platforms.
>
> Clint
>
> On Monday, November 14, 2011 01:20:29 pm David Cole wrote:
> > If you already know where all the libraries are, please just use the
> > full paths to those libraries, and do not use find_library.
> >
> > On Mon, Nov 14, 2011 at 3:15 PM, Robert Dailey 
> wrote:
> > > On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling  >
> > >
> > > wrote:
> > >> On 11/14/2011 06:17 PM, Robert Dailey wrote:
> > >> > Well maybe you can tell me I'm doing this wrong then, but based on
> how
> > >> >I
> > >> >
> > >> > am
> > >> > currently setting up my third party libraries, it is required.
> > >> >
> > >> > So basically all third party libraries we use are not installed
> > >> > individually, instead we have a server on our intranet that contains
> > >> > precompiled versions of all libraries in a specific and consistent
> > >> > hierarchy. For this reason, it doesn't make sense to use
> > >> > find_library(), which would normally always give you absolute paths
> > >> > to your library files
> > >> > and thus link_directories() would not be needed.
> > >> >
> > >> > Instead I have a script in CMake that iterates each third party
> > >> > library and
> > >> > adds its lib link directory to a list. When done I take this whole
> > >> > list of
> > >> > link directories and pass it to link_directories() in my top level
> > >> > CMakeLists file, this way each and every project will include all of
> > >> > the third party library lib directories to have access to them.
> > >>
> > >> Instead of populating a list with the libraries' directories, you
> might
> > >> set up one variable for each library containing the latter's full
> path,
> > >> e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
> > >> CMakeLists.txt, these variables propagate to subordinate
> CMakeLists.txt
> > >> files and, thus, will be known wherever they are needed in your
> project.
> > >>
> > >> > For each target I simply create a list of my libs, like so:
> > >> >
> > >> > set( libraries zlib libbdb47 )
> > >>
> > >> SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
> > >>
> > >> > I pass each one of these to target_link_libraries() and I leave it
> up
> > >> > to the compiler to search for where to find the file in the provided
> > >> > link directories.
> > >>
> > >> An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
> > >> especially with numerous directories, there's a growing probability
> > >> that the -L option will lure the linker into a wrong directory some
> > >> day. There're even situations which can't be resolved with -L/-l at
> > >> all: Suppose you have a directory x with liba.so and libb.so, and a
> > >> directory y with different versions of lib{a,b}.so. Suppose further
> > >> you want to link against x/liba.so and y/libb.so. How do you achieve
> > >> this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
> > >> insisting on the use of LINK_DIRECTORIES() limits the possibilities
> > >> how to organize the libraries on your intranet server. IMO, these
> > >> are actual drawbacks. OTOH, you must know the libaries' locations
> > >> to use LINK_DIRECTORIES(), and the libraries must be known anyway,
> > >> so why not join the locations to the libraries and use full paths?
> > >
> > > Problem is, if I end up using find_library(), I will have to provide
> hint
> > > search directories for each and every single library, and there are
> about
> > > 20 of them. This to me is the same as just generating a list of
> > > directories and including those directly, and a lot less trouble.
> > > find_library() is great and I really wanted to use it for this, but to
> me
> > > the benefits of using it diminish when we are not using third party
> > > libraries installed in a non deterministic location. If a user installs
> > > the third party libraries in different locations on each of their
> > > machines, and different versions, it makes more sense to use it in that
> > > case.
> > > Why should I let CMake search & find a library when I already know
> where
> > > it is? Simply to get absolute paths to those libraries? If I want
> > > absolute paths I can think of much better ways to do
> > > it, preferably through string concatenation.
> > > Another issue is that 80% of the libraries we use do not have a
> > > pre-packaged Find module provided by CMake. This means I'd end up
> > > writing 80% of the find modules myself. This is a lot of work for no
> > > perceived benefit.
> > > With my points made and circumstances explained, can you still give me
> a
> > > good reason to use find_library?
> > > I understand and agree with the issues that come 

Re: [CMake] Problem with LINK_DIRECTORIES

[Clinton Stimpson]

>From the Modules/Platform/* files, it looks like the only difference between 
>the 
two is when using CYGWIN or MinGW.  I'm not sure which to use.

Clint

On Monday, November 14, 2011 01:51:49 pm Robert Dailey wrote:
> What is the difference between CMAKE_LINK_LIBRARY_SUFFIX and
> CMAKE_IMPORT_LIBRARY_SUFFIX? Which should I use?
> 
> -
> Robert Dailey
> 
> On Mon, Nov 14, 2011 at 2:49 PM, Clinton Stimpson 
wrote:
> > That's what I do sometimes.  To make that easier, CMake gives some
> > convenience
> > variables for library prefixes and suffixes if you are on multiple
> > platforms.
> > 
> > Clint
> > 
> > On Monday, November 14, 2011 01:20:29 pm David Cole wrote:
> > > If you already know where all the libraries are, please just use the
> > > full paths to those libraries, and do not use find_library.
> > > 
> > > On Mon, Nov 14, 2011 at 3:15 PM, Robert Dailey 
> > 
> > wrote:
> > > > On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling
> > > >  > > > 
> > > > wrote:
> > > >> On 11/14/2011 06:17 PM, Robert Dailey wrote:
> > > >> > Well maybe you can tell me I'm doing this wrong then, but based on
> > 
> > how
> > 
> > > >> >I
> > > >> >
> > > >> > am
> > > >> > currently setting up my third party libraries, it is required.
> > > >> > 
> > > >> > So basically all third party libraries we use are not installed
> > > >> > individually, instead we have a server on our intranet that
> > > >> > contains precompiled versions of all libraries in a specific and
> > > >> > consistent hierarchy. For this reason, it doesn't make sense to
> > > >> > use
> > > >> > find_library(), which would normally always give you absolute
> > > >> > paths to your library files
> > > >> > and thus link_directories() would not be needed.
> > > >> > 
> > > >> > Instead I have a script in CMake that iterates each third party
> > > >> > library and
> > > >> > adds its lib link directory to a list. When done I take this whole
> > > >> > list of
> > > >> > link directories and pass it to link_directories() in my top level
> > > >> > CMakeLists file, this way each and every project will include all
> > > >> > of the third party library lib directories to have access to
> > > >> > them.
> > > >> 
> > > >> Instead of populating a list with the libraries' directories, you
> > 
> > might
> > 
> > > >> set up one variable for each library containing the latter's full
> > 
> > path,
> > 
> > > >> e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the
> > > >> top-level CMakeLists.txt, these variables propagate to subordinate
> > 
> > CMakeLists.txt
> > 
> > > >> files and, thus, will be known wherever they are needed in your
> > 
> > project.
> > 
> > > >> > For each target I simply create a list of my libs, like so:
> > > >> > 
> > > >> > set( libraries zlib libbdb47 )
> > > >> 
> > > >> SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
> > > >> 
> > > >> > I pass each one of these to target_link_libraries() and I leave it
> > 
> > up
> > 
> > > >> > to the compiler to search for where to find the file in the
> > > >> > provided link directories.
> > > >> 
> > > >> An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
> > > >> especially with numerous directories, there's a growing probability
> > > >> that the -L option will lure the linker into a wrong directory some
> > > >> day. There're even situations which can't be resolved with -L/-l at
> > > >> all: Suppose you have a directory x with liba.so and libb.so, and a
> > > >> directory y with different versions of lib{a,b}.so. Suppose further
> > > >> you want to link against x/liba.so and y/libb.so. How do you achieve
> > > >> this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
> > > >> insisting on the use of LINK_DIRECTORIES() limits the possibilities
> > > >> how to organize the libraries on your intranet server. IMO, these
> > > >> are actual drawbacks. OTOH, you must know the libaries' locations
> > > >> to use LINK_DIRECTORIES(), and the libraries must be known anyway,
> > > >> so why not join the locations to the libraries and use full paths?
> > > > 
> > > > Problem is, if I end up using find_library(), I will have to provide
> > 
> > hint
> > 
> > > > search directories for each and every single library, and there are
> > 
> > about
> > 
> > > > 20 of them. This to me is the same as just generating a list of
> > > > directories and including those directly, and a lot less trouble.
> > > > find_library() is great and I really wanted to use it for this, but
> > > > to
> > 
> > me
> > 
> > > > the benefits of using it diminish when we are not using third party
> > > > libraries installed in a non deterministic location. If a user
> > > > installs the third party libraries in different locations on each of
> > > > their machines, and different versions, it makes more sense to use
> > > > it in that case.
> > > > Why should I let CMake search & find a library when I already know
> > 
> > where
> > 
> > > > it is? Simply to get absolute paths to 

Re: [CMake] Multiple source directory scenario and cdt generator

[Dan Kegel]

On Sat, Nov 12, 2011 at 11:04 AM, Alexander Neundorf
 wrote:
> Ok. So two things:
> * please give current cmake master a try, it has several improvements.
> * please create a ticket in the cmake bug tracker for this, improved source-
> project generator for Eclipse, or something like this.
>
> My goal is to have no open bugs for Eclipse when 2.8.7 wil be released.

OK, I filed http://public.kitware.com/Bug/view.php?id=12579
for this

I'll give cmake master a spin sometime this week.
--

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