from:"Andreas Naumann"

Re: [CMake] CMake link order

2019-10-18 Thread Andreas Naumann


Hey all,

I face a similar problem when constructing a correct (and predictable)
link order for Linux and Cygwin. It would be of great help, if there is
some documentation.

In particular, I would raise two question
    1) when does the link order change?
    2) when does a clean up happen and in which way?

I did also some experiments on linux with cmake 3.13.4 and ended up with
the appended (nearly) minimal example. The example consists of:

 * two "fake"-libraries A and B, whose paths are stored in two
   variables libA and libB respectively. (they serve just for
   demonstration, no real linking is required)
 * two interface libraries interfaceA and interfaceB. Each links to the
   corresponding fake library.
 * two imported libraries impA and impB, each has the location to the
   corresponding fake library.

Now I construct some combinations:

1. An interface library interfaceA_B_vA, which links against the
   interface libraries "interfaceA interfaceB ${libA}" and an
   executable, which links only against interfaceA_B_vA. For that
   executable, I get the link order "B A"
2. Suppose one tries to correct that and link explicitly against with
   the variable. Such an executable which links as "${libA}
   interfaceA_B_vA". In that case, I got the link order "A A B". So we
   have a changed order compared to the previous experiment.
3. If I use the imported libraries instead of the variables from
   experiment 1, I get the link order A B A, as expected.

From these experiments, I got the impression, that

1. linking through variables remains a nightmare. That is nothing new.
2. interface libraries might change their order
3. imported libraries lead to a more stable link order?

I hope somebody could shed some light in this behavior.

Best regards,
Andreas


Am 18.10.19 um 18:24 schrieb Fred Baksik:



On Fri, Oct 18, 2019, at 11:55 AM, Fred Baksik wrote:


In target_link_libraries it states that "The library dependency graph
is normally acyclic (a DAG)".  I recall from my own experience that
the DAG is not always created the same way when generating the
project.  It has to do with the way with this part of CMake is
implemented (C++ containers and that sort of thing) so while all the
inputs are the same the order is Not the same so it produces a
different DAG which changed the ordering of the components build
order which also altered the link order.

For the GHS Generator to ensure that the exact same project files are
output we sorted the components by name into a vector first (instead
of just using a set) before supplying it to this algorithm.  Then the
results were always the same.



Sorry, I wanted to clarify this a bit.  The DAG is correct. For
example lets say A depends on B and C and then C on D.  This DAG
always comes out the same.  But when you try to extract the dependents
of A it sometimes returns something that will give you B then C or C
then B when accessing them in a linear order. So there were
differences if you inspected these items with the debugger.

When I ran across these kinds of things with the GHS Generator we sort
things in lexicographical order to produce the same results every time.

Best regards,
Fred



project(testLinkOrder)
cmake_minimum_required(VERSION 3.5)

file(WRITE "simpleProg.cc" "int main() { return 0; }")
set(libA "${CMAKE_BINARY_DIR}/A.a")
file(WRITE "${libA}" "i am not a library")

set(libB "${CMAKE_BINARY_DIR}/B.a")
file(WRITE "${libB}" "i am not a library")

add_library(impA IMPORTED STATIC)
set_target_properties(impA PROPERTIES IMPORTED_LOCATION ${libA})

add_library(impB IMPORTED STATIC)
set_target_properties(impB PROPERTIES IMPORTED_LOCATION ${libB})

add_library(interfaceA INTERFACE)
target_link_libraries(interfaceA INTERFACE ${libA})

add_library(interfaceB INTERFACE)
target_link_libraries(interfaceB INTERFACE ${libB})
#target_link_libraries(interfaceA INTERFACE ${libB})

add_library(interface_A_B_vA INTERFACE)
target_link_libraries(interface_A_B_vA INTERFACE interfaceA interfaceB ${libA})

add_executable(linkInterface_A_B_vA simpleProg.cc)
target_link_libraries(linkInterface_A_B_vA interface_A_B_vA)

add_executable(linkvA_IABAVA simpleProg.cc)
target_link_libraries(linkvA_IABAVA ${libA} interface_A_B_vA)

add_library(interface_impA_impB_vA INTERFACE)
target_link_libraries(interface_impA_impB_vA INTERFACE impA impB ${libA})

add_executable(linkInterface_impA_impB_vA simpleProg.cc)
target_link_libraries(linkInterface_impA_impB_vA interface_impA_impB_vA)
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at

Re: [CMake] How to specify Redhat Developer Toolset compiler?

2019-06-20 Thread Andreas Naumann


You could set the environment variables CXX and CC such that they point
to your toolset compiler

Am 20.06.19 um 17:39 schrieb David Aldrich:

My Centos 7.6 machine has CMake 3.13.5 and g++ 4.8.5 installed:

$ /usr/bin/x86_64-redhat-linux-g++ --version
x86_64-redhat-linux-g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

I have a very simple CMakeLists.txt:

cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
project(hello_world LANGUAGES CXX)

add_executable(hello_world "")

target_sources(hello_world
  PRIVATE
    main.cpp
    Message.hpp
    Message.cpp)

I also have Redhat Developer Toolset 7 installed which I can enable in
my bash shell:

$ scl enable devtoolset-7 bash
$ which g++
/opt/rh/devtoolset-7/root/usr/bin/g++
$ g++ --version
g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)

How can I get CMake to use the later version of g++ instead of 4.8.5?




--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How can I automatically optionally build a submodule?

2019-03-27 Thread Andreas Naumann


For me, this sounds more like foo is an independent thing and not a
subdirectory.

In this case, I think about two solutions:
    1) Use a macro/function "check_yada", which sets a variable
"yada_usable". If you extract this logic in an extra .cmake file, you
can reuse it in your yada CMakelists.txt
    2) Use foo as an external project. But thats looks like a major
change in the project structure.


Am 27.03.19 um 20:05 schrieb Steve Keller:

"Albrecht Schlosser"  wrote:


If you want yadda to be optional then don't use REQUIRED.

find_package(yadda)
if (yadda_FOUND)
message(STATUS "found yadda, building bar ...")

# add your code to build bar here

endif ()

This should do what you want - unless I misunderstood your question.

This will roughly do what I want, but I think it does not correctly
express things.  For the sub-project, yadda is not optional, and if I
call cmake in that sub-project's directory, it should fail.

What I think would be appropriate would be a command
add_subdirectory_optional(...) or add_subdirectory_and_ignore_errors(...)
or something similar.

Steve



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Correct Boost version found, linked against wrong one

2019-03-12 Thread Andreas Naumann


Hey Florian,


Am 12.03.19 um 13:53 schrieb Florian Lindner:

Hello,

I have a simple cmake file for a small project. That project uses boost and 
links again a shared lib that also uses boost:

find_library(precice precice PATHS $ENV{PRECICE_ROOT}/build 
$ENV{PRECICE_ROOT}/build/last)
find_package(Boost 1.60.0 REQUIRED COMPONENTS system program_options filesystem)

add_executable(preciceMap src/preciceMap.cpp src/common.cpp)
target_include_directories(preciceMap PRIVATE ${Boost_INCLUDE_DIRS})
target_link_libraries(preciceMap ${Boost_LIBRARIES})
target_link_libraries(preciceMap ${precice})

output is:


:~/software/aste/build> cmake ..
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Cray Programming Environment 2.5.17 C
-- Check for working C compiler: /opt/cray/pe/craype/2.5.17/bin/cc
-- Check for working C compiler: /opt/cray/pe/craype/2.5.17/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Cray Programming Environment 2.5.17 CXX
-- Check for working CXX compiler: /opt/cray/pe/craype/2.5.17/bin/CC
-- Check for working CXX compiler: /opt/cray/pe/craype/2.5.17/bin/CC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build configuration: Debug
CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message):
   Imported targets not available for Boost version 106600
Call Stack (most recent call first):
   /usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
   /usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES)
   CMakeLists.txt:21 (find_package)


CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message):
   Imported targets not available for Boost version 106600
Call Stack (most recent call first):
   /usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
   /usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES)
   CMakeLists.txt:21 (find_package)


CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message):
   Imported targets not available for Boost version 106600
Call Stack (most recent call first):
   /usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
   /usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES)
   CMakeLists.txt:21 (find_package)


-- Boost version: 1.66.0
-- Found the following Boost libraries:
--   system
--   program_options
--   filesystem
-- Found MPI_C: /opt/cray/pe/craype/2.5.17/bin/cc
-- Found MPI_CXX: /opt/cray/pe/craype/2.5.17/bin/CC
-- Configuring done
-- Generating done
-- Build files have been written to: 
/zhome/academic/HLRS/ipv/ipvflind/software/aste/build

:~/software/aste/build> make
Scanning dependencies of target preciceMap
[ 20%] Building CXX object CMakeFiles/preciceMap.dir/src/preciceMap.cpp.o
[ 40%] Building CXX object CMakeFiles/preciceMap.dir/src/common.cpp.o
[ 60%] Linking CXX executable preciceMap
/usr/bin/ld: warning: libboost_system.so.1.66.0, needed by 
/zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so, 
may conflict with libboost_system.so.1.54.0
/usr/bin/ld: warning: libboost_filesystem.so.1.66.0, needed by 
/zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so, 
may conflict with libboost_filesystem.so.1.54.0
/usr/bin/ld: warning: libboost_program_options.so.1.66.0, needed by 
/zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so, 
may conflict with libboost_program_options.so.1.54.0
/usr/bin/ld: CMakeFiles/preciceMap.dir/src/common.cpp.o: undefined reference to 
symbol '_ZN5boost15program_options3argB5cxx11E'
/opt/hlrs/tools/boost/1.66.0/lib/libboost_program_options.so.1.66.0: error 
adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
CMakeFiles/preciceMap.dir/build.make:124: recipe for target 'preciceMap' failed
make[2]: *** [preciceMap] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/preciceMap.dir/all' 
failed
make[1]: *** [CMakeFiles/preciceMap.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2



CMake finds boost 1.66 but why does it try to link against 1.54.0? $BOOST_ROOT 
is set and $LIBRARY_PATH, $LD_LIBRARY_PATH and $CPLUS_INCLUDE_PATH are also set 
appropriately.

:~/software/aste/build> ls $BOOST_ROOT/lib/*filesystem*
/opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.a  
/opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.so  
/opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.so.1.66.0

:~/software/aste/build> ls /usr/lib64/*filesystem*
/usr/lib64/libboost_filesystem-mt.so  /usr/lib64/libboost_filesystem.so  
/usr/lib64/libboost_filesystem.so.1.54.0

Maybe it prefers the -mt variants? But how can I get it to link against the 
correct

Re: [CMake] Question about functions

2019-02-18 Thread Andreas Naumann


Am 18.02.19 um 20:43 schrieb workbe...@gmx.at:

Hi everyone,

i have a function like:

FUNCTION(checksyste_64Bit arg1)

    IF(CMAKE_SIZEOF_VOID_P EQUAL 8)

        SET(${arg1} TRUE PARENT_SCOPE)

ENDFUNCTION()


but when i call it with an INTERNAL variable i've set before with

SET(SYSTEM_64BIT FALSE CACHE INTERNAL)

checksystem_64bit(${SYSTEM_64BIT})

the ${SYSTE_64BIT} variable stays the same, i thought when i use 
PARENT_SCOPE on a variable i can change it's value from inside the 
function ?



best regards!

You should call your function without dollar and braces around the 
variable, i.e.


  checksystem_64bit(SYSTEM_64BIT)

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] fixup-bundle usability

2019-02-18 Thread Andreas Naumann

lifies the linking and will load the
best library at runtime depending on the hardware. Fixup_bundle() will
copy only mkl_rt and you have to copy the other mkl libraries to
avoid runtime error.
Fixup bundle is tricky to put in place, but having a fixed list
of libraries to copy is even more cumbersome and flaky. When
supplied with the proper directories, the bundle is right every time.
Francis
Le sam. 16 févr. 2019 à 04:04, Andreas Naumann 
mailto:andreas-naum...@gmx.net>> a écrit :


Dear CMakers,

recently I tried to bundle an application in Windows. From the
documentation [1] I see that I should provide the directories to the
non-system libraries.

But these information should be already in the properties of the
targets, arent they? Is there any extension in cmake, that provides
these paths?

How do other users handle dependencies to external dlls?


[1] https://cmake.org/cmake/help/v3.0/module/BundleUtilities.html

Regards,
Andreas

-- 


Powered by www.kitware.com <http://www.kitware.com>

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community.
For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

--
Francis Giraldeau



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about set

2019-02-18 Thread Andreas Naumann


Hey,

I would introduce a list with the allowed values and introduce a macro 
"checked_set", which tests the setting or aborts.


Regards,
Andreas

Am 18.02.19 um 15:06 schrieb workbe...@gmx.at:

Hi everyone,

i've looked the web but found no result. I need a string variable that 
allows only certain values, like bool variables only allow true/false 
my string should be either "A" or "B" ...



best regards!



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Static libraries depending on libraries: only on headers/options/defines

2019-02-16 Thread Andreas Naumann


Hi Paul,

I understand the relationship between libraries as strict, such that you 
always build all dependent libraries before.
In your use case I thought about splitting the libraries in the actual 
target and the interface one.

For example, you could create an interface library foo_interface
add_library(foo_interface INTERFACE )
set the properties and then link foo and bar to this interface library 
using target_link_libraries.


But be aware, that now every executable, which links against bar must 
manually link against foo. If your project is large, this seems not 
really desirable. But I think you could also split the library bar in 
two bar_withoutFoo and bar. The library bar_withoutFoo would link 
against foo_interface and compile the sources, whereas bar is an 
interface library which depends on bar_withoutFoo and foo.
The developer could than build bar completely independent from foo and 
you could transport the transitive dependencies to the executable.


I don't know if this doubled structure using pure interfaces libraries 
and the actual libraries is maintainable.


Hope that helps a bit,
Andreas

Am 16.02.19 um 20:20 schrieb Paul Smith:

Hi all;

I'm working on modernizing our large complex CMake environment.  It
builds a number of different binaries from an even larger number of
static libraries, and these libraries depend on each other as well, in
that they need to include headers and, sometimes, -D options etc.

I've used straightforward target_link_libraries() to declare the
relationship between these libraries; for example:

   add_library(foo STATIC ...)
   target_include_directories(foo PUBLIC ...)
   target_compile_definitions(foo PUBLIC ...)
   target_compile_options(foo PUBLIC ...)

   add_library(bar STATIC ...)
   target_link_libraries(bar PUBLIC foo)

   add_executable(one ...)
   target_link_libraries(one PRIVATE bar)

This works, in that everything builds properly but it has a side-effect
we want to avoid.  Because the source tree is large many developers
have a habit of testing compilation of subsets of the code using
something like:

   make -jX bar

and expect it to just build the static library bar.  Because it's a
static library you don't need to actually build "foo" until link time.
But we do need all the include directories, compile definitions, and
compile options to be inherited from "foo" into "bar".

However with the above formulation, building "bar" also forces the
compilation of "foo", which we don't need or want.

I've played around with the different values of PUBLIC, PRIVATE, and
INTERFACE but there doesn't seem to be a straightforward way to say,
"take the interface values for includes, definitions, and options, but
don't depend on the generated target".

I can write a function to do this myself but this seems like the most
common way someone would want to treat static libraries referencing
other static libraries, so I wondered if I was missing something that would 
allow this in a simpler way.

Thanks!



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] fixup-bundle usability

2019-02-16 Thread Andreas Naumann


Dear CMakers,

recently I tried to bundle an application in Windows. From the 
documentation [1] I see that I should provide the directories to the 
non-system libraries.


But these information should be already in the properties of the 
targets, arent they? Is there any extension in cmake, that provides 
these paths?


How do other users handle dependencies to external dlls?


[1] https://cmake.org/cmake/help/v3.0/module/BundleUtilities.html

Regards,
Andreas

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How is ARGN passed to a macro

2018-11-21 Thread Andreas Naumann


Hey Torsten,

Am 21.11.18 um 13:15 schrieb Torsten Robitzki:

Hi,
I’ve stumbled over following behavior and now I’m searching for the rules, that 
explains that behavior:

test.cmake:

   macro(check_argn)
 message("in macro check_argn ARGN: ${ARGN}")

 if(ARGN)
   foreach(item IN LISTS ARGN)
 message("ARG: ${item}")
   endforeach(item)
   message("ARGN: ${ARGN}")
 endif()
   endmacro()

   function(f1 a)
 message("in function ARGN: ${ARGN}")
 check_argn()
   endfunction()

   f1(1)
   f1(1 2)

This will yield the following output:

   $ cmake -P ./test.cmake
   in function ARGN:
   in macro check_argn ARGN:
   in function ARGN: 2
   in macro check_argn ARGN:
   ARG: 2
   ARGN:

I would expect ARGN to behave exactly the same in the macro, as in the 
function, but apparently there is a difference. Can someone of you explain that 
to me?


I think the behavior is explained in [1] and [2]. In particular the 
second section of [2] states that the parameter " [...] such as ARGN are 
not variables in the usual CMake sense. They are string replacements 
[...]".  And the example at the end of [2] seems to match your test 
perfectly.


Hope that helps a bit,
Andreas

[1] https://cmake.org/cmake/help/latest/command/function.html

[2] https://cmake.org/cmake/help/latest/command/macro.html



TIA and kind regards,

Torsten



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Moving static library to separate project

2018-09-26 Thread Andreas Naumann


Dear Chris,

you have several ways to cope with that.
First, you should write a MyLogConfig.cmake-File [2], which imports your 
static library as import library [1] and sets the include path. The same 
file also defines the dependency on pthread via target_link_library.
Your project with the executable then uses find_package(MyLog ) to 
insert the library into the project.


The second way uses the install(Export ...) directive to create export 
files. These files contain the transitivie dependencies and the include 
paths at once. In this case, your executable project has to use the 
export-File via find_file / input.


Hope that helps a little bit,
Andreas


[1] https://cmake.org/cmake/help/v3.5/command/add_library.html
[2] https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html

Am 25.09.2018 um 23:58 schrieb Christopher E Robison:
I've got a situation I've searched for answers on, and though I've 
found similar questions, I've found no generally-applicable answers, 
or at least ones I can use. Apologies in advance for a beginner-level 
question.


I have a group of applications that all use some common functionality 
I've located in a static library (for logging in this case). we'll 
call it libmylog here. Libmylog is pretty simple, but at some point I 
wanted to solve some thread safety situations, so I included some 
synchronization features that now require me to link with pthreads. 
Easy enough, "target_link_libraries(mylog pthread)" takes care of it.


I've recently begun developing a separate application which doesn't 
belong in the same tree, and so I've put it in its own new project. 
I've decided I'd like this new application to use libmylog as well, 
and so now I've moved mylog into its own separate project too. I've 
added install directives and the library (libmylog.a) and its header 
file end up in the correct spots in /usr/local when I do a "make 
install". Looks good so far.


The problem is when I compile any of my executables, the link fails 
with undefined reference errors since after removing libmylog from the 
same build tree every application I've written that uses it must now 
link with libpthread as well. This is an odd thing to have to specify 
for small utilities that don't have threads and shouldn't need to care 
about them. I look at libmylog.a with nm and all the references to 
pthreads symbols are undefined.


More critically, it seems that since the build process for libmylog 
doesn't generate an executable, the "target_link_libraries(mylog 
pthread) line is now _silently ignored_.


What is the Right Way of dealing with this in CMake? I'd like a way to 
tell the linker to force the inclusion of the relevant code in the 
static library, but if there's a more canonical approach I'd 
appreciate the advice. (For example, do I need to [learn how to] 
create a CMake "package" for my libmylog installation -- would this 
help propagate the -lpthread requirement to the build for the 
executables?)



Thanks!
Chris










--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Beginners Guide to Cmake and Modern Cmake

2018-07-27 Thread Andreas Naumann


Dear space & and the rest of the cmake world :)

i just googled for "modern cmake" and came up with at least two 
interesting talks from cppcon and boostcon:

https://www.youtube.com/watch?v=bsXLMQ6WgIk=youtu.be=37m15s
    https://www.youtube.com/watch?v=eC9-iRN2b04
Their slides can be found at
https://github.com/CppCon/CppCon2017/blob/master/Tutorials/Using%20Modern%20CMake%20Patterns%20to%20Enforce%20a%20Good%20Modular%20Design/Using%20Modern%20CMake%20Patterns%20to%20Enforce%20a%20Good%20Modular%20Design%20-%20Mathieu%20Ropert%20-%20CppCon%202017.pdf
https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf

I just slipped through them, but they look like the right way. Another 
nice summary is at 
https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1#file-effective_modern_cmake-md


Wish you a nice weekend,
Andreas


Am 27.07.2018 um 01:54 schrieb Space:

Dear Cmake world,

I am wanting to learn how to use Cmake correctly and I would like to
implement Modern Cmake (the latest version and techniques).

Currently I have a project that was intended for use on windows machine but
I want to run/develop it on Mac and am also interested to make it overall
cross platform. On Mac I'll use Visual Studio Code and Xcode (preferably
VSC).

Here is a link to the GitHub for the current project of interest:
https://github.com/AcademyOfInteractiveEntertainment/aieBootstrap

Dependencies are:
 glfw
 glm
 imgui
 stb
 openGL (gl_core_4_4.c/h)

I have visited the cmake.org site and looked at the tutorials, they teach
old cmake 2.8 but shouldn't there be material that teaches the Modern way.

I know about the documentation that has made an effort to show some of the
modern practices but to a person, new to cmake, my brain just shuts down to
the reference styled documents, and yes, but thats what the documentation
is; a reference list.

I then found the webinars, but much disappoint, they are dated back to March
2012 ( a great effort for its time but left me confused; not modern).

We are now end of July 2018. It would be great to see a webinar completely
refreshed, which is directed at the complete beginner and makes an effort to
teach Modern Cmake in todays world. It would also be nice to understand how
to bridge the gap between old 2.8 cmake and the latest cmake. For example:
Making proper use of find_package etc...

I hope this is an interesting topic to be reviewed,

regards,

Space





--
Sent from: http://cmake.3232098.n2.nabble.com/



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] conditions and included subprojects

2018-06-11 Thread Andreas Naumann

I think, I missunderstood some parts. In particular, why should the user have to change the CMakeLists.txt? He/she can set the value at the commandline or in the cmake-gui and your CMakelist sees the value of your option and can react to that.

Gesendet: Montag, 11. Juni 2018 um 10:55 Uhr
Von: "Cornelis Bockemühl"
An: "Andreas Naumann" , cmake@cmake.org
Betreff: Re: [CMake] conditions and included subprojects

Thanks for your proposals!

Actually my problem is basically that I want to keep up with some minimum good practice, but I am seeing myself throwing it over board constantly if I do not find a logical solution after one or two hours of struggling...

Your second option is close to what I am currently implementing - basically just hard-code the option into the sub-project and let the user adapt the CMakeLists.txt before starting cmake. A bit "brute force", not nice, certainly not "good practice" - but works!

However, what I imagine is rather like this - from a user perspective:

- if the user goes into the main project with cmake-gui, he will see THAT_OPTION with a default value and of course the option to change it. In this case, the sub-project should be built without further bothering the user with options - just take it from the main project. The point is that the option will have an effect for both the main and the sub project, but it has to be the same in both.

- if the user goes directly into the sub project with cmake-gui, he should also see THAT_OPTION, but now it would come from the CMakeLists.txt of the sub project. Again with a default value and the option to change it.

My guess is that I would need an additional "flag" variable that tells the sub project whether it is now being built within the main project or standalone. Again not so nice, but besides the "brute force solution" (hardcoded) the only one that I can see to do it more nicely...

Regards,

Cornelis

Am Montag, den 11.06.2018, 10:44 +0200 schrieb Andreas Naumann:

Dear Cornelis,

your description looks to me like having a three valued option: ON, OFF, UNDEFINED. But an option in cmake language has only two values: ON or OFF.

To solve your problem with the connection between your sub-project and the main project, you should forget about the main project and concentrate on the sub project only. Than, you have two possibilities:

1) Keep the three state variable "THAT_OPTION". Set it to undefined at the very beginning and check later with if(DEFINED THAT_OPTION) With this variant, you can handle the "I forgot to set it"-case. But your user will not see it as an option in the cmake gui. Your main project will set it, as desired.

2) Use an initial value for the option. Now, it is always defined, there is no need to check for the source. It is the responsibility of the user to set the option appropriately.

I think, the second version is the easiest way.

Regards,

Andreas

Gesendet: Montag, 11. Juni 2018 um 10:20 Uhr
Von: "Cornelis Bockemühl"
An: cmake@cmake.org
Betreff: [CMake] conditions and included subprojects

Dear CMake users,

Maybe my question is trivial for most, but still I do not find an answer on my own!

If you have a project and some sub-project (or module or whatever the jargon is) that are both managed with CMake, they should be in separate directories (directory trees), and each of them have a CMakeLists.txt in the root directory, where the sub-project is "included" into the main project with an ADD_DIRECTORY() etc. So far so clear.

But then I learned that it is good practice to ensure that the sub-project would also be "buildable" with cmake separately. My problem is about how to pass options from the main to the sub project in such a way that this is working properly, i.e.:

- if the sub project is part of the main project it would simply take over the option from the main project level

- but if the sub project is being built standalone, the option is not defined and should be set e.g. in cmake-gui

If I write now in the sub project

IF(THAT_OPTION)

...

this will be true if THAT_OPTION was set to ON in the main project. So far so good. But the _expression_ is now so "clever" that it cannot distinguish between THAT_OPTION being set to OFF in the main project, or THAT_OPTION not being defined at all - like in a standalone build!

One way would be to have an additional option or variable BUILDING_MAINPROJECT which is set to ON or TRUE in the main project and can be checked. However, I have so far not seen any CMakeLists.txt with such a code, so ... what are the experts doing in such a case?

Thanks and regards,

Cornelis

-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake commu

Re: [CMake] conditions and included subprojects

2018-06-11 Thread Andreas Naumann

Dear Cornelis,

your description looks to me like having a three valued option: ON, OFF, UNDEFINED. But an option in cmake language has only two values: ON or OFF.

2) Use an initial value for the option. Now, it is always defined, there is no need to check for the source. It is the responsibility of the user to set the option appropriately.

I think, the second version is the easiest way.

Regards,

Andreas

Gesendet: Montag, 11. Juni 2018 um 10:20 Uhr
Von: "Cornelis Bockemühl"
An: cmake@cmake.org
Betreff: [CMake] conditions and included subprojects

Dear CMake users,

Maybe my question is trivial for most, but still I do not find an answer on my own!

- if the sub project is part of the main project it would simply take over the option from the main project level

- but if the sub project is being built standalone, the option is not defined and should be set e.g. in cmake-gui

If I write now in the sub project

IF(THAT_OPTION)

...

Thanks and regards,

Cornelis

-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] problem with CMake not including library's path (with pkg-config)

2018-05-24 Thread Andreas Naumann


Dear Francesco,

I use the pkg-config module with IPopt and had the same problem. 
According to the documentation, the library paths are in 
_LIBRARY_DIRS. In your case, you should find the paths in the 
variable AGG_LIBRARY_DIRS or all flags in the variable  AGG_LDFLAGS .


Regards,
Andreas
Am 24.05.2018 um 18:48 schrieb Francesco Abbate:

Hi all,

I stumbled in a problem with CMake. Everything is working fine except
that, for two libraries that I locate with pkg-config, cmake does not
include during linking the library's path (-L) which is given by
pkg-config.


Here an extract of the CMakeLists.txt:


[...]

include(FindPkgConfig)
pkg_search_module(AGG REQUIRED libagg)

[...]

target_link_libraries(libcanvas ${AGG_LIBRARIES})
target_include_directories(libcanvas PUBLIC
${PROJECT_SOURCE_DIR}/include ${AGG_INCLUDE_DIRS})
[...]

When I run pkg-config everything is correct:


pkg-config --libs libagg

-Lc:/fra/local_msys64/lib -lagg -lm

One can notice that pkg-config provides a non-standard path for the library.

By inspecting CMakeCache.txt I found a trace of the library's path.
See below an extract:

AGG_CFLAGS:INTERNAL=-Ic:/fra/local_msys64/include/agg2
AGG_CFLAGS_I:INTERNAL=
AGG_CFLAGS_OTHER:INTERNAL=
AGG_FOUND:INTERNAL=1
AGG_INCLUDEDIR:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_INCLUDE_DIRS:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_LDFLAGS:INTERNAL=-Lc:/fra/local_msys64/lib;-lagg;-lm
AGG_LDFLAGS_OTHER:INTERNAL=
AGG_LIBDIR:INTERNAL=c:/fra/local_msys64/lib
AGG_LIBRARIES:INTERNAL=agg;m
AGG_LIBRARY_DIRS:INTERNAL=c:/fra/local_msys64/lib
AGG_LIBS:INTERNAL=
AGG_LIBS_L:INTERNAL=
AGG_LIBS_OTHER:INTERNAL=
AGG_LIBS_PATHS:INTERNAL=
AGG_PREFIX:INTERNAL=c:/fra/local_msys64
AGG_STATIC_CFLAGS:INTERNAL=-Ic:/fra/local_msys64/include/agg2
AGG_STATIC_CFLAGS_I:INTERNAL=
AGG_STATIC_CFLAGS_OTHER:INTERNAL=
AGG_STATIC_INCLUDE_DIRS:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_STATIC_LDFLAGS:INTERNAL=-Lc:/fra/local_msys64/lib;-lagg;-lm
AGG_STATIC_LDFLAGS_OTHER:INTERNAL=
AGG_STATIC_LIBDIR:INTERNAL=
AGG_STATIC_LIBRARIES:INTERNAL=agg;m
AGG_STATIC_LIBRARY_DIRS:INTERNAL=c:/fra/local_msys64/lib
AGG_STATIC_LIBS:INTERNAL=
AGG_STATIC_LIBS_L:INTERNAL=
AGG_STATIC_LIBS_OTHER:INTERNAL=
AGG_STATIC_LIBS_PATHS:INTERNAL=
AGG_VERSION:INTERNAL=2.5.0
AGG_libagg_INCLUDEDIR:INTERNAL=
AGG_libagg_LIBDIR:INTERNAL=
AGG_libagg_PREFIX:INTERNAL=
AGG_libagg_VERSION:INTERNAL=

but in the Ninja build file the library's path is not given (below an extract):

--
#
# Link the executable tests\test-window.exe

build tests/test-window.exe: CXX_EXECUTABLE_LINKER__test-window tests/CMakeFiles
/test-window.dir/test-window.cpp.obj | win32/liblibcanvaswin32.a src/liblibcanva
s.a || src/liblibcanvas.a win32/liblibcanvaswin32.a
   LINK_LIBRARIES = win32/liblibcanvaswin32.a src/liblibcanvas.a -lagg
-lm -lfreetype -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32


So the behavior of CMake looks wrong to me. Pkg-config is giving
explicitly a non-standard library path but CMake just decided to not
include it in the linker options.

To finish let me report that I'am using CMake 3.11.1 on a Windows
system using MSYS2.

I can also mention that a similar Meson build just works fine but this
is only to make you, CMake guys, jealous.

Ok, just kidding :-)

Thank you in advance for any help.

Kind regards
Francesco







--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake does not find module, though it's in MODULE_PATH

2018-05-07 Thread Andreas Naumann


Dear Florian,

 

please note, that CMake expects the variable CMAKE_MODULE_PATH not as an environment variable, but as a CMake variable. So, you could do something like

set(CMAKE_MODULE_PATH $ENV{CMAKE_MODULE_PATH})

before calling find_package(Eigen3)

 

But there are other ways, according to stackoverflow https://stackoverflow.com/questions/12249140/find-package-eigen3-for-cmake .

 

Regards,

Andreas

 

Gesendet: Montag, 07. Mai 2018 um 11:28 Uhr
Von: "Florian Lindner" 
An: "cmake@cmake.org" 
Betreff: [CMake] CMake does not find module, though it's in MODULE_PATH

Hello,

my CMake 3.6.2 complains about not finding FindEigen3.cmake

CMake Error at CMakeLists.txt:62 (find_package):
By not providing "FindEigen3.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Eigen3", but
CMake did not find one.

Could not find a package configuration file provided by "Eigen3" with any
of the following names:

Eigen3Config.cmake
eigen3-config.cmake

Add the installation prefix of "Eigen3" to CMAKE_PREFIX_PATH or set
"Eigen3_DIR" to a directory containing one of the above files. If "Eigen3"
provides a separate development package or SDK, be sure it has been
installed.

However, it's clearly there in ls $CMAKE_MODULE_PATH/FindEigen3.cmake

I try to use it like find_package(Eigen3 REQUIRED)

What else could be wrong there?

Thanks!

Florian
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake



-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] FindMPI & policy CMP0004

2018-03-12 Thread Andreas Naumann

Thank you for the hint, and I run in a similiar problem. Building from 
scratch solved the issue.


Sorry for the noise.

Am 11.03.2018 um 23:07 schrieb Craig Scott:
This could be a case of needing to clear out an old CMake cache. That 
problem you mentioned was supposed to have been fixed already. You can 
find the updated discussion of the Mantis issue you linked to in 
gitlab here 
<https://gitlab.kitware.com/cmake/cmake/issues/11881> where someone 
else had a situation that sounds similar to yours.



On Mon, Mar 12, 2018 at 7:16 AM, Andreas Naumann 
<andreas-naum...@gmx.net <mailto:andreas-naum...@gmx.net>> wrote:


Dear all,

recently, I got a problem with FindMPI on our HPC systems. With
cmake 3.10.2, I get an error about policy CMP0004. And I cannot
set it to OLD anymore. Is this intended?

Exactly the same error, together with a patch, is described in the
bugtracker https://public.kitware.com/Bug/view.php?id=11881
<https://public.kitware.com/Bug/view.php?id=11881>

I cannot reproduce the error easiliy. On my home system, it works.
But on the hpc system, mpicc -showme:link returns
-L/lib -lmpi -ldl -lm -lnuma -Wl,--export-dynamic -lrt
-lnsl -lutil -lm -ldl

so, we have exactly one -Wl, part and libraries
otherwise. It looks to me, that the patch from the bugtracker
should avoid the problem.
Can somebody confirm this finding?

The problem gets even worse with newercmake versions. With cmake
3.9, I can set policy cmp0004 to OLD, so FindMPI remains usable.
With newer cmake versions, ie. 3.10.2,  the policy setting seems
to get deprecated. So, the user won't get any way to use newer
cmake with such a bug.

What is the preferred way to resolve such an issue, when the
policy setting is not allowed anymore?

Regards,
Andreas
-- 


Powered by www.kitware.com <http://www.kitware.com>

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
<http://www.cmake.org/Wiki/CMake_FAQ>

Kitware offers various services to support the CMake community.
For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
<http://cmake.org/cmake/help/support.html>
CMake Consulting: http://cmake.org/cmake/help/consulting.html
<http://cmake.org/cmake/help/consulting.html>
CMake Training Courses: http://cmake.org/cmake/help/training.html
<http://cmake.org/cmake/help/training.html>

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
<https://cmake.org/mailman/listinfo/cmake>




--
Craig Scott
Melbourne, Australia
https://crascit.com


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] FindMPI & policy CMP0004

2018-03-11 Thread Andreas Naumann


Dear all,

recently, I got a problem with FindMPI on our HPC systems. With cmake 
3.10.2, I get an error about policy CMP0004. And I cannot set it to OLD 
anymore. Is this intended?


Exactly the same error, together with a patch, is described in the 
bugtracker https://public.kitware.com/Bug/view.php?id=11881


I cannot reproduce the error easiliy. On my home system, it works. But 
on the hpc system, mpicc -showme:link returns
-L/lib -lmpi -ldl -lm -lnuma -Wl,--export-dynamic -lrt -lnsl 
-lutil -lm -ldl


so, we have exactly one -Wl, part and libraries otherwise. It 
looks to me, that the patch from the bugtracker should avoid the problem.

Can somebody confirm this finding?

The problem gets even worse with newercmake versions. With cmake 3.9, I 
can set policy cmp0004 to OLD, so FindMPI remains usable. With newer 
cmake versions, ie. 3.10.2,  the policy setting seems to get deprecated. 
So, the user won't get any way to use newer cmake with such a bug.


What is the preferred way to resolve such an issue, when the policy 
setting is not allowed anymore?


Regards,
Andreas
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] RPATH for pkg-config

2018-01-03 Thread Andreas Naumann


What about using a FindPETSC-Module? Some hints are
*http://jacobmerson.com/2016/01/17/cmake-petsc2.html
*http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake

Regards,
Andreas

Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:

On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:

Hello,

How to ask cmake to add a library path (coming from pc file) to rpath ?

I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but still not
working. Can somebody help ?

more main.cpp

#include 

int main(int argc, char ** argv) {
PetscInitialize(, , NULL, "");
PetscFinalize();
return 0;
}


more CMakeLists.txt

cmake_minimum_required(VERSION 3.7)
enable_language(CXX)

find_package(MPI REQUIRED)
find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
pkg_check_modules(PETSc REQUIRED PETSc)

project(main)
add_executable(main main.cpp)

target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})

target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
foreach(lib ${PETSc_LDFLAGS})
target_link_libraries(main PUBLIC ${lib})
endforeach(lib)

How does each ${lib} look like ?
Is it "-lpetsc" or does it have the full path to the libraries ?
You should use the full path to the libraries, otherwise cmake doesn't know
where they are and the RPATH computation will not work.


foreach(dir ${PETSc_LIBRARY_DIRS})
link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
endforeach(dir)

no, link_directories() in general should not be used.


# use, i.e. don't skip the full RPATH for the build tree
SET(CMAKE_SKIP_BUILD_RPATH FALSE)
# when building, don't use the install RPATH already
# (but later on when installing)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")

If the automatic computation fails, you could add the petsc lib dir here as
INSTALL_RPATH

Alex



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] cmake-server, path length for pipe

2017-12-29 Thread Andreas Naumann


Hey cmakers,

I use visual studio code with the extension "vscode-cmake-tools" [1]. 
This extension uses the cmake-server functionality,

Recently, I have encountered the strange error message
[cmake-server] CMake Error: Internal Error with 
/release/.cmserver.18775: EADDRINUSE


where the length of longPath is 101 characters. The same error is also 
discussed in the issue 197 in [2].


After that, I did two small tests using the cmake server. Starting from 
the longPath above, I tried


cmake -E server --experimental --pipe=`pwd`/release/foo
and
cmake -E server --experimental --pipe=./release/foo

The first test led to the error, whereas the second one worked.

Is there a path length restriction for the cmake server?

And there is an error in the cmake-server manpage. The pipe argument is 
"--pipe= " instead of "--pipe "


I used cmake version 3.9.5.

Regards,
Andreas



[1] https://github.com/vector-of-bool/vscode-cmake-tools/
[2] https://github.com/vector-of-bool/vscode-cmake-tools/issues/197
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] absolute library path, sorry for the question

2017-12-23 Thread Andreas Naumann

your problem is hard to analyse. If you have a "minimal" example, which 
shows this behavior, we could test it. In your last mail, you wrote 
about building and installing libtiff using your own libjpeg. But than 
you write about a later build. So something must happen in the "later 
build".


Interesting enough, you said, that with newer systems, you do not have 
this problem. Do these old systems use a different cmake version?


Seasons Greetings,
Andreas
Am 22.12.2017 um 17:42 schrieb Mario Emmenlauer:

Can anyone help to force cmake use absolute paths?

On 13.12.2017 11:45, Mario Emmenlauer wrote:

Thank you for your reply!! Your explanation is very helpful for writing
my own CMakeLists.txt. But in my case, I use the standard CMakeLists.txt
that comes with the libraries. For example libtiff, turbojpeg, thrift,
and many others...

As an example, I build libtiff in the following way:
 cmake ../$TIFFVERSION \
 -Wno-dev \
 -G"Unix Makefiles" \
 -DCMAKE_PREFIX_PATH="$THIRDPARTYTARGETDIR" \
 -DCMAKE_INSTALL_PREFIX="$THIRDPARTYTARGETDIR" \
 -DCMAKE_BUILD_TYPE="Release" \
 -DBUILD_SHARED_LIBS="ON" \
 -Djpeg="ON" \
 -DJPEG_INCLUDE_DIR="$THIRDPARTYTARGETDIR/include" \
 -DJPEG_LIBRARY="$THIRDPARTYTARGETDIR/lib/libjpeg.so" && \
 make VERBOSE="1" && make install

In the build log, I can see that cmake detects the jpeg library to be
'$THIRDPARTYTARGETDIR/lib/libjpeg.so'. However, in the later build, the
Makefile links with '-ljpeg' instead of '$THIRDPARTYTARGETDIR/lib/libjpeg.so'.
And this in turn will make 'ld' use '/usr/lib/x86_64-linux-gnu/libjpeg.so'
instead of my thirdparty libjpeg.

So at some point between FindJPEG.cmake and the final Makefile, cmake
changed the JPEG_LIBRARIES variable from absolute to relative. And I can
not understand why or when this happens. The documentation also does not
help me, because it explains that this should happen 'if the full path is
not know or if the full path is one of the system library dirs' (see
https://cmake.org/pipermail/cmake/2015-September/061462.html). In my case,
I override to use jpeg with a known, existing path that is not a system
library.

All the best,

Mario




On 13.12.2017 11:12, Bo Zhou wrote:

Hi

CMAKE_SKIP_RPATH usually is used for the shared module which might want to have 
the customized distributed path such as within the application. According
personal experience on POSIX systems (Linux, UNIX, OSX), always enable 
CMAKE_SKIP_RPATH for the all local shared dependencies, and to the final 
distribution,
(if needed) put shared libraries into the lib folder of distribution.

According your description, I'm not sure how did you pick up your library into 
the application from CMake, usually we have to make sure the CMake always 
chooses
the libraries from 3rd-party directory not system or another places. In our 
system, it has a variable THIRDPARTY_DIR for command FIND_PATH() to locate the
folder which contains the all built libraries, then use HINTS and NAMES in the 
command FIND_PATH() and FIND_LIBRARY() to locate the correct paths for the
pre-built libraries, so the linking should be okay.

If everything has no error, but just the application always picks up the 
system's library not the 3rd-party libraries we prepared, one solution would add
another loader script for the application, from the loader script it appends 
the local lib folder to LD_LIBRARY_PATH, then launch the actual application
executable file. A lot of commercial application on Linux solve the similar 
issue by this way.

Wish my reply is helpful.

Thank you very much.

On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer > wrote:


 Dear cmake users,

 I have found good documentation on the cmake wiki about RPATH and
 its different variables, and also on the mailing lists. But somehow
 it still does not add up for me. Can you please help?

 I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
 amongst others. I build many standard libraries (like tiff and jpeg)
 into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
 them there. On newer Linux and Windows, cmake uses always the absolute
 path to those libraries, and everything works fine. But on older Linux
 like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
 library in the correct absolute thirdparty directory, and I can confirm
 this by printing the 'XXX_LIBRARIES' variable in the find script. But
 later the Makefile will link with '-lxxx' instead of the full path.
 This makes 'ld' use the system library instead!

 I completely fail to understand at what point cmake changes XXX_LIBRARIES
 from an absolute path to '-lxxx', for example for libjpeg.

 I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
 The only workaround I

Re: [CMake] Please update the documentation for execute_process

2017-08-25 Thread Andreas Naumann


Am 25.08.2017 um 16:12 schrieb Jeffrey Walton:

Below is a typical case for us
(https://github.com/weidai11/cryptopp/blob/master/CMakeLists.txt). If
it looks pretty shitty, it probably is. That's the best we have been
able to come up with based on the documentation.

Below is the example code. We don't know whether it should be:

set(SHELL_CMD sh)
set(SHELL_ARGS -c)
set(GREP_CMD egrep)
set(GREP_ARGS -i -c)

execute_process(COMMAND ${SHELL_CMD} ${SHELL_ARGS}
"${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} ${GREP_ARGS} "amd64"
OUTPUT_VARIABLE CRYPTOPP_AMD64
OUTPUT_STRIP_TRAILING_WHITESPACE)

Or:

COMMAND "${SHELL_CMD}", "${CMAKE_CXX_COMPILER}", "-dumpmachine", "2>&1"

Or:

COMMAND "${SHELL_CMD}" "${CMAKE_CXX_COMPILER}" "-dumpmachine" "2>&1"

Or:

set(SHELL_CMD sh)
set(GREP_CMD egrep)

execute_process(COMMAND ${SHELL_CMD} "-c" "${CMAKE_CXX_COMPILER}
"-dumpmachine" "2>&1"
COMMAND ${GREP_CMD} ${GREP_ARGS} "-i" "-c" "amd64"
OUTPUT_VARIABLE CRYPTOPP_AMD64
OUTPUT_STRIP_TRAILING_WHITESPACE)

And we certainly don't know what to do with "2>&1" because there is no example.

The documentation states
"If OUTPUT_VARIABLE or ERROR_VARIABLE are given the variable named will 
be set with the contents of the standard output and standard error pipes 
respectively. If the same variable is named for both pipes their output 
will be merged in the order produced


so I would suspect to use something like

execute_process(COMMAND "${CMAKE_CXX_COMPILER}"
"-dumpmachine" OUTPUT_VARIABLE output_dump ERROR_VARIABLE output_dump)

and then use a
if( output_dump MATCHES "amd64" )
..

endif()

block

Does that work?


Jeff

**

set(SHELL_CMD sh -c)
set(GREP_CMD egrep -i -c)

execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "amd64"
OUTPUT_VARIABLE CRYPTOPP_AMD64
OUTPUT_STRIP_TRAILING_WHITESPACE)

execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "x86_64"
OUTPUT_VARIABLE CRYPTOPP_X86_64
OUTPUT_STRIP_TRAILING_WHITESPACE)

execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "i.86"
OUTPUT_VARIABLE CRYPTOPP_I386
OUTPUT_STRIP_TRAILING_WHITESPACE)

# http://github.com/weidai11/cryptopp/issues/466
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "mingw32"
OUTPUT_VARIABLE CRYPTOPP_MINGW32
OUTPUT_STRIP_TRAILING_WHITESPACE)

# http://github.com/weidai11/cryptopp/issues/466
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "w64-mingw32"
OUTPUT_VARIABLE CRYPTOPP_MINGW64
OUTPUT_STRIP_TRAILING_WHITESPACE)

execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "x32"
OUTPUT_VARIABLE CRYPTOPP_X32
OUTPUT_STRIP_TRAILING_WHITESPACE)

execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "Aarch32"
OUTPUT_VARIABLE CRYPTOPP_AARCH32
OUTPUT_STRIP_TRAILING_WHITESPACE)

execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "Aarch64"
OUTPUT_VARIABLE CRYPTOPP_AARCH64
OUTPUT_STRIP_TRAILING_WHITESPACE)

# http://stackoverflow.com/q/12515462/608639
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "\\"
OUTPUT_VARIABLE CRYPTOPP_ARM
OUTPUT_STRIP_TRAILING_WHITESPACE)

execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "ARMHF"
OUTPUT_VARIABLE CRYPTOPP_ARMHF
OUTPUT_STRIP_TRAILING_WHITESPACE)

execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "ARM7L"
OUTPUT_VARIABLE CRYPTOPP_ARM7L
OUTPUT_STRIP_TRAILING_WHITESPACE)

# Fixup?
if ("${CRYPTOPP_MINGW64}" STREQUAL "1")
unset(CRYPTOPP_MINGW32)
endif()

# MinGW32
if ("${CRYPTOPP_MINGW32}" STREQUAL "1")
set(CRYPTOPP_I386 "1")
endif()
# OpenBSD and MinGW64
if ("${CRYPTOPP_X86_64}" STREQUAL "1" OR "${CRYPTOPP_MINGW64}" STREQUAL "1")
set(CRYPTOPP_AMD64 "1")
endif()
# arm7l is another 32-bit hard float machine. RPI-3 is arm7l on 64-bit hardware
if ("${CRYPTOPP_ARM}" STREQUAL "1" OR "${CRYPTOPP_ARM7L}" STREQUAL "1")
set(CRYPTOPP_ARMHF "1")
endif()


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

2017-07-12 Thread Andreas Naumann


Dear Rene,

cmake instrospects your compiler and asks for system directories. Only 
these system directories will be removed and the corresponding libraries 
will be linked by -l<...>. So, you should check your compiler and the 
environment. I had several problems years ago with the environment 
variable LIBRARY_PATH, which leads to such a behavior.


Regards,
Andreas
Am 12.07.2017 um 13:38 schrieb René J.V. Bertin:

Hi,

I have a target_link_libraries command that uses ${PNG_LIBRARIES} and thus 
*should* add something like `/path/to/libpng.so /path/to/libz.so` to the linker 
command. Instead, I am getting a linker command line that has `-lpng -lz`, 
which fails for me because the `/path/to` in question isn't on the standard 
library search path.

Is there a cmake feature that does this automatic conversion, and if so how can 
I turn it off?

Thanks,
René


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Cross project include/link pathing?

2017-02-10 Thread Andreas Naumann


Dear Chris,

your description looks like the perfect example for ExternalProject_add. 
Than, every library would be a project. Inside each library, it looks 
for its dependency using find_package() and exports 
the dependency chain.

Your CMakeLists.txt of the application than has two possibilities:
a) simply assume, that the library is installed in a (known) 
location -> use find_package as described above and proceed as is.
b) build the library as an external project. In this case, your 
application has to be an external project with dependency to the 
external project of the library.


Hope that helps you and describes at least the idea,

Andreas

Am 09.02.2017 um 22:26 schrieb Chris Johnson:

We've been using CMake for a couple of years for C++ application
building.  We effectively set up our CMake project structure once, and
mostly only change it to add new source files, etc.

Currently, all C++ source is checked out of our SVN repository into one
large tree.  This tree actually contains multiple applications.  Many,
but not all, depend on libraries which are also in this same source tree
checkout.  Executables are statically linked to the libraries.

Our source tree has grown to the point where this arrangement really
does not make sense, and is quite far from best practices.  We want to
move to a more project-oriented structure, where there will be multiple
projects, but where the libraries are still shared.

How do I go about this?

In particular, how do I structure each project to find the common,
shared (but statically linked) libraries?  I would assume that each
library itself or the collection of libraries would be a project, with a
top-level CMakeLists.txt file.

Note that each project could be installed in its own unique location in
its deployed VM or container, so placing the libraries into, say,
hard-coded /usr/local/lib is not a feasible solution for us.


Pictorially (use fixed width font for best results):
=

Current single source tree layout
-

.
|-- CMakeLists.txt
|-- application_1/
|   `-- CMakeLists.txt
|-- application_2/
|   |-- CMakeLists.txt
|   |-- util_1/
|   |   `-- CMakeLists.txt
|   |-- util_2/
|   |   `-- CMakeLists.txt
|   `-- util_3/
|   `-- CMakeLists.txt
`-- lib/
|-- CMakeLists.txt
|-- lib_1/
|   `-- CMakeLists.txt
`-- lib_2/
`-- CMakeLists.txt


Desired project-oriented layout
---

[Application 1 Project]
.
`-- CMakeLists.txt

[Application 2 Project]
.
|-- CMakeLists.txt
|-- util_1/
|   `-- CMakeLists.txt
|-- util_2/
|   `-- CMakeLists.txt
`-- util_3/
`-- CMakeLists.txt

[Libraries Project]
.
|-- CMakeLists.txt
|-- lib_1/
|   `-- CMakeLists.txt
`-- lib_2/
`-- CMakeLists.txt



Presently, all of the applications know where to find the library header
files, because they are all in the same tree.  When we run "cmake ." at
the root of the source checkout, CMake knows where everything is, and
correctly provides the include paths to C++ compiler.

Similarly, at link time, CMake has automatically determined where the
compiled static libraries are, and our CMakeLists.txt files only need
mention them by name.  CMake has been brilliant at making this kind of
stuff simple.

But how do I make CMake generate the correct include and link paths when
"cmake ." is run on some individual project's source code, when those
paths will be outside the current tree, i.e. elsewhere?


..chris




--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Platform-independent config package

2017-01-10 Thread Andreas Naumann


Dear Ghis,

the easiest long-term fix would be an own glmConfig.cmake file.
The command write_basic_package_version_file uses a template with those 
pointer checks. The glm-developers could simply copy the template to 
their source directory, remove the unneeded lines and run the 
configure_file command themself on the changed template.


The short solution for debian would be a patch file,which just 
uncomments the last 5 lines.


Regards,
Andreas

Am 10.01.2017 um 19:52 schrieb Ghislain Vaillant:

Dear all,

I am currently hit by an issue with the CMake detection of a 
header-only library [1]. The library is built on a 64-bit machine and 
packaged for all other architectures supported by Debian.


However, CMake detection fails on 32-bit platforms with the following 
error:


```
Any attempt to call `find_package(glm REQUIRED)` produces the following
error:

```
Could not find a configuration file for package "glm" that is
compatible with requested version "".

The following configuration files were considered but not accepted:

/usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit)
```

How can this be effectively solved? Can the bit-ness detection be 
dropped somehow? It should not be needed for a header-only target.


Cheers,
Ghis


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850277




--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Find Vulkan on 32 bit builds

2017-01-08 Thread Andreas Naumann


Hello,
Am 08.01.2017 um 07:22 schrieb Saad Khattak:

Hello,

When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio 
2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES} 
variables both point to the "Bin" folder for the Vulkan installation 
instead of the "Bin32" folder.


I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS 
...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a 
mistake setting up. The message does indeed print confirming that my 
pointer size is 4 and thus the current toolchain selected is 32 bit.


What's perplexing is that when I do a MESSAGE(STATUS 
${Vulkan_LIBRARY}) the path is:



D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib 


instead of


D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib 




It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake 
ignoring 32?


You should think the other way around: Why should cmake look in a 
special directory, when it finds a library with an appropriate name 
before this one?
This decision should be in the corresponding FindVulkan.cmake, i.e. the 
corresponding find_library call should be constrained to 
${VULKAN_DIR}/Bin32 in the 32bit case.





Regards,
Andreas
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] target_link_libraries is using relative path of library

2017-01-08 Thread Andreas Naumann


Hello,

on Linux cmake treats system directorys specially, i.e. those libraries 
are linked without any path.
Furthermore there are environment variables, whose content is added to 
the set of system directories.
I do not work on Windows, but your problem looks like a smiliar problem. 
Does some of the environment variables (except path) contain your 
directory?


Hope that helps,
Andreas

Am 08.01.2017 um 04:01 schrieb Saad Khattak:

Hello,

This is a very strange behavior I am encountering. I am using CMake 
3.7.1 with Visual Studio 2015. I have the following as part of a 
CMakeLists file:


find_library(glfw_LIB_D  glfw3_d ${glfw_LIBRARIES})
find_library(glfw_LIBglfw3   ${glfw_LIBRARIES})

When I do "message(STATUS ${glfw_LIB_D})" I get the full absolute 
path. However, when I add an executable that depends on the library:


add_executable(vk_test  src/vulkan_test.cpp  )
target_link_libraries(vk_test ${glfw_LIB_D})

CMake puts the relative path when I look at my project's project 
properties:


..\install\glfw\lib\glfw_d.lib

I also tried the following:

target_link_libraries(vk_test 
"${CMAKE_SOURCE_DIR}/install/glfw/lib/glfw_d.lib")


And it's still a relative path. Because of this issue, my project will 
not compile as Visual Studio is looking for the library in the 
incorrect folder.


I even set the following, thinking that somehow relative paths got set:

set(${CMAKE_USE_RELATIVE_PATHS} FALSE FORCE)

I still got the same relative path. What is going on?




--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Modifying the FindBoost.cmake module

2016-06-27 Thread Andreas Naumann


Hey,

if you would use the FindBoost.cmake module from cmake itself, you could 
set the environment variable BOOST_ROOT to the second path.


Regards,
Andreas

Am 28.06.2016 um 01:21 schrieb Sambeet Panigrahi:

Hi,
I  am using Cmake to build Orocos RTT. There is a FindBoost.cmake 
module available in the config directory which the project uses.Now I 
have got two boost installations one in

1)/usr/include/boost
2)~/NewRockPort/x86/Install/boost

The second installation is the one I want to use .However The 
find_package command always goes on to find the first installation. 
There is a section in the file


  SET(_boost_INCLUDE_SEARCH_DIRS
"$ENV{INSTALL_PREFIX}/boost/include/"
C:/boost/include
C:/boost
"$ENV{ProgramFiles}/boost/include"
"$ENV{ProgramFiles}/boost"
/sw/local/include
in which I have tried to set the second installation's address, but it 
always points to the first.I have also tried to set the second 
installation from environment but somehow it always detects the first 
installation.


What can I do to include the second installation in my project?

Regards
Sambeet




--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] subversion

2016-06-27 Thread Andreas Naumann

The discussion is interesting and ends with the question, whether the 
macro "Subversion_IS_WC" is usable. As I understand the other arguments are

*leave the FATAL_ERROR as default for backwards compatibility
*the suggested patch hides the error message if error_quite is set .
*calling svn info twice is felt to be a waste, if the result is 
desired anyway.

So, I would suggest to extend Erik Johanssons patch from 
http://www.mail-archive.com/cmake@cmake.org/msg26817.html by storingto  
the error message and svn error code in an extra variable.
Than, we have the ability to ignore errors due to "wrong" working 
directories and to analyze the error, if the user is interested in the 
error.
In my opinion, a hard fail is annoying, because the user is not able to 
recover from the error.

Regards,
Andreas

Am 27.06.2016 um 12:57 schrieb Marcel Loose:

See also https://cmake.org/Bug/view.php?id=10200

Cheers,
Marcel Loose.

On 27/06/16 09:23, Andreas Naumann wrote:
Thanks for the 6 year old hint. But obviously, the patch is not in 
any recent cmake version.
Therefore, I could use it in my own project and ship my own 
FindSubversion.cmake.. which is quite ugly.

*Gesendet:* Montag, 27. Juni 2016 um 03:11 Uhr
*Von:* Nagger <nag...@gmx.de>
*An:* cmake@cmake.org
*Betreff:* Re: [CMake] subversion
Am 24.06.2016 um 19:48 schrieb Andreas Naumann:

> At the moment, I check, if my directory is a working copy and if it is
> not, the version variable is not defined. In my oppinion, it would be
> better, if the macro from the subversion module would simply define a
> variable "is_working_directory" instead of failing hard.

See https://cmake.org/pipermail/cmake/2010-January/034862.html

--

Powered by www.kitware.com <http://www.kitware.com>

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For 
more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] subversion

2016-06-27 Thread Andreas Naumann


Thanks for the 6 year old hint. But obviously, the patch is not in any recent cmake version.

Therefore, I could use it in my own project and ship my own FindSubversion.cmake.. which is quite ugly.

 

Gesendet: Montag, 27. Juni 2016 um 03:11 Uhr
Von: Nagger <nag...@gmx.de>
An: cmake@cmake.org
Betreff: Re: [CMake] subversion

Am 24.06.2016 um 19:48 schrieb Andreas Naumann:

> At the moment, I check, if my directory is a working copy and if it is
> not, the version variable is not defined. In my oppinion, it would be
> better, if the macro from the subversion module would simply define a
> variable "is_working_directory" instead of failing hard.

See https://cmake.org/pipermail/cmake/2010-January/034862.html


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake



-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] subversion

2016-06-24 Thread Andreas Naumann


Dear cmake users,

I have a question if, and how, you use the Subversion module of cmake.
The module provides the macro Subversion_WC_INFO, which extracts 
information of a working copy. I use this information, to generate a sub 
minor revision number of my project.
If I checkout my project using svn, it works. But if I export it, the 
modules failes with a fatal error.
At the moment, I check, if my directory is a working copy and if it is 
not, the version variable is not defined. In my oppinion, it would be 
better, if the macro from the subversion module would simply define a 
variable "is_working_directory" instead of failing hard.

What do you think about this idea? How do you use the subversion module?
The patch would be easy, and I would send one to the developer mailing 
list, if desired.


Regards,
Andreas
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Freetype on linux systems in non-standard directories

2016-06-07 Thread Andreas Naumann


Hey Kristian,

as the documentation 
https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake 
at line 21 states, FREETYPE_DIR is an environment variable.

So, if you change your line
set(FREETYPE_DIR "/home/kristian/Documents/freetype/freetype")
to
set(ENV{FREETYPE_DIR} "/home/kristian/Documents/freetype/freetype")
I would assume, your script will work.

Hth,
Andreas

Am 07.06.2016 um 22:47 schrieb Kristian:

Hey guys,

I wanted to try something out with CMake and latest version of 
freetype (2.6.3). So I downloaded freetype, compiled it with the commands


> ./configure --prefix=/home/kristian/Documents/freetype/freetype
> make
> make install

After that, I created a small C++-file and a CMakeLists.txt. The 
C++-file depends on freetype, so my CMakeLists.txt looks like this:


=

> cmake_minimum_required(VERSION 3.5)
> project(freetype_ex)
>
> set(FREETYPE_DIR "/home/kristian/Documents/freetype/freetype")
> find_package(Freetype)
>
> set(SOURCES main.cpp)
>
> include_directories(${FREETYPE_INCLUDE_DIRS})
>
> add_executable(${PROJECT_NAME} ${SOURCES})
> target_link_libraries(${PROJECT_NAME} ${FREETYPE_LIBRARIES})

=

But when calling cmake, I am getting this error:
=

> -- Could NOT find Freetype (missing: FREETYPE_LIBRARY 
FREETYPE_INCLUDE_DIRS)
> CMake Error: The following variables are used in this project, but 
they are set to NOTFOUND.
> Please set them or make sure they are set and tested correctly in 
the CMake files:

> FREETYPE_LIBRARY (ADVANCED)
> linked by target "freetype_ex" in directory 
/home/kristian/Documents/freetype/cmake

>
> -- Configuring incomplete, errors occurred!
> See also 
"/home/kristian/Documents/freetype/cmake/CMakeFiles/CMakeOutput.log".


=

This sort of error seems for me to be a bug, because I would assume, 
that when I set the variable FREETYPE_DIR, then CMake would also look 
at this dir.


I looked at the FindFreetype.cmake file 
(https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake) 
and my first assumption is, that it would help, to add something like 
${FREETYPE_DIR} the the find_path calls.


What do you think of this? Another idea is, to add another variable 
instead of FREETYPE_DIR, e.g. FREETYPE_ROOT_DIR...





--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Cmake cannot locate header file that exists on my system

2016-03-19 Thread Andreas Naumann

You have to add the directory /usr/include/trilinos to the c++ include 
directories. The fastest workaround would be, to add the directory to 
the CMAKE_CXX_FLAGS using ccmake or cmake-gui.
The better solution is to look for any hint regarding trilinos in the 
CMakeLists.txt of dakota and check, why the corresponding include 
directory is not added.


Regards,

Andreas

Am 17.03.2016 um 14:32 schrieb Chris Coutinho:


I’m attempting to install Dakota 6.3.0 using cmake 3.5.0 on a 64-bit 
Linux box from source (to link python and MATLAB), and Dakota is 
having trouble finding some dependencies. I’ve been able to install 
and use Dakota successfully on my previous machine (64-bit, OpenSUSE 
13.2, cmake 3.3.0) without any problems. Now that I upgraded to the 
more recent version of OpenSUSE (Opensuse Leap 42.1) and cmake 
(3.5.0), I’m not able to get past this error.


I am using cmake to build the source and create a makefile. 
Configuring cmake is fine; however, when running ‘make’ I get an error 
at around 5% of compiling:


/[ 5%] Building CXX object 
packages/OPTPP/src/CMakeFiles/optpp.dir/globals.C.o/
/In file included from 
/opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/globals.C:4:0:/
//opt/dakota/dakota-6.3.0.src/packages/OPTPP/include/globals.h:22:41: 
fatal error: Teuchos_SerialDenseMatrix.hpp: No such file or directory/

/#include "Teuchos_SerialDenseMatrix.hpp"/
/^/
/compilation terminated./

I looked for the missing file ‘Teuchos_SerialDenseMatrix.hpp’, and see 
that I have two copies on my computer from installing trilinos 11.4.3 
through the package manager. One is located under 
‘/usr/include/trilinos’, and the other is located 
‘/usr/lib64/mpi/gcc/openmpi/include/trilinos’. I’m not sure why I have 
two copies…


I added both of those directories to LD_LIBRARY_PATH in ~/.bashrc, but 
the error keeps coming up that Dakota isn’t able to find the file. Can 
anyone help me with this installation issue?


Kind regards,

*Chris Coutinho,* EIT

R Engineer

REDstack, B.V.

Pieter Zeemanstraat 6

8606 JR Sneek, The Netherlands

work: +31 6  5785

mobile: +31 6 1689 0287

www.redstack.nl

De informatie verzonden middels deze e-mail is uitsluitend bestemd 
voor de geadresseerde. Gebruik door anderen is niet toegestaan. 
Openbaarmaking, verspreiding en/of verstrekking van deze informatie 
aan derden is niet toegestaan. A.Hak staat niet in voor een juiste en 
volledige overbrenging van de inhoud, alsmede de tijdige ontvangst 
daarvan.


The information contained in this communication, including files, is 
confidential and legally privileged. It is intended solely for the use 
of the individual or entity to whom it is addressed and others 
authorized to receive it. If you are not the intended recipient you 
are hereby notified that any disclosure, copying, distribution or 
taking any action in reliance to the contents of this information, is 
strictly prohibited and may be unlawful. A.Hak is not liable for the 
proper, complete and timely transmission of the information contained 
in this communication.





--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Fwd: Re: cmake needs 2 runs to find boost

2015-11-09 Thread Andreas Naumann

Did boost change the naming convention? The documentation says, it 
should be named with vc. And therefore, cmake cannot find 
the library... Even the boost header files rely on the names in Visual 
studio. So, I would assume, your boost installation to be broken?


Regards,
Andreas

Am 09.11.2015 um 11:36 schrieb Boudewijn Rempt:
I'm actually hitting a similar problem -- I know I've got boost_system 
installed in


c:\dev2\i\lib\boost_system-vc-mt-1_55.dll
c:\dev2\i\lib\boost_system-vc-mt-1_55.lib

I run cmake like this:

cmake ..\krita -G"Visual Studio 14 Win64" -DBoost_DEBUG=ON 
-DBoost_FIND_QUIETLY=FALSE -DBOOST_INCLUDEDIR=c:\dev2\i\include 
-DBOOST_ROOT=c:\dev2\i -DBOOST_LIBRARYDIR=c:\dev2\i\lib 
-DCMAKE_INSTALL_PREFIX=c:\dev2\i -DCMAKE_PREFIX_PATH=c:\dev2\i 
-DCMAKE_BUILD_TYPE=Release


And the output is that boost_system isn't found, because it's looking 
for vc140, instead of vc, it seems:



-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:515 ] 
_boost_TEST_VERSIONS = 
1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;
1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1. 

39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 

-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:517 ] 
Boost_USE_MULTITHREADED = TRUE
-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:519 ] 
Boost_USE_STATIC_LIBS =
-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:521 ] 
Boost_USE_STATIC_RUNTIME =
-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:523 ] 
Boost_ADDITIONAL_VERSIONS =
-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:525 ] 
Boost_NO_SYSTEM_PATHS =
-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:577 ] Declared as 
CMake or Environmental Variables:
-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:579 ] BOOST_ROOT = 
c:\dev2\i
-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:581 ] 
BOOST_INCLUDEDIR = c:\dev2\i\include
-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:583 ] 
BOOST_LIBRARYDIR = c:\dev2\i\lib
-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:585 ] 
_boost_TEST_VERSIONS = 
1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;
1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1. 

39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 

-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:654 ] Include 
debugging info:
-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:656 ] 
_boost_INCLUDE_SEARCH_DIRS = 
c:\dev2\i\include;c:\dev2\i/include;c:\dev2\i;PATHS;C:/boos

t/include;C:/boost;/sw/local/include
-- [ C:/Program Files 
(x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:658 ] 
_boost_PATH_SUFFIXES = 
boost-1_58_0;boost_1_58_0;boost/boost-1_58_0;boost/boost_1_58_0;b
oost-1_58;boost_1_58;boost/boost-1_58;boost/boost_1_58;boost-1_57_0;boost_1_57_0;boost/boost-1_57_0;boost/boost_1_57_0;boost-1_57;boost_1_57;boost/boost-1_57;boost/boost_ 

1_57;boost-1_56_0;boost_1_56_0;boost/boost-1_56_0;boost/boost_1_56_0;boost-1_56;boost_1_56;boost/boost-1_56;boost/boost_1_56;boost-1_55_0;boost_1_55_0;boost/boost-1_55_0; 

boost/boost_1_55_0;boost-1_55;boost_1_55;boost/boost-1_55;boost/boost_1_55;boost-1_54_0;boost_1_54_0;boost/boost-1_54_0;boost/boost_1_54_0;boost-1_54;boost_1_54;boost/boo 

st-1_54;boost/boost_1_54;boost-1_53_0;boost_1_53_0;boost/boost-1_53_0;boost/boost_1_53_0;boost-1_53;boost_1_53;boost/boost-1_53;boost/boost_1_53;boost-1_52_0;boost_1_52_0 

;boost/boost-1_52_0;boost/boost_1_52_0;boost-1_52;boost_1_52;boost/boost-1_52;boost/boost_1_52;boost-1_51_0;boost_1_51_0;boost/boost-1_51_0;boost/boost_1_51_0;boost-1_51; 

boost_1_51;boost/boost-1_51;boost/boost_1_51;boost-1_50_0;boost_1_50_0;boost/boost-1_50_0;boost/boost_1_50_0;boost-1_50;boost_1_50;boost/boost-1_50;boost/boost_1_50;boost 

-1_49_0;boost_1_49_0;boost/boost-1_49_0;boost/boost_1_49_0;boost-1_49;boost_1_49;boost/boost-1_49;boost/boost_1_49;boost-1_48_0;boost_1_48_0;boost/boost-1_48_0;boost/boos 

t_1_48_0;boost-1_48;boost_1_48;boost/boost-1_48;boost/boost_1_48;boost-1_47_0;boost_1_47_0;boost/boost-1_47_0;boost/boost_1_47_0;boost-1_47;boost_1_47;boost/boost-1_47;bo 

ost/boost_1_47;boost-1_46_1;boost_1_46_1;boost/boost-1_46_1;boost/boost_1_46_1;boost-1_46_0;boost_1_46_0;boost/boost-1_46_0;boost/boost_1_46_0;boost-1_46;boost_1_46;boost

Re: [CMake] CMake + MPI

2015-09-08 Thread Andreas Naumann


Hi Nico,

I just use find_package(MPI REQUIRED) and use the given 
MPI_CXX_LIBRARIES and MPI_CXX_INCLUDE_PATH.

Recent mpi wrappers should support support interspection.

Regards,
Andreas

Am 08.09.2015 um 13:01 schrieb Nico Schlömer:

Hi everyone,

When it comes to compiling and linking, the MPI world is quite a mess. 
Sometimes, vendors make you link and include certain 
libraries/directories, sometimes you are supposed to simply use a 
compiler wrapper, often both.


What's the recommended way of dealing with MPI in CMake? Do you 
`find_package(MPI REQUIRED)` and set LINK_LIBRARIES and INCLUDE_DIRS? 
Do you select a compiler wrapper from within the CMake file? From outside?


Cheers,
Nico




--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake Error at build/modules/add_boost.cmake:156 (message):

2015-08-13 Thread Andreas Naumann


Hey,
at the first sight, it seems to me an error in their build system.
But the error message is surrounded by an if-clause. Your error message 
does not show any error or output, so I assume, there was no error with 
bootstrap, but the (executable? file?) b2 was not found.
To test it, you could print the result of the find_program call in their 
file add_boost.cmake just after the line 154.


Good luck,
Andreas

Am 13.08.2015 um 20:19 schrieb Sonya Blade:

Dear All,

I'm attempting to build the open license manager from that location 
.https://github.com/open-license-manager
As can be seen, there is not much info what needs to be done to 
configure and compile it, I'm not even sure that

it is been configured to work with GCC 4.7.1 and Code Blocks.

Anyway if attempt to run the configuration with CMake-GUI then I 
receive the following error,
AFAIU this library requires the boost library and Cmake-GUI downloads 
the boost automatically
but at th middle of configuration throws the following error how am I 
supposed further procedd on that?


CMake Error at build/modules/add_boost.cmake:156 (message):
Failed running ./bootstrap.sh;--with-toolset=gcc:

Call Stack (most recent call first):
CMakeLists.txt:73 (add_boost)

Regards,




--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Check whether C++ headers are self-sufficient

2015-03-14 Thread Andreas Naumann

Why do you want to use one library per header? I think, it would be 
sufficient to have one cc-file per header and one library per folder. 
The library would simply contain all files.

Why do you worry about large build directories?

Regards,
Andreas

Am 14.03.2015 um 13:19 schrieb Christoph Grüninger:

Dear CMakers,
I want to have all my C++ headers self-sufficient (self-contained),
i.e., a header can be included without additional includes. This is not
only handy but also part of Google's C++ styleguide [2].

It would be great to have a make target (let's call it headercheck),
that can check for this, by compiling a simple test.cc file for each
current_header.h:
   #include config.h
   #include current_header.h
   #include current_header.h

Additionally it would be great to have such a target for every folder
(checking all headers recursively) and every header that is explicitly
passed as an argument.

We tried this with CMake: We generate a test.cc file per header and
create a library for every cc file. The problem is, that we get hundreds
of additional targets, we generate a lot of folders and files which can
increase our build directory size by an order of magnitude and it does
not work properly on a per file or per directory basis.

What do you think, is there a good way to have such a target headercheck
with CMake? Or would it be better to include it as a CTest? Or better as
an external (bash) script as proposed in [1]?

If it can be done in a good way with CMake, would it be of interest to
include it as a feature in CMake? Or as an external project similar to
UseLATEX.cmake?

Bye
Christoph

[1]
http://stackoverflow.com/questions/1892043/self-sufficient-header-files-in-c-c
[2]
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Self_contained_Headers



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Problems with CMP0037

2014-11-02 Thread Andreas Naumann


Hi Alan,

with cmake 2.8.12.1 I can confirm this behavior at least for Makefile 
generator on Linux, see the attached small CMakeLists.txt. But what 
would be a better behavior? Changing the target name would change the 
output at end. So the user would have to figure out, what changed why. 
At this point, I would prefer the current behavior, because cmake does 
at least with the Makefile generator, the same thing as the user writes.

So the warning is  appropriate.

Andreas

Am 02.11.2014 18:30, schrieb Alan W. Irwin:

Eike said:


Because you can't create files or directories with that name, you
would end up getting one directory tests and a file/directory 
win32_test*. And
creating both with one API call isn't possible, so this may work if 
there is a directory tests before because of some other reason, but 
it will not reliably work.


Hi Eike:

I just want to confirm something about your answer.  The OP
was getting complaints about a _target_ with a slash in the name. At
the CMake level there is a huge distinction between targets and files.

Are you saying that at least for some generators a target eventually
ends up as a filename (e.g., at the configured Makefile level) with
exactly the same name as the target so a slash propagates to that 
filename?  I

agree if that were the case, it could cause issues on Unix platforms
if the directory portion of the filename was not independently
created first.

If this is actually the case, I am somewhat surprised that CMake
exposes such implementation details at the CMake level. For example,
it should be possible to use a unique hash of target names when
creating the corresponding configured filename such that the filename
does not include any characters such as / that have special meaning
at the file level on some platforms.

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
__


project(testSlash)
cmake_minimum_required(VERSION 2.8)
file(WRITE main.c int main() { return 0; })
add_executable(testDir/TestExe main.c)
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-18 Thread Andreas Naumann


Am 17.09.2014 22:00, schrieb Alexander Neundorf:

On Wednesday, September 17, 2014 14:50:40 Volker Pilipp wrote:
...

I suppose it is the line
LIBRARY_PATH=/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/opt/XXX/lib/g
cc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/:/lib/../lib64/:/usr/lib
/../lib64/:/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../:/lib/:/
usr/lib/

yes, cmake checks $LIBRARY_PATH and uses -l for the libraries located in these
directories.
I stumbled about that behaviour last year or so, I guess it's a feature.

Alex

It less a feature of cmake, much more a feature of gcc. It interprets 
every directory in LIBRARY_PATH as system directory and reports this to 
cmake, so it assumes, that those directories are system directories.


Andreas
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CFLAGS disables link directories?

2014-08-28 Thread Andreas Naumann


  
  
Hello Alexander,
  
  
  your problem is not a problem of CFlags, it is much more a problem
  of the compiler and what you are setting with --sysroot=/sysroot.
  
  Here you tell the compiler, that it should treat /sysroot as
  system library directory, so that cmake removes it from the link
  line, because it is part of the system. The same applies with gcc
  for the environment variable LIBRARY_DIR.
  
  
  I hope, that helps you.
  
  Andreas
  
  Am 28.08.2014 18:21, schrieb Alexander Shashkevych:


  Hi all,

I did't found info how cmake internally handles CFLAGS environment
variable, but I know that cmake picks it up from environment and seems this
removes link directories from linking flags added by link_directories()
command.

For example. I'm using custom sysroot, to build my app and I run cmake with
following command:

   export CFLAGS="--sysroot=/sysroot/"
   cmake ..

My cmake file is:

   # GStreamer_LIBRARY_DIRS is set by pkg_check_modules()
   link_directories(${GStreamer_LIBRARY_DIRS})

   get_directory_property(LINK_DIRS LINK_DIRECTORIES)
   message("LINK_DIRS: ${LINK_DIRS}")

   add_executable(myapp main.c)
   target_link_libraries(myapp ${GStreamer_LIBRARIES})

When CFLAGS isn't specified, then file src/CMakeFiles/myapp.dir/link.txt
contains -L/sysroot/usr/lib and -Wl,-rpath,/sysroot/usr/lib flags as
expected, but when I add CFLAGS to environment, then -L and -Wl,-rpath are
disappearing from linker options.

Could someone to confirm, is this expected behavior?

PS: Regardless of CFLAGS specified in command line or not, message() always
prints: LINK_DIRS: /sysroot/usr/lib, so internally cmake sets this property.

Thanks!

Alexander


  
  
  


  

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Cmake appears to substitute -llibrary when a full path is given.

2013-09-25 Thread Andreas Naumann


Hi Seth,
I had the same problem some time ago. In my case, the environment 
variable LIBRARY_PATH contained the boost directory, which instructs the 
linker to use it as standard library directory.
CMake asks the compiler for implicit linking directories. I am not 
completly sure, but the directories should be documented in some 
CMakeFiles/*Output* file.


I hope, that helps a little.
Andreas

On 23.09.2013 10:01, S'orlok Reaves wrote:

Good afternoon all,


This is my first post to this list, so please redirect me if I'm in the wrong 
place. So far cmake has been great, but I've run into an issue that I am having 
trouble understanding.

I'm searching for the Boost libs on a server that has two different versions 
installed. One is in my home directory; the other is a system-wide install 
(which is older).

In my CMakeLists.txt:

set(Boost_NO_SYSTEM_PATHS ON)
set(BOOST_ROOT /home/me/opt)
find_package(Boost COMPONENTS system REQUIRED)
MESSAGE(${Boost_LIBRARIES})
#later:
target_link_libraries (My_Program ${Boost_LIBRARIES})


This prints out the following, so I know the correct library is indeed found:
/home/me/opt/lib/libboost_system.so


Now, I make the project, and everything compiles, but fails to link, 
specifying several missing symbols in boost::system. The linker command includes the 
following:
#g++ etc., then:
-o ../My_Program -rdynamic /usr/local/lib64/libsoci_core.so -lboost_system 
-Wl,-rpath,/usr/local/lib64


If I change it to the following, it compiles, links, and runs fine:
-o ../My_Program -rdynamic /usr/local/lib64/libsoci_core.so 
/home/me/opt/lib/libboost_system.so -Wl,-rpath,/usr/local/lib64

Clearly the -lboost_system flag is catching the old libraries. From reading the cmake 
docs, I was under the impression that the full path (/home/me/opt/lib/libboost_system.so) would 
only be truncated to an -lboost_system if it was on the implicit path (e.g., /usr/lib). 
In that case, I have two questions:

1) Why is boost_system not being included via its complete path? Is this a bug, 
or am I doing something wrong?
2) Why is soci_core being included by the full path. Is it because /usr/local 
is not on the implicit path?

The second question is just out of curiosity; it is the first question that is 
causing me a lot of grief right now. Any suggestions?

The server I'm compiling on is running Debian Squeeze (6.0.7), with a 
locally-installed version of cmake (2.8.11.2).

Thanks,
Seth

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] library link order

2013-08-24 Thread Andreas Naumann


Hello,

I have cmake project, which tries to link against external libraries using

target_link_libraries(myExec ${EXTERNAL_LIBS})

When compiling and linking the executable using make, I can see that 
some libraries are doubled in the link line, but not all.
At the current stage, I think, that this leads to the linker errors with 
missing simbols of libraries, which are not doubled on the link command.


My question are now
a) why does cmake double some libraries?
b) which are append twice?


I am using cmake version 2.8.11.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] check_function_exists failing for gcc built-in functions?

2012-09-19 Thread Andreas Naumann





Hi,

it is an interesting problem. If you tell the gcc to use the math
library, it works. The interesting thing is the way of testing.

The cmake macro simply declares a function foo with the signature
 char foo();
and call this one without arguments. If you tell cmake to link against
the math library, it works.

But, if you simply call sqrt(5.0) the library is ommitted (I think the
gcc optimizes the code?)

So, if you always know the math library for the specific platform, you
should use it.

Hth,

Andreas

Am 19.09.2012 17:08, schrieb Jack Stalnaker:
Hi,
  
  
  I'm having trouble with check_function_exists() when it comes to
built-in functions in gcc. If I create just a simple C++ file with a
call to sqrt() or pow() and have a CMakeLists.txt with the following
lines,
  
  
  include (CheckFunctionExists)
  check_function_exists(sqrt HAVE_SQRT)
  
  
  cmake fails to find sqrt (or pow, log, exp, etc). In the sqrt
case, CMakeError.log shows
  
  
  /usr/share/cmake/Modules/CheckFunctionExists.c:3: warning:
conflicting types for built-in function 'sqrt'
  Linking C executable cmTryCompileExec
  /usr/bin/cmake -E cmake_link_script
CMakeFiles/cmTryCompileExec.dir/link.txt --verbose=1
  /usr/bin/gcc -DCHECK_FUNCTION_EXISTS=sqrt -fPIC
CMakeFiles/cmTryCompileExec.dir/CheckFunctionExists.c.o -o
cmTryCompileExec -rdynamic
  CMakeFiles/cmTryCompileExec.dir/CheckFunctionExists.c.o: In
function 'main':
  CheckFunctionExists.c:(.text+0x15): undefined reference to 'sqrt'
  
  
  What is the workaround for this, in the situation where the
function is built in, but I want to test for it on other platforms?
  
  
  Thanks
  

--

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] Check if a command exists?

2012-09-03 Thread Andreas Naumann

I don't know if it's the right way, but I am looking for the 
executable/script with find_file and set up a custom command for it.


Regards,
Andreas Naumann

Am 03.09.2012 21:59, schrieb Rui Maciel:
I have a small project which includes a couple of parsers whose lexers 
are generated by re2c.  I intended to set cmake so that it could check 
if re2c is present in the system, but after browsing through the docs 
I've ended up empty-handed.


So, is there a way to set a cmake project so that it checks if a 
tool/program/command is present in the build system?  If there is a 
way to run that check, can anyone provide an example?



Thanks in advance,
Rui Maciel
--

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] FindBLAS module

2012-08-31 Thread Andreas Naumann


I remember the same problem, but could not figure it out.
Which cmake version are you using?


Am 31.08.2012 19:30, schrieb Bogdan Cristea:

On Friday 31 August 2012 17:59:38 you wrote:
   

did you try to set the variable BLA_VENDOR to ACML?
 

Tried with this:

cmake .. -DBLA_VENDOR=ACML_MP

but I get another error message:

CMake Error at /usr/share/cmake/Modules/FindBLAS.cmake:293 (list):
list index: 0 out of range (-0, 18446744073709551615)

same if I use -DBLA_VENDOR=ACML.

LD_LIBRARY_PATH has the content:

/opt/acml5.1.0/gfortran64_mp/lib/

   


--

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] FindBLAS module

2012-08-31 Thread Andreas Naumann


Am 31.08.2012 19:58, schrieb Bogdan Cristea:

On Friday 31 August 2012 19:56:35 Andreas Naumann wrote:
   

I remember the same problem, but could not figure it out.
Which cmake version are you using?
 

cmake version 2.8.6

I have read somewhere that acml5.1.0 is not supported by cmake, but I am not
sure if this problem has been fixed or not.

regards
   
The current FindBLAS.cmake is more up to date and the last error should 
not occur. But I don't know, if it works.
I think, those fixed paths in the find modules are a bad idea. But I 
don't know a lot about the acml module to do it better.


Andreas
--

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] Relink to shared libs

2012-07-20 Thread Andreas Naumann

If you are using the Makefile system, then the libraries are newer than 
your tests, so your tests seems to need an update.


And sometimes programs need relinking, where should the build system 
now, if you really need the relinking?



Am 20.07.2012 14:08, schrieb Leif Walsh:

Why, if I make a small change to my shared library, does cmake relink all of my 
tests to it? It's a shared library, isn't the point that it doesn't need 
relinking? Seems like a big waste of time. Can I suppress this in any way?

Sent from my iPhone
--

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] SHARED library containing OBJECT library: Missing -fPIC

2012-06-22 Thread Andreas Naumann


Hello Benjamin,

if you wants to use an object file for a shared library, this object 
file has to be compiled with -fPIC. I don't think, that it is possible 
to create a shared library from such object files.


Regards,
Andreas

Am 22.06.2012 09:50, schrieb Benjamin Eikel:

Hello,

I have a problem using an OBJECT library that I want to compile into a SHARED
library using CMake version 2.8.8.

Here is a small example that demonstrates my problem:

# --- CMakeLists.txt ---
cmake_minimum_required(VERSION 2.8.8)
project(CMakeTest CXX)
add_library(MyLibSub OBJECT
 ClassA.cpp
)
add_library(MyLib SHARED
 $TARGET_OBJECTS:MyLibSub
 ClassB.cpp
)

The content of the other four files is more or less irrelevant. To make the
example complete, I added them at the end of this e-mail.

When I want to build this example, I get the following error:

$ mkdir build  cd build  cmake ..  make
-- The CXX compiler identification is GNU 4.7.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/benjamin/Desktop/CMake test/build
Scanning dependencies of target MyLibSub
[ 50%] Building CXX object CMakeFiles/MyLibSub.dir/ClassA.cpp.o
[ 50%] Built target MyLibSub
Scanning dependencies of target MyLib
[100%] Building CXX object CMakeFiles/MyLib.dir/ClassB.cpp.o
Linking CXX shared library libMyLib.so
/usr/bin/ld: CMakeFiles/MyLibSub.dir/ClassA.cpp.o: relocation R_X86_64_32
against `.rodata' can not be used when making a shared object; recompile with
-fPIC
CMakeFiles/MyLibSub.dir/ClassA.cpp.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [libMyLib.so] Error 1
make[1]: *** [CMakeFiles/MyLib.dir/all] Error 2
make: *** [all] Error 2

When I add the line
set_target_properties(MyLibSub PROPERTIES COMPILE_FLAGS -fPIC)
to the CMakeLists.txt, everything works fine. Am I doing something wrong?
Should CMake add -fPIC automatically in this case? Your feedback is greatly
appreciated.

Kind regards
Benjamin



// --- ClassA.cpp ---
#include ClassA.h
#includeiostream

void ClassA::printName() {
 std::cout  ClassA  std::endl;
}
// --- ClassA.h ---
#ifndef CLASSA_H
#define CLASSA_H

struct ClassA {
 void printName();
};

#endif /* CLASSA_H */
// --- ClassB.cpp ---
#include ClassB.h
#includeiostream

void ClassB::printName() {
 std::cout  ClassB  std::endl;
 a.printName();
}
// --- ClassB.h ---
#ifndef CLASSB_H
#define CLASSB_H

#include ClassA.h

struct ClassB {
 void printName();
 ClassA a;
};

#endif /* CLASSB_H */

--

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] SHARED library containing OBJECT library: Missing -fPIC

2012-06-22 Thread Andreas Naumann

I think the latter is the case. It should not be allowed to compose a 
shared library from OBJECT libraries.

What does the cmake developer think about this problem?

Regards,
Andreas

Am 22.06.2012 11:14, schrieb Benjamin Eikel:

Hello Andreas,

Am Freitag, 22. Juni 2012, 11:09:36 schrieb Andreas Naumann:
   

Hello Benjamin,

if you wants to use an object file for a shared library, this object
file has to be compiled with -fPIC. I don't think, that it is possible
to create a shared library from such object files.
 

I know that this is the case. My question is not directed to -fPIC in general,
but to CMake's handling of these files. I want to use CMake's new OBJECT
library feature to structure the build of a library. The library is built
statically as well as dynamically. When building statically, there is no
problem in using the OBJECT libraries of CMake. But when building dynamically,
the problem described in my original e-mail arises. CMake's documentation does
not say that it is not allowed to use OBJECT libraries to compose shared
libraries.

Kind regards
Benjamin

   

Regards,
Andreas

Am 22.06.2012 09:50, schrieb Benjamin Eikel:
 

Hello,

I have a problem using an OBJECT library that I want to compile into a
SHARED library using CMake version 2.8.8.

Here is a small example that demonstrates my problem:

# --- CMakeLists.txt ---
cmake_minimum_required(VERSION 2.8.8)
project(CMakeTest CXX)
add_library(MyLibSub OBJECT

  ClassA.cpp

)
add_library(MyLib SHARED

  $TARGET_OBJECTS:MyLibSub
  ClassB.cpp

)

The content of the other four files is more or less irrelevant. To make
the example complete, I added them at the end of this e-mail.

When I want to build this example, I get the following error:

$ mkdir build   cd build   cmake ..   make
-- The CXX compiler identification is GNU 4.7.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/benjamin/Desktop/CMake
test/build Scanning dependencies of target MyLibSub
[ 50%] Building CXX object CMakeFiles/MyLibSub.dir/ClassA.cpp.o
[ 50%] Built target MyLibSub
Scanning dependencies of target MyLib
[100%] Building CXX object CMakeFiles/MyLib.dir/ClassB.cpp.o
Linking CXX shared library libMyLib.so
/usr/bin/ld: CMakeFiles/MyLibSub.dir/ClassA.cpp.o: relocation R_X86_64_32
against `.rodata' can not be used when making a shared object; recompile
with -fPIC
CMakeFiles/MyLibSub.dir/ClassA.cpp.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [libMyLib.so] Error 1
make[1]: *** [CMakeFiles/MyLib.dir/all] Error 2
make: *** [all] Error 2

When I add the line
set_target_properties(MyLibSub PROPERTIES COMPILE_FLAGS -fPIC)
to the CMakeLists.txt, everything works fine. Am I doing something wrong?
Should CMake add -fPIC automatically in this case? Your feedback is
greatly appreciated.

Kind regards
Benjamin



// --- ClassA.cpp ---
#include ClassA.h
#includeiostream

void ClassA::printName() {

  std::cout   ClassA   std::endl;

}
// --- ClassA.h ---
#ifndef CLASSA_H
#define CLASSA_H

struct ClassA {

  void printName();

};

#endif /* CLASSA_H */
// --- ClassB.cpp ---
#include ClassB.h
#includeiostream

void ClassB::printName() {

  std::cout   ClassB   std::endl;
  a.printName();

}
// --- ClassB.h ---
#ifndef CLASSB_H
#define CLASSB_H

#include ClassA.h

struct ClassB {

  void printName();
  ClassA a;

};

#endif /* CLASSB_H */

--

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
 

--

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

Re: [CMake] help with shared-lib make failure

2012-06-18 Thread Andreas Naumann


Am 18.06.2012 08:34, schrieb luxInteg:

On Sunday 17 June 2012 14:13:00 Andreas Naumann wrote:

   

#--build2: gs_test/results.c.  build  disabled   near beginning
but comes in ~65%   of build
[ 65%] Building C object Lib/CMakeFiles/gsl.dir/__/test/results.c.o
cd /home/TESTS/BUILDgsl/Lib   /usr/bin/gcc  -Dgsl_EXPORTS
-DHAVE_CONFIG_H - DPIC -m64 -fPIC  -msse2 -fPIC -I~SRS/blas -I~SRS/block
-I~SRS/bspline - I~SRS/cblas -I~SRS/cdf -I~SRS/cheb -I~SRS/deriv
-I~SRS/dht -I~SRS/eigen - I~SRS/err -I~SRS/fit -I~SRS/gsl
-I~SRS/histogram -I~SRS/iee-utils - I~SRS/integration
-I~SRS/interpolation -I~SRS/linalg -I~SRS/matrix -I~SRS/min -I~SRS/monte
-I~SRS/multifit -I~SRS/multimin -I~SRS/multiroots -I~SRS/multiset
-I~SRS/ntuple -I~SRS/ode-initval -I~SRS/permuation -I~SRS/poly
-I~SRS/qrng - I~SRS/randist -I~SRS/rng -I~SRS/roots -I~SRS/siman
-I~SRS/sort -I~SRS/specfunc -I~SRS/statistics -I~SRS/sum -I~SRS/sys
-I~SRS/test -I~SRS/utils -I~SRS/vector -I~SRS/wavelet
-I/home/TESTS/BUILDgsl -I~SRS   -msse2 -mfpmath=sse -msse3 - mfpmath=sse
-Wall -o CMakeFiles/gsl.dir/__/test/results.c.o   -c ~SRS/test/results.c
~SRS/test/results.c: In function 'gsl_test':
~SRS/test/results.c:89: error: 'va_list' undeclared (first use in this
function)
~SRS/test/results.c:89: error: (Each undeclared identifier is reported
only once
~SRS/test/results.c:89: error: for each function it appears in.)
~SRS/test/results.c:89: error: expected ';' before 'ap'
~SRS/test/results.c:93: warning: implicit declaration of function
'va_start' ~SRS/test/results.c:93: error: 'ap' undeclared (first use in
this function) ~SRS/test/results.c:96: warning: implicit declaration of
function 'va_end' ~SRS/test/results.c: In function 'gsl_test_rel':
~SRS/test/results.c:149: error: 'va_list' undeclared (first use in this
function)
~SRS/test/results.c:149: error: expected ';' before 'ap'
~SRS/test/results.c:153: error: 'ap' undeclared (first use in this
function) ~SRS/test/results.c: In function 'gsl_test_abs':
~SRS/test/results.c:225: error: 'va_list' undeclared (first use in this
function)
~SRS/test/results.c:225: error: expected ';' before 'ap'
~SRS/test/results.c:230: error: 'ap' undeclared (first use in this
function) ~SRS/test/results.c: In function 'gsl_test_factor':
~SRS/test/results.c:302: error: 'va_list' undeclared (first use in this
function)
~SRS/test/results.c:302: error: expected ';' before 'ap'
~SRS/test/results.c:307: error: 'ap' undeclared (first use in this
function) ~SRS/test/results.c: In function 'gsl_test_int':
~SRS/test/results.c:357: error: 'va_list' undeclared (first use in this
function)
~SRS/test/results.c:357: error: expected ';' before 'ap'
~SRS/test/results.c:362: error: 'ap' undeclared (first use in this
function) ~SRS/test/results.c: In function 'gsl_test_str':
~SRS/test/results.c:401: error: 'va_list' undeclared (first use in this
function)
~SRS/test/results.c:401: error: expected ';' before 'ap'
~SRS/test/results.c:406: error: 'ap' undeclared (first use in this
function) make[2]: *** [Lib/CMakeFiles/gsl.dir/__/test/results.c.o]
Error 1 make[2]: Leaving directory `/home/TESTS/BUILDgsl'
make[1]: *** [Lib/CMakeFiles/gsl.dir/all] Error 2
make[1]: Leaving directory `/home/TESTS/BUILDgsl'
make: *** [all] Error 2



suggestions welcome

sincerely
luxInteg
   

The comp misses the declaration of the type va_list. if those errors
are the first ones, then this type is simply never declared. If it works
with the static library, you should have look which preprocessor flags
are used for the static libraries and compare them with the shared ones.

 

The  preprocessor flag appears to be -M.  When this is sumstituted  a 'patched
version of results.c does indeed compile and the build progresses to  ~70%
where   th results.c is again compiled  with a load of other files  into a
large library and there   are no obvius ways   to isolate its  compilation to
add the -M definition.  I tried set_source_file_properties(PROPERTIES compile
definitions -M)  but this adds a -D-M  which does not seem to be the same -
M.

Anyway the problem seems to be a troublesome test/results.c file.
(It is attached for your info )
   the unpatched version gives this response at the start of the build :-

#
In file included from ~/TESTS/gsl-1.15/test/results.c:32:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.2/include/varargs.h:4:2: error:
#error GCC no longer implementsvarargs.h.
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.2/include/varargs.h:5:2: error:
#error Revise your code to usestdarg.h.
make[2]: *** [test/CMakeFiles/gsltest-static.dir/results.c.o] Error 1
#

the file seems to need  updating   (extensively patched ) for newer compilers
so any suggestiions  you have  will be gratefully received.


sincerely
luxInteg
   
I think it is a bad idea to rely on the -M flag, because cmake tries to 
figure out the dependencies..


You could start with defining STDC_HEADERS, or let cmake look for the 
needed headers and set the flag appropriatly

Re: [CMake] CMake 2.7.8 cannot find boost installation While building PCL files.

2012-04-12 Thread Andreas Naumann

Hi,

you could set Boost_DEBUG and Boost_DETAILED_FAILURE_MSG to true and
have a look at the messages.

I hope, this helps you.

Andreas

Am 12.04.2012 11:06, schrieb Joeri Friederich:

Im
trying to build PCL (Point cloud library) files using Cmake.
It
needs a bunch if dependencies one of which is boost.
It
finds all other dependencies without a hitch but it gives this error
for boost:

The following Boost
libraries could not be found:
boost_system
boost_filesystem
boost_thread
boost_date_time
boost_iostreams
I
have been trying to fix this for 2 days now.

What
I did:
I
build my own libraries with boost.build using the following commands:
b2
toolset=gcc
--build-dir=C:\boost
--build-type=complete
This
build the library successfully.

Adding
the files (libboost_thread-mgw46-mt-1_49.dll) etc to the lib folder in
my boost installation doesn't allow cmake to find them though.
It
does however find the include directory without a hitch.
Even
manually linking Cmake to the (correct) libraries doesn't allow it to
find them.

How
do I get cmake to find these lib's?

Also:
boost_thread doesnt exist on my computer but"libboost_thread-mgw46-mt-1_49.dll"
and 20 different versions of it with different letters at mt do.
is
there a way that I can see what file Cmake is looking for exactly?

Version
etc:
Cmake:2.8.7
Cmake
generator: Mingw makefiles
Compiler:
GCC.
Boost
v:1.49.0
Windows
7

Thanks
for any help,

Joeri.

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

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] FindPackage search priority for Boost

2012-04-11 Thread Andreas Naumann





Dear Petar,

In cmake 2.8.3, you can set Boost_NO_SYSTEM_PATHS to true.

Kind regards,
Andreas Naumann

Am 11.04.2012 15:04, schrieb Petar Marendic:
Greetings,
  
I recently noticed that FindPackage always begins its search for
package Boost in /usr/lib and only thereafter in the directory
specified by variable BOOST_ROOT. This can cause problems if there
already are Boost libraries in the /usr/lib directory as they will be
selected over those (or together with those) located in BOOST_ROOT
subdirectories.
  
Is this intended behavior and if so what is the conventional procedure
to resolve such issues?
  
This behaviour was exhibited with CMake version 2.8.0, Ubuntu 10.04.3
LTS Lucid Lynx and Boost version 1.49.0 
  
Kind regards,
Petar Marendich
  

--

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] Using CMake to interface with non-CMake libraries

2011-07-24 Thread Andreas Naumann


Hey Zoey,

I don't know anything about SOLID, but the errormessage means, your 
program needs to be linked against a library.


You could ask cmake to look for your SOLID library:
find_library(SOLID_LIBRARY solid)
if(NOT SOLID_LIBRARY)
  message(ERROR please specify the library for SOLID)
endif(NOT SOLID_LIBRARY)

add extend the target_link_libraries call with ${SOLID_LIBRARY}:

target_link_libraries(hybrid_PRM_demo ${QT3_LIBRARIES} ${CGAL_LIBRARIES}
${CGAL_3RD_PARTY_LIBRARIES} ${SOLID_LIBRARY})

I hope that helps you a little bit.

Andreas

Am 24.07.2011 12:09, schrieb Zoey McCarthy:

Hello everyone,

I am new to using CMake and I am trying to compile a program that uses two
libraries, one of which needs to be built using CMake, and the other, that
utilizes its own build system(the Makefiles were generated using ./configure).
The two libraries are CGAL and SOLID (for collision detection).

CGAL provides a script, cgal_create_cmake_script , that produces the
CMakeLists.txt file for an executable that includes the CGAL library.  I can
build my executable fine using cmake and make when I only try to include CGAL.
When I try to include SOLID, I have issues with finding class definitions during
linking, i.e. I get errors of the type:

/home/zoeymccarthy/hybrid_PRM/CollisionChecker.h:146: undefined reference to
`DT_GenResponseClass'

SOLID is installed in /usr/local/include/SOLID/ and /usr/include/SOLID/. The
header files for the library were installed there, but I have since tried
copying the rest of the files associated with the library there since the
compiler was able to locate the header files.


This is the CMakeLists.txt that the CGAL script generated for my project:



# Created by the script cgal_create_cmake_script
# This is the CMake script for compiling a CGAL application.


project( hybrid_PRM_demo )

CMAKE_MINIMUM_REQUIRED(VERSION 2.4.5)

set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true)

if ( COMMAND cmake_policy )
   cmake_policy( SET CMP0003 NEW )
endif()

find_package(CGAL QUIET COMPONENTS Core Qt3 )

if ( CGAL_FOUND )

   include( ${CGAL_USE_FILE} )

   find_package(Qt3-patched QUIET )
   # FindQt3-patched.cmake is FindQt3.cmake patched by CGAL developers, so
   # that it can be used together with FindQt4: all its variables are prefixed
   # by QT3_ instead of QT_.

   if(CGAL_Qt3_FOUND AND QT3_FOUND)

 include( Qt3Macros-patched )
 qt3_automoc(  main.cpp )

 # Make sure the compiler can find generated .moc files
 include_directories(BEFORE ${CMAKE_CURRENT_BINARY_DIR})

 include_directories( ${QT3_INCLUDE_DIR} )

 add_executable  (hybrid_PRM_demo  main.cpp)

 add_to_cached_list( CGAL_EXECUTABLE_TARGETS hybrid_PRM_demo )


 # Link the executable to CGAL and third-party libraries
 target_link_libraries(hybrid_PRM_demo ${QT3_LIBRARIES} ${CGAL_LIBRARIES}
${CGAL_3RD_PARTY_LIBRARIES} )
   else()

 message(STATUS NOTICE: This demo requires Qt3 and the CGAL Qt3 library, 
and
will not be compiled.)

   endif()

else()

 message(STATUS NOTICE: This demo requires the CGAL library, and will not 
be
compiled.)

endif()




As you can see, there is no reference to SOLID.  How should I modify it so that
the resulting Makefile will know where to link to my SOLID object files, given
that SOLID has no .cmake file associated with it, and the library was built
without any CMakeLists.txt files?  I've tried adding the following two lines:

include_directories(/usr/include/SOLID/)
link_directories(/usr/include/SOLID/)

to the middle of my CMakeLists.txt (before if ( CGAL_FOUND) ), but it results in
the same error.

I'm sorry if this is a stupid question, but for the life of me I can't get it to
work.


Thank you for your help,

Zoey

___
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] Multiple install section from the same base folder

2011-07-12 Thread Andreas Naumann


You could use
file(GLOB_RECURSE files *.h)

or install the main directory with
install(DIRECTORY ... )
and exclude every non-header file (and possibly svn..)

Andreas


Am 12.07.2011 05:04, schrieb Laszlo Papp:

Hi,

I have just realized this snippet in my CMakeLists.txt file:

install(FILES
 atticamanager.h
 authentication.h

 DESTINATION ${INCLUDE_INSTALL_DIR}/gluon/player/lib
 COMPONENT Devel
)

install(FILES
 archive/archive.h

 DESTINATION ${INCLUDE_INSTALL_DIR}/gluon/player/lib/archive
 COMPONENT Devel
)

install(FILES
 models/commentitemsmodel.h
 models/gameitemsmodel.h
 models/highscoresmodel.h
 DESTINATION ${INCLUDE_INSTALL_DIR}/gluon/player/lib/models
 COMPONENT Devel
)

I wonder whether it could be done smarter. In the example above, there
are subfolders like archive, models. It could also contain 5-10
subfolders (even more) and we install the headers this way: one
separate install section for each subfolder even if we explicitely
write the subfolders all the time, like archive/archive.h,
models/commentitemsmodel.h, et cetera.

Are we doing it wrong and there is already a smarter cmake option for
this ? I find it useful if there is just one section for those things,
but if it is technically not possible or against the design, please
let me know.

Best Regards,
Laszlo Papp
___
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] Getting file list from build directory

2011-06-26 Thread Andreas Naumann





You could run ar -x at cmake runtime using
execute_process(...)

and then glob the objects.

If your archive is created by cmake, you could write a shell script,
that unpacks the archive and do what you wants with the object files.

Andreas

Am 26.06.2011 07:38, schrieb Dan Furtney:

  
  
  I have a CMakeLists.txt file file that creates an archive from
several files. It includes a custom command that dumps the list of
objects from the archive using ar –x.
   
  I need to link these objects with another custom command. What
is the best way to get the list of objects into the link line?
Currently the object files are dumping to CMAKE_CURRENT_BINARY_DIR.
   
  I tried glob but the files need to be present at cmake run-time.
Thanks again for any help.
  
  
  

___
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] How to compile MPI code

2011-06-22 Thread Andreas Naumann





What do you mean with "it doesn't run correctly"? Does it not even
start? How do you start your program?

Andreas

Am 22.06.2011 12:00, schrieb M Dolores Villalobos Ortiz:

  

  
Hi

I'm trying to compile a main program (it contains MPI functions) using
cmake. I get an executable file (there aren't problems in compilation
), but it doesn't run correctly.

If I compile my code using a simple Makefile, it works; but I need to
compile it using cmake (that's a prerequisite for my work).

I have installed MPICH2 and cmake 2.8.4. and I use the next files:

CMakeLists.txt:

cmake_minimum_required(VERSION 2.7)
set(CMAKE_CXX_COMPILER "/home/lola/Packages/mpich2-1.3.2p1/bin/mpicxx")
set(CMAKE_C_COMPILER "/home/lola/Packages/mpich2-1.3.2p1/bin/mpicc")
project( ITK_MPI )
find_package ( MPI )
if ( MPI_FOUND )
 include_directories( ${MPI_INCLUDE_PATH} )
endif( MPI_FOUND )

--

CMakeCache.txt:

.
..

//CXX compiler.
CMAKE_CXX_COMPILER:FILEPATH=/home/lola/Packages/mpich2-1.3.2p1/bin/mpicxx
//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING=
//Flags used by the compiler during debug builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=
//Flags used by the compiler during release minsize builds.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=
//Flags used by the compiler during release builds (/MD /Ob1 /Oi
// /Ot /Oy /Gs will produce slightly less optimized but smaller
// files).
CMAKE_CXX_FLAGS_RELEASE:STRING=
//Flags used by the compiler during Release with Debug Info builds.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=
//C compiler.
CMAKE_C_COMPILER:FILEPATH=/home/lola/Packages/mpich2-1.3.2p1/bin/mpicc




//Value Computed by CMake
ITK_MPI_BINARY_DIR:STATIC=/home/lola/Curso/Proyecto/Pruebas_MPI
//Value Computed by CMake
ITK_MPI_SOURCE_DIR:STATIC=/home/lola/Curso/Proyecto/Pruebas_MPI
//Executable for running MPI programs.
MPIEXEC:FILEPATH=/home/lola/Packages/mpich2-1.3.2p1/bin/mpiexec
//Maximum number of processors available to run MPI applications.
MPIEXEC_MAX_NUMPROCS:STRING=2
//Flag used by MPI to specify the number of processes for MPIEXEC;
// the next option will be the number of processes.
MPIEXEC_NUMPROC_FLAG:STRING=-n2
//These flags will come after all flags given to MPIEXEC.
MPIEXEC_POSTFLAGS:STRING=
//These flags will be directly before the executable that is being
// run by MPIEXEC.
MPIEXEC_PREFLAGS:STRING=
//MPI compiler. Used only to detect MPI compilation flags.
MPI_COMPILER:FILEPATH=/home/lola/Packages/mpich2-1.3.2p1/bin/mpicxx
//MPI compilation flags
MPI_COMPILE_FLAGS:STRING=' '
//Extra MPI libraries to link against
MPI_EXTRA_LIBRARY:STRING=/usr/lib/mpich/lib/libmpich.a;/usr/lib/libpthread.so;/usr/lib/librt.so
//MPI include path
MPI_INCLUDE_PATH:STRING=/home/lola/Packages/mpich2-1.3.2p1/include
//MPI library to link against
MPI_LIBRARY:FILEPATH=/usr/lib/mpich/lib/libpmpich++.a;/usr/lib/mpich/lib/libmpich.a;/usr/lib/libpthread.so;/usr/lib/librt.so
//MPI linking flags
MPI_LINK_FLAGS:STRING=
.


What's am I doing wrong?, Is there any other configuration?. I really
need to make it work.

Thank you

Lola

  

  
  

___
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] Test-specific configuration

2011-06-20 Thread Andreas Naumann


Am 21.06.2011 02:50, schrieb Tim Gallagher:

Hi,

I'm trying to set up automated testing of our code with CTest (we are using 
CMake), but I'm running into some issues I can't figure out the correct way to 
solve. Many of our tests require specific sets of options to be turned on/off 
in the configuration step.

How is this done? We've used CTest for a much simpler code and there we created 
a bunch of different driver programs for unit tests that we added with 
add_executable() and add_test(), but there were no configuration options that 
changed for each test.

In this case, if we have, say, 10 tests, each test will need a 
configure/build/run step with different options for configuration. What needs 
to go in the CMakeLists.txt?

These will be submitted to CDash also, if that changes things.

Any help would be appreciated.

Tim
___
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

   

Hi Tim,

the configurations differ in compileflags or compiledefinitions only, right?

So you could add different executables for each compileflag definition:
add_executable(test_${config} SOURCES)
set_target_properties(test_${config} COMPILEFLAGS ${CURRENTFLAGS})

or use different build directories for each configuration, configure 
with cmake and then run ctest in each directory.


Andreas
___
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] Dependencies and libraries..How does it work?

2011-06-17 Thread Andreas Naumann





I don't see any good reason, why should cmake call itself in another
build directory?

If the library is part of the project, than it is added with
add_subdirectory in the main CMakeLists.txt file.
If the library is not part of the project, it has to be maintained from
outside.

Am I missing something?

Andreas

Am 17.06.2011 11:40, schrieb David Springate:
Hi Andreas,
  
Thanks for another reply!
  
My question therefore is:
How can the cmake for MY_APP start the cmake for MY_LIB?
  
I know how to get my app to link a library, and how to add the include
directories for the lib - so that the app can compile - but how can it
kick-start the build for MY_LIB so that the library is guaranteed to
exist ready to be linked? I don't want to use an external script as I'd
have to have one for each platform - going against the point of cmake,
surely?
  
Thanks again for your help so far,
  
David
  
  On 17 June 2011 10:22, Andreas Naumann andreas-naum...@gmx.net
wrote:
  

Hi,

how should cmake find your MY_LIB-directory?
The simplest way, is to add the directory using
"add_subdirectory(MY_LIB_DIR ...)"

If the MY_LIB-build directory is somewhere else, in a completely
different directory, you should think about your project structure.

Andreas

Am 17.06.2011 11:06, schrieb David Springate:
Hi,
  
Thanks for the reply - but I think you might have misunderstood my
question.
  
I want to setup CMake so that when I call Cmake like so (for MY_APP):
mkdir build  cd build
cmake .. -G Xcode
  
that the cmake call will be able to 'know' that it needs MY_LIB, find
where the MY_LIB CMakeLists.txt file is, build it, and then continue
with the cmake call for MY_APP.
  
Any ideas?
  
David
  
  On 17 June 2011 08:18, J.S. van
Bethlehem j.s.van.bethle...@astro.rug.nl
wrote:
  Hej
David,

From your description I think all your build script needs to do is:

mkdir build  cd build
cmake ..
make MY_APP

Further, assuming your library also gets build with CMake, you probably
have an add_directory(../MY_LIB ../MY_LIB) in your main lists-file
(otherwise you should) and then the link_directories() command is not
needed. I created sort of a 'standard' machinery for building a list of
'sub-packages' using CMake. It's not well documented and probably still
has many issues, but I could mail it to you if you think it may help
you get started and if you're interested.

Greetsz,
Jakob

On 06/16/2011 11:54 PM, David Springate wrote:
Hi,
  
I am new to CMake - and whilst I am immediately impressed with it's
relative ease of use - I have a 'noob' question, I'm sure!
  
I have the following:
A library called MY_LIB that builds with a cmake command (I have
created a nice CMakeLists.txt file)
An application called MY_APP that builds a nice application - and even
links in MY_LIB using:
link_directories("../MY_LIB")
target_link_libraries(MY_APP MY_LIB)
  
Now, first of all I know that I'm not supposed to use relative paths..
but we'll call a side issue.. (though I'd be happy to hear the correct
way of doing things!) - the real problem that I have is this:
  
Give than MY_LIB is built using CMake and MY_APP is built using CMake..
how can I setup my build scripts so that I can call CMake once for
MY_APP, it'll realise that it needs MY_LIB, which hasn't yet been
built, invoke CMake for MY_LIB and then link itself with MY_APP?
  
I ask because I use libraries heavily to organise my code (and reuse)
and would love to switch to CMake for all my building (XCode 4 has
forced my hand!) but I can't seem to figure this out.
  
Please help a newcomer out - any help is greatly appreciated!
  
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
  
  
  
  
  
-- 
David Springate
  david.spring...@gmail.com
  
___
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:

Re: [CMake] unexpected INSTALL problems

2011-06-15 Thread Andreas Naumann


Am 15.06.2011 14:24, schrieb Dominik Szczerba:

On Wed, Jun 15, 2011 at 2:22 PM, Andreas Naumann
andreas-naum...@gmx.net  wrote:
   

Am 15.06.2011 13:58, schrieb Dominik Szczerba:
 

I am trying to copy all libboost* stuff from /usr/lib to
CMAKE_INSTALL_PREFIX just as most users would guess:


   

Why do you want to copy the boost libraries from /usr/lib to
CMAKE_INSTALL_PREFIX? And why all of them??
I don't see any reason for this.
If you wants to use them, you could use
find_package(Boost .)
 

I need to create a redistributable package with this and none other
boost version. It works very well for us and this policy is not up to
me. The point of the mail was the very unintuitive cmake behavior. I
will appreciate any hints.

Dominik

   

okay, than you could use
find_package(Boost YOUR_VERSION EXACT)

If you think, you really have to ship the boost libraries with your 
package, you could look for your boost libraries you need and use the 
variable Boost_LIBRARIES.

But than you possibly copy only the links...

INSTALL(DIRECTORY ${BOOST_RUNTIME_DIR}/ DESTINATION
${CMAKE_INSTALL_PREFIX}/bin FILES_MATCHING ...)
   

I tried

file(GLOB BOOSTLIBS /usr/lib/libboost*.so.*)
INSTALL(FILES ${BOOSTLIBS} DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)

and it worked.
The libboost*.so are only symlinks on my system.

Andreas

Whatever I specify for matching I always get half of my system copied
instead of the requested files. E.g.

PATTERN libboost*.so does absolutely nothing and REGEX
libboost.*\.so.*$ complains about the slash, when removed does
nothing either. As a result all content is always copied.

Interestingly and confusingly, the same thing (only used PATTERN)
works for e.g. *.h. What is special here?

Are there any examples how to use this functionality? Both the
documentation and the FAQ are not very comprehensive in this matter.

Thanks and regards,
Dominik
___
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


 
   


___
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] unexpected INSTALL problems

2011-06-15 Thread Andreas Naumann


Am 15.06.2011 14:58, schrieb Dominik Szczerba:

okay, than you could use
find_package(Boost YOUR_VERSION EXACT)
 

Problem is boost has very complicated linking scenario. Using
FindBoost and linking to it hardcodes the versions, because they are
in the filenames! If I need to run on another system I must have
exactly the same boost version, but that is almost never the case.

   

INSTALL(DIRECTORY ${BOOST_RUNTIME_DIR}/ DESTINATION
${CMAKE_INSTALL_PREFIX}/bin FILES_MATCHING ...)

   

I tried

file(GLOB BOOSTLIBS /usr/lib/libboost*.so.*)
INSTALL(FILES ${BOOSTLIBS} DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
 

The problem here is that FILE() only runs at configure time, while
INSTALL on building the install target. We can not accept that on
other reasons, we need to have the full installation in one go.

So I conclude it is not possible.

Many thanks for your response.

Dominik

   


On my system, FindBoost detects the *.so without the version numbers. 
So, I can update to a new (hopefully binary compatible) version without 
relinking.
And we provide packages depending on boost by setting the package 
dependency using cpack.


Andreas
___
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] unexpected INSTALL problems

2011-06-15 Thread Andreas Naumann


Am 15.06.2011 22:16, schrieb Dominik Szczerba:

I use Debian SID 64bit which is similar to Ubuntu, but not the same :)
The problem (if it really is one) is that debian does ship the libraries
with another naming, so FindBoost will select the library without version
number.
 

That's very interesting. My Boost_LIBRARIES according to cmake are:
optimized;/usr/lib/libboost_thread-mt.so;debug;/usr/lib/libboost_thread-mt.so
but my stuff gets linked to the ones with versions in the name, proved
by ldd:

   

ldd bin/vtkmyFilteringPython.so | grep boost
 

libboost_thread.so.1.40.0 =  /usr/lib/libboost_thread.so.1.40.0
(0x7f51c7a8e000)

Very strange.

   

I looked in the script FindBoost.cmake and saw the problem in the lines 717
- 723 (and 728 - 735). Here, the libraries with the version number are
listed before the ones without version number.
Does one always prefer the libraries with version number? Or should the
order changed?
I think the best way is to use both:
If the user wants exactly this version, the find-library command should use
ONLY libraries with names, and if not it should look for libraries without
the number first.

What do you think about this idea?
 

I see advantages and disadvantages of both options and I do agree with
you that a user should have a choice to pick one.

Best regards,
Dominik

   

This behavior is really strange and I tested it in the last 10 minutes.
CMake says:
boost libs: /usr/lib/libboost_system-mt.so

Compiling and linking with verbose reveals the link command:
/usr/bin/c++  CMakeFiles/test.dir/test.cpp.o  -o test -rdynamic 
-lboost_system-mt


But a ldd on test gives:
andreas[515:3]:ldd test
linux-vdso.so.1 =  (0x7fff2fb4a000)
libboost_system.so.1.46.1 = /usr/lib/libboost_system.so.1.46.1 
(0x7f525e8c7000)

libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f525e5bd000)
libm.so.6 = /lib/libm.so.6 (0x7f525e33a000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7f525e124000)
libc.so.6 = /lib/libc.so.6 (0x7f525ddc3000)
librt.so.1 = /lib/librt.so.1 (0x7f525dbba000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7f525d99e000)
/lib64/ld-linux-x86-64.so.2 (0x7f525eaf5000)

I don't install, only build the executable.

Does anybody have an idea?

Regards,
Andreas
___
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] unexpected INSTALL problems

2011-06-15 Thread Andreas Naumann


Am 15.06.2011 22:28, schrieb Andreas Naumann:

Am 15.06.2011 22:16, schrieb Dominik Szczerba:

I use Debian SID 64bit which is similar to Ubuntu, but not the same :)
The problem (if it really is one) is that debian does ship the 
libraries
with another naming, so FindBoost will select the library without 
version

number.

That's very interesting. My Boost_LIBRARIES according to cmake are:
optimized;/usr/lib/libboost_thread-mt.so;debug;/usr/lib/libboost_thread-mt.so 


but my stuff gets linked to the ones with versions in the name, proved
by ldd:


ldd bin/vtkmyFilteringPython.so | grep boost

libboost_thread.so.1.40.0 =  /usr/lib/libboost_thread.so.1.40.0
(0x7f51c7a8e000)

Very strange.

I looked in the script FindBoost.cmake and saw the problem in the 
lines 717

- 723 (and 728 - 735). Here, the libraries with the version number are
listed before the ones without version number.
Does one always prefer the libraries with version number? Or should the
order changed?
I think the best way is to use both:
If the user wants exactly this version, the find-library command 
should use
ONLY libraries with names, and if not it should look for libraries 
without

the number first.

What do you think about this idea?

I see advantages and disadvantages of both options and I do agree with
you that a user should have a choice to pick one.

Best regards,
Dominik


This behavior is really strange and I tested it in the last 10 minutes.
CMake says:
boost libs: /usr/lib/libboost_system-mt.so

Compiling and linking with verbose reveals the link command:
/usr/bin/c++  CMakeFiles/test.dir/test.cpp.o  -o test -rdynamic 
-lboost_system-mt


But a ldd on test gives:
andreas[515:3]:ldd test
linux-vdso.so.1 =  (0x7fff2fb4a000)
libboost_system.so.1.46.1 = 
/usr/lib/libboost_system.so.1.46.1 (0x7f525e8c7000)

libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f525e5bd000)
libm.so.6 = /lib/libm.so.6 (0x7f525e33a000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7f525e124000)
libc.so.6 = /lib/libc.so.6 (0x7f525ddc3000)
librt.so.1 = /lib/librt.so.1 (0x7f525dbba000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7f525d99e000)
/lib64/ld-linux-x86-64.so.2 (0x7f525eaf5000)

I don't install, only build the executable.

Does anybody have an idea?

Regards,
Andreas
___
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

It seems to be a feature of the linker. If the library has the DT_SONAME 
field, the linker will use this field as library to link against instead 
of the filename... I did not find an option to avoid this behavior. Is 
there any? Even the IMPORTED feature of add_library does not help.


Regards
Andreas
___
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] Changing definitions at compile time

2011-06-14 Thread Andreas Naumann





Am 14.06.2011 18:12, schrieb Kfir Lavi:

  Hi,
I need to compile the code twice. Once with -DA and once with -DB
My code look like this:
add_definitions(-DA)
add_library(${mylib_A} SHARED ${myfiles})
remove_definitions(-DA)
  
add_definitions(-DB)
add_library(${lib_B} SHARED ${myfiles})
remove_definitions(-DB)
  
What cmake does is to define A and then remove it, so in compile time,
there 
is now definition of A or B. 
  
How do I tell cmake that the remove needs to  be in compile time?
  
Regards,
Kfir
  
  

___
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

You want to create two libraries A and B from the same sourcefiles
${myfiles}. The first one have to be compiled with -DA and the second
one with -DB, haven't it?

So you could simply set the COMPILE_FLAGS property with
add_library(A ${myfiles})
add_library(B ${myfiles})

set_target_properties(A PROPERTIES COMPILE_FLAGS "-DA")
set_target_properties(B PROPERTIES COMPILE_FLAGS "-DB")

Regards,
Andreas


___
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] Changing definitions at compile time

2011-06-14 Thread Andreas Naumann


Am 14.06.2011 19:26, schrieb Michael Wild:

On 06/14/2011 07:12 PM, Kfir Lavi wrote:
   


On Tue, Jun 14, 2011 at 8:04 PM, Andreas Naumann
andreas-naum...@gmx.netmailto:andreas-naum...@gmx.net  wrote:

 Am 14.06.2011 18:12, schrieb Kfir Lavi:
 

 Hi,
 I need to compile the code twice. Once with -DA and once with -DB
 My code look like this:
 add_definitions(-DA)
 add_library(${mylib_A} SHARED ${myfiles})
 remove_definitions(-DA)

 add_definitions(-DB)
 add_library(${lib_B} SHARED ${myfiles})
 remove_definitions(-DB)

 What cmake does is to define A and then remove it, so in compile
 time, there
 is now definition of A or B.

 How do I tell cmake that the remove needs to  be in compile time?

 Regards,
 Kfir
   

 You want to create two libraries A and B from the same sourcefiles
 ${myfiles}. The first one have to be compiled with -DA and the
 second one with -DB, haven't it?

 So you could simply set the COMPILE_FLAGS property with
 add_library(A ${myfiles})
 add_library(B ${myfiles})

 set_target_properties(A PROPERTIES COMPILE_FLAGS -DA)
 set_target_properties(B PROPERTIES COMPILE_FLAGS -DB)

 Regards,
 Andreas


Thanks,
This solved my problems.

Again thanks,
Kfir
 

Except that COMPILE_FLAGS is the wrong property. You should use
COMPILE_DEFINITIONS without the -D prefix.

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

   

correct me, if I am wrong, but at
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set_target_properties
there is no property COMPILE_DEFINITIONS.

If I search through the documentation, I get to the target properties.

It seems to me, that COMPILE_DEFINITIONS can set only preprocessor 
definitions like -DVAR=VALUE with

set_target_properties(targ PROPERTIES COMPILE_DEFINITIONS VAR=VALUE).
But if I have a special compiler flag like
-flag:flag_value
I should use
set_target_properties(targ PROPERTIES COMPILE_FLAGS -flag:flag_value)

?

Andreas
___
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] Changing definitions at compile time

2011-06-14 Thread Andreas Naumann


Am 14.06.2011 21:26, schrieb Michael Wild:

On 06/14/2011 09:12 PM, Andreas Naumann wrote:
   

Am 14.06.2011 19:26, schrieb Michael Wild:
 

On 06/14/2011 07:12 PM, Kfir Lavi wrote:

   

On Tue, Jun 14, 2011 at 8:04 PM, Andreas Naumann
andreas-naum...@gmx.netmailto:andreas-naum...@gmx.net   wrote:

  Am 14.06.2011 18:12, schrieb Kfir Lavi:

 

  Hi,
  I need to compile the code twice. Once with -DA and once with -DB
  My code look like this:
  add_definitions(-DA)
  add_library(${mylib_A} SHARED ${myfiles})
  remove_definitions(-DA)

  add_definitions(-DB)
  add_library(${lib_B} SHARED ${myfiles})
  remove_definitions(-DB)

  What cmake does is to define A and then remove it, so in compile
  time, there
  is now definition of A or B.

  How do I tell cmake that the remove needs to  be in compile time?

  Regards,
  Kfir

   

  You want to create two libraries A and B from the same sourcefiles
  ${myfiles}. The first one have to be compiled with -DA and the
  second one with -DB, haven't it?

  So you could simply set the COMPILE_FLAGS property with
  add_library(A ${myfiles})
  add_library(B ${myfiles})

  set_target_properties(A PROPERTIES COMPILE_FLAGS -DA)
  set_target_properties(B PROPERTIES COMPILE_FLAGS -DB)

  Regards,
  Andreas


Thanks,
This solved my problems.

Again thanks,
Kfir

 

Except that COMPILE_FLAGS is the wrong property. You should use
COMPILE_DEFINITIONS without the -D prefix.

Michael


   

correct me, if I am wrong, but at
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set_target_properties

there is no property COMPILE_DEFINITIONS.

If I search through the documentation, I get to the target properties.

It seems to me, that COMPILE_DEFINITIONS can set only preprocessor
definitions like -DVAR=VALUE with
set_target_properties(targ PROPERTIES COMPILE_DEFINITIONS VAR=VALUE).
But if I have a special compiler flag like
-flag:flag_value
I should use
set_target_properties(targ PROPERTIES COMPILE_FLAGS -flag:flag_value)

?

Andreas
 

The assignment part is AFAIK optional (probably should be mentioned in
the docs). And yes, to pass special flags, use COMPILE_FLAGS.
COMPILE_DEFINITIONS should be exclusively used for preprocessor-symbols,
as is the command add_definitions().

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

   

You are right. The assignment is optional, as said in the documentation.

Andreas
___
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] library path stripping

2011-06-11 Thread Andreas Naumann

Am 11.06.2011 16:21, schrieb Michael Hertling:

On 06/10/2011 12:57 PM, Andreas Naumann wrote:

Am 10.06.2011 00:16, schrieb Michael Hertling:

On 06/09/2011 08:18 AM, Andreas Naumann wrote:

Am 09.06.2011 07:35, schrieb Michael Hertling:

On 06/09/2011 07:13 AM, Andreas Naumann wrote:

Am 08.06.2011 20:43, schrieb Andreas Pakulat:

On 08.06.11 20:00:54, Andreas Naumann wrote:

Am 08.06.2011 15:02, schrieb Eric Noulard:

2011/6/8 Andreas Naumannandreas-naum...@gmx.net:

Am 08.06.2011 11:56, schrieb Eric Noulard:

2011/6/8 Andreas Naumannandreas-naum...@gmx.net:

Hi @all,

I have some problem with the library usage in cmake.

It seems to me, that cmake removes the full path of the library, if the
path
is in the environment variable LIBRARY_PATH.
This behaviour cause problems at our system, such that the linker links
against the wrong library.

Is there an option to avoid this splitting?

Did you read that:
http://www.cmake.org/Wiki/CMake_RPATH_handling

Which version of CMake are you using?
On which system ?

We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.

I've read the hints on RPATH handling, but there it is said, that:
By default if you don't change any RPATH related settings, CMake will link
the executables and shared libraries with full RPATH to all used libraries
in the build tree

Yes.
And you did not mention it but the probleme you have occurs when using
the executable **directly from the build dir** right?

what do you mean with using? I cannot even link the executable,
because cmake removes the path from the library without adding the
directory to the library directories.

This means, if I don't set anything related to RPATH, cmake should not strip
the path from the library, should it?

No it shoudn't for the binary in the buitd tree but...
if you do make install the installed binaries will have no RPATH unless
you set

SET(CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_PREFIX}/lib)

# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

I don't even want to install, just build and use.

I played with the example and it was a bit hard to understand, when the path
is stripped from the library.
The problem arises before linking the executable.

This is a different issue.
Could you copy/paste the

add_executable
and
target_link_libraries

statement you use for the offending executable?

simple:
project(test)

cmake_minimum_required(VERSION 2.8)
set(MYLIB /home/andreas/cmake_test/lib/libfoo.so)
add_executable(foo_exec test.cc)
target_link_libraries(foo_exec ${MYLIB})

So the executable gets the full name and the example works, if the
environment variable library_path is not set to
/home/andreas/cmake_test/lib. The link command is:

/usr/bin/c++ CMakeFiles/foo_exec.dir/test.cc.o -o foo_exec
-rdynamic /home/andreas/cmake_test/lib/libfoo.so
-Wl,-rpath,/home/andreas/cmake_test/lib

If I set LIBRARY_PATH to /home/andreas/cmake_test/lib, the directory
is stripped and the link-command gets:

/usr/bin/c++ CMakeFiles/foo_exec.dir/test.cc.o -o foo_exec
-rdynamic -lfoo

I can reproduce this here with CMake 2.8.4.

And before someone else asks (since I thought that might be the error),
the envvar is really LIBRARY_PATH, i.e. not LD_LIBRARY_PATH.

The strange thing is that there's no occurrence of this specific string
anywhere in the cmake sources. There are all kinds of occurrence of
LD_... or CMAKE_... but no string matching just LIBRARY_PATH. So its
unclear why CMake respects that envvar.

Andreas

___
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

The problem is related to the compiler, not to the linker. The
gcc-documentation
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Environment-Variables.html#Environment-Variables
says:

LIBRARY_PATH
The value of LIBRARY_PATH is a colon-separated list of directories, much
like PATH. When configured as a native compiler, GCC tries the
directories thus specified when searching for special linker files, if
it can't find them using GCC_EXEC_PREFIX. Linking using GCC also uses
these directories when searching for ordinary libraries for the -l
option (but directories specified with -L come

Re: [CMake] library path stripping

2011-06-10 Thread Andreas Naumann

Am 10.06.2011 00:16, schrieb Michael Hertling:

On 06/09/2011 08:18 AM, Andreas Naumann wrote:

Am 09.06.2011 07:35, schrieb Michael Hertling:

On 06/09/2011 07:13 AM, Andreas Naumann wrote:

Am 08.06.2011 20:43, schrieb Andreas Pakulat:

On 08.06.11 20:00:54, Andreas Naumann wrote:

Am 08.06.2011 15:02, schrieb Eric Noulard:

2011/6/8 Andreas Naumannandreas-naum...@gmx.net:

Am 08.06.2011 11:56, schrieb Eric Noulard:

2011/6/8 Andreas Naumannandreas-naum...@gmx.net:

Hi @all,

I have some problem with the library usage in cmake.

Is there an option to avoid this splitting?

Did you read that:
http://www.cmake.org/Wiki/CMake_RPATH_handling

Which version of CMake are you using?
On which system ?

We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.

Yes.
And you did not mention it but the probleme you have occurs when using
the executable **directly from the build dir** right?

what do you mean with using? I cannot even link the executable,
because cmake removes the path from the library without adding the
directory to the library directories.

This means, if I don't set anything related to RPATH, cmake should not strip
the path from the library, should it?

No it shoudn't for the binary in the buitd tree but...
if you do make install the installed binaries will have no RPATH unless
you set

SET(CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_PREFIX}/lib)

# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

I don't even want to install, just build and use.

I played with the example and it was a bit hard to understand, when the path
is stripped from the library.
The problem arises before linking the executable.

This is a different issue.
Could you copy/paste the

add_executable
and
target_link_libraries

statement you use for the offending executable?

simple:
project(test)

cmake_minimum_required(VERSION 2.8)
set(MYLIB /home/andreas/cmake_test/lib/libfoo.so)
add_executable(foo_exec test.cc)
target_link_libraries(foo_exec ${MYLIB})

So the executable gets the full name and the example works, if the
environment variable library_path is not set to
/home/andreas/cmake_test/lib. The link command is:

/usr/bin/c++ CMakeFiles/foo_exec.dir/test.cc.o -o foo_exec
-rdynamic /home/andreas/cmake_test/lib/libfoo.so
-Wl,-rpath,/home/andreas/cmake_test/lib

If I set LIBRARY_PATH to /home/andreas/cmake_test/lib, the directory
is stripped and the link-command gets:

/usr/bin/c++ CMakeFiles/foo_exec.dir/test.cc.o -o foo_exec
-rdynamic -lfoo

I can reproduce this here with CMake 2.8.4.

And before someone else asks (since I thought that might be the error),
the envvar is really LIBRARY_PATH, i.e. not LD_LIBRARY_PATH.

Andreas

___
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

The problem is related to the compiler, not to the linker. The
gcc-documentation
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Environment-Variables.html#Environment-Variables
says:

CMake seems to ask the compiler for implicitly used link directories and
removes each path in this list from the libraries in the directories.
Because this information comes from the compiler, cmake

Re: [CMake] library path stripping

2011-06-09 Thread Andreas Naumann

Am 09.06.2011 07:35, schrieb Michael Hertling:

On 06/09/2011 07:13 AM, Andreas Naumann wrote:

Am 08.06.2011 20:43, schrieb Andreas Pakulat:

On 08.06.11 20:00:54, Andreas Naumann wrote:

Am 08.06.2011 15:02, schrieb Eric Noulard:

2011/6/8 Andreas Naumannandreas-naum...@gmx.net:

Am 08.06.2011 11:56, schrieb Eric Noulard:

2011/6/8 Andreas Naumannandreas-naum...@gmx.net:

Hi @all,

I have some problem with the library usage in cmake.

Is there an option to avoid this splitting?

Did you read that:
http://www.cmake.org/Wiki/CMake_RPATH_handling

Which version of CMake are you using?
On which system ?

We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.

Yes.
And you did not mention it but the probleme you have occurs when using
the executable **directly from the build dir** right?

what do you mean with using? I cannot even link the executable,
because cmake removes the path from the library without adding the
directory to the library directories.

This means, if I don't set anything related to RPATH, cmake should not strip
the path from the library, should it?

No it shoudn't for the binary in the buitd tree but...
if you do make install the installed binaries will have no RPATH unless
you set

SET(CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_PREFIX}/lib)

# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

I don't even want to install, just build and use.

I played with the example and it was a bit hard to understand, when the path
is stripped from the library.
The problem arises before linking the executable.

This is a different issue.
Could you copy/paste the

add_executable
and
target_link_libraries

statement you use for the offending executable?

simple:
project(test)

cmake_minimum_required(VERSION 2.8)
set(MYLIB /home/andreas/cmake_test/lib/libfoo.so)
add_executable(foo_exec test.cc)
target_link_libraries(foo_exec ${MYLIB})

So the executable gets the full name and the example works, if the
environment variable library_path is not set to
/home/andreas/cmake_test/lib. The link command is:

/usr/bin/c++ CMakeFiles/foo_exec.dir/test.cc.o -o foo_exec
-rdynamic /home/andreas/cmake_test/lib/libfoo.so
-Wl,-rpath,/home/andreas/cmake_test/lib

If I set LIBRARY_PATH to /home/andreas/cmake_test/lib, the directory
is stripped and the link-command gets:

/usr/bin/c++ CMakeFiles/foo_exec.dir/test.cc.o -o foo_exec
-rdynamic -lfoo

I can reproduce this here with CMake 2.8.4.

And before someone else asks (since I thought that might be the error),
the envvar is really LIBRARY_PATH, i.e. not LD_LIBRARY_PATH.

Andreas

___
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

The problem is related to the compiler, not to the linker. The
gcc-documentation
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Environment-Variables.html#Environment-Variables
says:

CMake seems to ask the compiler for implicitly used link directories and
removes each path in this list from the libraries in the directories.
Because this information comes from the compiler, cmake cannot
distinguish between working and not working directories.
My question is now, why does cmake remove the paths? If the use
specifies a library with full path, he wants EXACTLY this library

[CMake] library path stripping

2011-06-08 Thread Andreas Naumann


Hi @all,

I have some problem with the library usage in cmake.

It seems to me, that cmake removes the full path of the library, if the 
path is in the environment variable LIBRARY_PATH.
This behaviour cause problems at our system, such that the linker links 
against the wrong library.


Is there an option to avoid this splitting?

Regards,
Andreas Naumann
___
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] library path stripping

2011-06-08 Thread Andreas Naumann


Am 08.06.2011 11:56, schrieb Eric Noulard:

2011/6/8 Andreas Naumannandreas-naum...@gmx.net:
   

Hi @all,

I have some problem with the library usage in cmake.

It seems to me, that cmake removes the full path of the library, if the path
is in the environment variable LIBRARY_PATH.
This behaviour cause problems at our system, such that the linker links
against the wrong library.

Is there an option to avoid this splitting?
 

Did you read that:
http://www.cmake.org/Wiki/CMake_RPATH_handling

Which version of CMake are you using?
On which system ?


   

We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.

I've read the hints on RPATH handling, but there it is said, that:
By default if you don't change any RPATH related settings, CMake will 
link the executables and shared libraries with full RPATH to all used 
libraries in the build tree


This means, if I don't set anything related to RPATH, cmake should not 
strip the path from the library, should it?


I played with the example and it was a bit hard to understand, when the 
path is stripped from the library.
The problem arises before linking the executable. We link to a library, 
which exists in two different directories:

/usr/lib64
and
somewhere/lib/

At the same time, the environment variable LIBRARY_PATH is set to 
somewhere/lib. In this case, cmake removes the path from the library 
name, but does not append it as -L to the linker search paths.
Now it is up to the linker to choose the right library, which is really 
bad! In our case (gcc 4.1.2 on Suse) it selects the wrong library.


Is there any possibility to avoid this environmentvariable dependent 
splitting?



___
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] library path stripping

2011-06-08 Thread Andreas Naumann

Am 08.06.2011 20:43, schrieb Andreas Pakulat:

On 08.06.11 20:00:54, Andreas Naumann wrote:

Am 08.06.2011 15:02, schrieb Eric Noulard:

2011/6/8 Andreas Naumannandreas-naum...@gmx.net:

Am 08.06.2011 11:56, schrieb Eric Noulard:

2011/6/8 Andreas Naumannandreas-naum...@gmx.net:

Hi @all,

I have some problem with the library usage in cmake.

Is there an option to avoid this splitting?

Did you read that:
http://www.cmake.org/Wiki/CMake_RPATH_handling

Which version of CMake are you using?
On which system ?

We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.

Yes.
And you did not mention it but the probleme you have occurs when using
the executable **directly from the build dir** right?

what do you mean with using? I cannot even link the executable,
because cmake removes the path from the library without adding the
directory to the library directories.

This means, if I don't set anything related to RPATH, cmake should not strip
the path from the library, should it?

No it shoudn't for the binary in the buitd tree but...
if you do make install the installed binaries will have no RPATH unless
you set

SET(CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_PREFIX}/lib)

# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

I don't even want to install, just build and use.

I played with the example and it was a bit hard to understand, when the path
is stripped from the library.
The problem arises before linking the executable.

This is a different issue.
Could you copy/paste the

add_executable
and
target_link_libraries

statement you use for the offending executable?

simple:
project(test)

cmake_minimum_required(VERSION 2.8)
set(MYLIB /home/andreas/cmake_test/lib/libfoo.so)
add_executable(foo_exec test.cc)
target_link_libraries(foo_exec ${MYLIB})

So the executable gets the full name and the example works, if the
environment variable library_path is not set to
/home/andreas/cmake_test/lib. The link command is:

/usr/bin/c++ CMakeFiles/foo_exec.dir/test.cc.o -o foo_exec
-rdynamic /home/andreas/cmake_test/lib/libfoo.so
-Wl,-rpath,/home/andreas/cmake_test/lib

If I set LIBRARY_PATH to /home/andreas/cmake_test/lib, the directory
is stripped and the link-command gets:

/usr/bin/c++ CMakeFiles/foo_exec.dir/test.cc.o -o foo_exec
-rdynamic -lfoo

I can reproduce this here with CMake 2.8.4.

And before someone else asks (since I thought that might be the error),
the envvar is really LIBRARY_PATH, i.e. not LD_LIBRARY_PATH.

Andreas

___
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

The problem is related to the compiler, not to the linker. The
gcc-documentation

http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Environment-Variables.html#Environment-Variables
says:

Currently, we print a warning, if the variable LIBRARY_PATH is set in
the environment.

Andreas
___
Powered by www.kitware.com

Visit other

71 matches

Mail list logo