Re: [CMake] link_libraries
Ranjeet Kuruvilla wrote:
> I have read that link_libraries command has gotten deprecated for version
> 3.10 and instead one needs to use link_librariestarget_link_libraries has
> one major disadvantage, in that it is required to put that statement after
> add_executable. I have here a CMake file for many different projects with
> the same folder structure, that scans a subfolder for files ending with
> .cmake. Those .cmake files can contain extra includes, definitions and
> libraries. With link_libraries I can put all statements inside one .cmake
> file. With target_link_libraries statement however I need 2 .cmake files,
> one before add_executable and one after for all the libraries. So I ask you
> to keep link_libraries alive!
tl;dr: no, surely not, it just adds libraries to probably unrelated targets.
> cmake_minimum_required( VERSION 3.10.0 )
>
> project( ${PROJ_NAME} ${CXX} )enable_language(CXX)
> set( CMAKE_VERBOSE_MAKEFILE ON)
>
> set( OPTIMIZING_FLAGS -O2)
>
> set( CUSTOMBUILD "customBuild" )
> ...include_directories( BEFORE "/usr/local/include/x86_64-linux-gnu")
That is a compiler specific include, that should never be needed. The compiler
adds that anyway, and if you use a different compiler this will probably badly
screw things up.
> link_directories( BEFORE "/usr/lib")
That is a default link directory and is not needed.
> link_directories( BEFORE
> "/usr/lib/boost" ...
> IF(EXISTS ${ CUSTOMBUILD})
> message("Found custom cmake to build")
> file( GLOB_RECURSE CMAKE_ITEMS LIST_DIRECTORIES false
> ${CONST_BASE_PATH_CUSTOMBUILD}*${CMAKE_SUFFIX})
> foreach(CMAKE_ITEM ${CMAKE_ITEMS})
> message("Add cmake file " ${CMAKE_ITEM})
> include(${CMAKE_ITEM})
> endforeach(CMAKE_ITEM)
> endif()...
If you like it that way, fine…
> link_libraries(-lqpidclient -lqpidmessaging)
> link_libraries( -ljsoncpp)
> link_libraries( -lpistache)
> link_libraries( -lboost_system -lboost_thread -lboost_regex
> -lboost_filesystem -lboost_random -lboost_date_time -lboost_log
> -lboost_program_options -lboost_signals)link_libraries( -lpulse-simple
> -lpulse)
> link_libraries( -lcrypto -lpthread -lcurl)
> link_libraries(-lgstreamer-1.0 -lgstrtp-1.0 -lgstrtsp-1.0 -lgstsdp-1.0 -
lgstbase-1.0)
> link_libraries( -lgobject-2.0 -lsigc-2.0)
> link_libraries( -lssl -levent_openssl)
> link_libraries( -lcassandra)
> link_libraries( -lwebsockets)
> link_libraries( -levent -levent_pthreads -lcrypto -lcrypto++)
> link_libraries( -lm -lrt -lz -ldl -lva -lX11 -lm)
> link_libraries(${SEASTAR_DIR_LIBS})
but this is just broken. This will break
-when you update one of those libraries and it needs new dependencies
-when the libraries have different names e.g. because of a custom build
-probably just when you leave your own Linux distro
-for sure if you ever go to any other system (*BSD, Mac, Windows)
> add_executable( ${PROJ_NAME} ${SOURCES} )
When you use the modern version with (imported) targets you can even skip the
include_directories things. I will reduce my example to 2 libraries for
clarity, but it will work with the whole bunch also:
find_library(OpenSSL REQUIRED)
find_library(Boost REQUIRED regex)
add_library(foo ...)
target_link_libraries(foo
# the usage of SSL is buried inside the lib and just an implementation
# detail
PRIVATE OpenSSL::SSL
# a Boost Regex is part of the API, so everyone using this library needs
# to get the headers and link to Boost
PUBLIC Boost:regex
)
add_executable(bar ...)
target_link_libraries(bar foo)
So bar also links to Boost, it get's all the headers and more needed to use
Boost.
For the very same reason people started using include-what-you-use one should
not use link_libraries: explicitely specify what you need, otherwise you very
likely break your build system if any of your dependencies changes and
suddenly does not drag in one of your needed pieces anymore.
Eike
signature.asc
Description: This is a digitally signed message part.
--
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] link_libraries
I have read that link_libraries command has gotten deprecated for version 3.10
and instead one needs to use link_librariestarget_link_libraries has one major
disadvantage, in that it is required to put that statement after add_executable.
I have here a CMake file for many different projects with the same folder
structure, that scans a subfolder for files ending with .cmake. Those .cmake
files can contain extra includes, definitions and libraries.
With link_libraries I can put all statements inside one .cmake file. With
target_link_libraries statement however I need 2 .cmake files, one before
add_executable and one after for all the libraries.
So I ask you to keep link_libraries alive!
cmake_minimum_required( VERSION 3.10.0 )
project( ${PROJ_NAME} ${CXX} )enable_language(CXX)
set( CMAKE_VERBOSE_MAKEFILE ON)
set( OPTIMIZING_FLAGS -O2)
set( CUSTOMBUILD "customBuild" )
...include_directories( BEFORE "/usr/local/include/x86_64-linux-gnu")
link_directories( BEFORE "/usr/lib")link_directories( BEFORE "/usr/lib/boost"
...
IF(EXISTS ${ CUSTOMBUILD}) message("Found custom cmake to build") file(
GLOB_RECURSE CMAKE_ITEMS LIST_DIRECTORIES false
${CONST_BASE_PATH_CUSTOMBUILD}*${CMAKE_SUFFIX}) foreach(CMAKE_ITEM
${CMAKE_ITEMS}) message("Add cmake file " ${CMAKE_ITEM})
include(${CMAKE_ITEM}) endforeach(CMAKE_ITEM)endif()...link_libraries(
-lqpidclient -lqpidmessaging)
link_libraries( -ljsoncpp)link_libraries( -lpistache)link_libraries(
-lboost_system -lboost_thread -lboost_regex -lboost_filesystem -lboost_random
-lboost_date_time -lboost_log -lboost_program_options
-lboost_signals)link_libraries( -lpulse-simple -lpulse)link_libraries( -lcrypto
-lpthread -lcurl)link_libraries( -lgstreamer-1.0 -lgstrtp-1.0 -lgstrtsp-1.0
-lgstsdp-1.0 -lgstbase-1.0 )link_libraries( -lgobject-2.0
-lsigc-2.0)link_libraries( -lssl -levent_openssl)link_libraries(
-lcassandra)link_libraries( -lwebsockets)link_libraries( -levent
-levent_pthreads -lcrypto -lcrypto++ )link_libraries( -lm -lrt -lz -ldl -lva
-lX11 -lm)link_libraries( ${SEASTAR_DIR_LIBS})
add_executable( ${PROJ_NAME} ${SOURCES} )
--
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-developers] [CMake] LINK_LIBRARIES not spilled to response file
I have added a patch that should help. (Tested on Darwin only) Please check it for Windows before apply. Claus On 09.07.2012, at 12:13, Zaheer Chothia wrote: Done: http://public.kitware.com/Bug/view.php?id=13385 --Zaheer -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] LINK_LIBRARIES not spilled to response file
On Jul 8, 2012 10:59 PM, Zaheer Chothia zaheer.chot...@gmail.com wrote:
Hello,
I posted a mail here [1] but have yet to receive any replies. I think my
last
message was too long and detailed so let me summarize:
* Command line length is limited on Windows.
* To alleviate this, CMake places object files into a response file, but
the
same is not done for libraries.
* This can pose a problem when the link line becomes too long.
I am primarily interested in a solution for the Ninja generator, although
this
issue affects other generators too. My previous mail contains a testcase
and
proposed solution. In the interim another issue [2] was posted, but that
is
orthogonal and does not solve what is discussed here.
I'd suggest you raise a defect. Kitware are pretty good at fixing things or
suggesting temporary workarounds until the underlying issue is fixed.
Kind regards,
--Zaheer
[1]: http://www.cmake.org/pipermail/cmake/2012-June/051065.html
[2]: http://public.kitware.com/Bug/view.php?id=13366
On Thu, Jun 28, 2012 at 3:50 PM, Zaheer Chothia zaheer.chot...@gmail.com
wrote:
Hello,
I encountered an issue while building a CMake project where one target
is linked
against a large number of libraries. Unlike object files, libraries are
not
placed into a response file, which can lead to build commands which
exceed the
length limits on Windows. For reference, I am using the CMake 2.8.9-rc1
and
Ninja generator with Microsoft compilers.
Following this mail is a testcase generator [1] to demonstrate this issue
(sample project attached for convenience). The build fails with this
error (for
readibility I replaced a long sequence of libraries with ...):
FAILED: cmd.exe /c cd. C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @hello.exe.rsp /DWIN32
/D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /Fehello.exe
/Fdhello.pdb -link /implib:hello.lib /version:0.0 /STACK:1000
/machine:X86 /debug /INCREMENTAL /subsystem:console
src\abcdefghijklmnopqrstuvwxyz0123456789\library1.lib
src\abcdefghijklmnopqrstuvwxyz0123456789\library2.lib ...
kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib cd.
The command line is too long.
ninja: build stopped: subcommand failed.
Although this example may seem artificial, with the use case I refer to
(i)
libraries are are specified by absolute paths so they are indeed
reasonably long
and (ii) since there are third-party libraries involved I would not be
able to
simply combine source files into one large library as is possible here.
I
should also mention that this issue does not affect the Visual Studio
generators, however it is present with the following: Ninja, MinGW
Makefiles, NMake Makefiles, MSYS Makefiles. For Ninja I suspect that the
indirection via cmd.exe imposes a maximum command length of 8192 KB,
whereas for
the others this will likely be 32 KB (CreateProcess).
I would be quite content if this is fixed for the Ninja generator. A
simple fix
would be to adapt the build rules by moving $LINK_LIBRARIES from
'command' to
'rspfile_content':
--- rules.ninja.bak 2012-06-28 15:23:35 +0100
+++ rules.ninja 2012-06-28 15:38:09 +0100
@@ -40,10 +40,10 @@
# Rule for linking C executable.
rule C_EXECUTABLE_LINKER_RSPFILE
- command = cmd.exe /c $PRE_LINK C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @$out.rsp $FLAGS
/Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
$LINK_FLAGS $LINK_LIBRARIES $POST_BUILD
+ command = cmd.exe /c $PRE_LINK C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @$out.rsp $FLAGS
/Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
$LINK_FLAGS $POST_BUILD
description = Linking C executable $out
rspfile = $out.rsp
- rspfile_content = $in
+ rspfile_content = $in $LINK_LIBRARIES
Best,
--Zaheer
[1]: BEGIN: testcase.sh
---
#!/bin/bash -e
NUM_LIBRARIES=500
# Use a long path to quickly exhaust the command-line length limit.
SRC_DIR=src/abcdefghijklmnopqrstuvwxyz0123456789
# Root directory: application and CMakeLists.txt
echo int main() { return 0; } hello.c
cat EOF CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(Hello)
add_subdirectory($SRC_DIR)
add_executable(hello hello.c)
target_link_libraries(hello
EOF
for ((i = 1; i = $NUM_LIBRARIES; i++)); do
echo library$i CMakeLists.txt
done
echo ) CMakeLists.txt
# Libraries: sources and CMakeLists.txt
mkdir -p $SRC_DIR
[[ -f $SRC_DIR/CMakeLists.txt ]] rm $SRC_DIR/CMakeLists.txt
for ((i = 1; i = $NUM_LIBRARIES; i++)); do
echo int function$i() { return $i; } $SRC_DIR/function$i.c
echo
Re: [CMake] LINK_LIBRARIES not spilled to response file
Done: http://public.kitware.com/Bug/view.php?id=13385
--Zaheer
On Mon, Jul 9, 2012 at 8:15 AM, Brett Delle Grazie
brett.dellegra...@gmail.com wrote:
On Jul 8, 2012 10:59 PM, Zaheer Chothia zaheer.chot...@gmail.com wrote:
Hello,
I posted a mail here [1] but have yet to receive any replies. I think my
last
message was too long and detailed so let me summarize:
* Command line length is limited on Windows.
* To alleviate this, CMake places object files into a response file, but
the
same is not done for libraries.
* This can pose a problem when the link line becomes too long.
I am primarily interested in a solution for the Ninja generator, although
this
issue affects other generators too. My previous mail contains a testcase
and
proposed solution. In the interim another issue [2] was posted, but that
is
orthogonal and does not solve what is discussed here.
I'd suggest you raise a defect. Kitware are pretty good at fixing things or
suggesting temporary workarounds until the underlying issue is fixed.
Kind regards,
--Zaheer
[1]: http://www.cmake.org/pipermail/cmake/2012-June/051065.html
[2]: http://public.kitware.com/Bug/view.php?id=13366
On Thu, Jun 28, 2012 at 3:50 PM, Zaheer Chothia zaheer.chot...@gmail.com
wrote:
Hello,
I encountered an issue while building a CMake project where one target is
linked
against a large number of libraries. Unlike object files, libraries are
not
placed into a response file, which can lead to build commands which
exceed the
length limits on Windows. For reference, I am using the CMake 2.8.9-rc1
and
Ninja generator with Microsoft compilers.
Following this mail is a testcase generator [1] to demonstrate this issue
(sample project attached for convenience). The build fails with this
error (for
readibility I replaced a long sequence of libraries with ...):
FAILED: cmd.exe /c cd. C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @hello.exe.rsp /DWIN32
/D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /Fehello.exe
/Fdhello.pdb -link /implib:hello.lib /version:0.0 /STACK:1000
/machine:X86 /debug /INCREMENTAL /subsystem:console
src\abcdefghijklmnopqrstuvwxyz0123456789\library1.lib
src\abcdefghijklmnopqrstuvwxyz0123456789\library2.lib ...
kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib cd.
The command line is too long.
ninja: build stopped: subcommand failed.
Although this example may seem artificial, with the use case I refer to
(i)
libraries are are specified by absolute paths so they are indeed
reasonably long
and (ii) since there are third-party libraries involved I would not be
able to
simply combine source files into one large library as is possible here.
I
should also mention that this issue does not affect the Visual Studio
generators, however it is present with the following: Ninja, MinGW
Makefiles, NMake Makefiles, MSYS Makefiles. For Ninja I suspect that the
indirection via cmd.exe imposes a maximum command length of 8192 KB,
whereas for
the others this will likely be 32 KB (CreateProcess).
I would be quite content if this is fixed for the Ninja generator. A
simple fix
would be to adapt the build rules by moving $LINK_LIBRARIES from
'command' to
'rspfile_content':
--- rules.ninja.bak 2012-06-28 15:23:35 +0100
+++ rules.ninja 2012-06-28 15:38:09 +0100
@@ -40,10 +40,10 @@
# Rule for linking C executable.
rule C_EXECUTABLE_LINKER_RSPFILE
- command = cmd.exe /c $PRE_LINK C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @$out.rsp $FLAGS
/Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
$LINK_FLAGS $LINK_LIBRARIES $POST_BUILD
+ command = cmd.exe /c $PRE_LINK C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @$out.rsp $FLAGS
/Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
$LINK_FLAGS $POST_BUILD
description = Linking C executable $out
rspfile = $out.rsp
- rspfile_content = $in
+ rspfile_content = $in $LINK_LIBRARIES
Best,
--Zaheer
[1]: BEGIN: testcase.sh
---
#!/bin/bash -e
NUM_LIBRARIES=500
# Use a long path to quickly exhaust the command-line length limit.
SRC_DIR=src/abcdefghijklmnopqrstuvwxyz0123456789
# Root directory: application and CMakeLists.txt
echo int main() { return 0; } hello.c
cat EOF CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(Hello)
add_subdirectory($SRC_DIR)
add_executable(hello hello.c)
target_link_libraries(hello
EOF
for ((i = 1; i = $NUM_LIBRARIES; i++)); do
echo library$i CMakeLists.txt
done
echo ) CMakeLists.txt
# Libraries: sources and CMakeLists.txt
mkdir -p $SRC_DIR
[[ -f
Re: [CMake] LINK_LIBRARIES not spilled to response file
Hello,
I posted a mail here [1] but have yet to receive any replies. I think my
last
message was too long and detailed so let me summarize:
* Command line length is limited on Windows.
* To alleviate this, CMake places object files into a response file, but the
same is not done for libraries.
* This can pose a problem when the link line becomes too long.
I am primarily interested in a solution for the Ninja generator, although
this
issue affects other generators too. My previous mail contains a testcase
and
proposed solution. In the interim another issue [2] was posted, but that is
orthogonal and does not solve what is discussed here.
Kind regards,
*--Zaheer*
*
*
[1]: http://www.cmake.org/pipermail/cmake/2012-June/051065.html
[2]: http://public.kitware.com/Bug/view.php?id=13366
On Thu, Jun 28, 2012 at 3:50 PM, Zaheer Chothia zaheer.chot...@gmail.comwrote:
Hello,
I encountered an issue while building a CMake project where one target is
linked
against a large number of libraries. Unlike object files, libraries are
not
placed into a response file, which can lead to build commands which exceed
the
length limits on Windows. For reference, I am using the CMake 2.8.9-rc1
and
Ninja generator with Microsoft compilers.
Following this mail is a testcase generator [1] to demonstrate this issue
(sample project attached for convenience). The build fails with this
error (for
readibility I replaced a long sequence of libraries with ...):
FAILED: cmd.exe /c cd. C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @hello.exe.rsp /DWIN32
/D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /Fehello.exe
/Fdhello.pdb -link /implib:hello.lib /version:0.0 /STACK:1000
/machine:X86 /debug /INCREMENTAL /subsystem:console
src\abcdefghijklmnopqrstuvwxyz0123456789\library1.lib
src\abcdefghijklmnopqrstuvwxyz0123456789\library2.lib ...
kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib cd.
The command line is too long.
ninja: build stopped: subcommand failed.
Although this example may seem artificial, with the use case I refer to (i)
libraries are are specified by absolute paths so they are indeed
reasonably long
and (ii) since there are third-party libraries involved I would not be
able to
simply combine source files into one large library as is possible here. I
should also mention that this issue does not affect the Visual Studio
generators, however it is present with the following: Ninja, MinGW
Makefiles, NMake Makefiles, MSYS Makefiles. For Ninja I suspect that the
indirection via cmd.exe imposes a maximum command length of 8192 KB,
whereas for
the others this will likely be 32 KB (CreateProcess).
I would be quite content if this is fixed for the Ninja generator. A
simple fix
would be to adapt the build rules by moving $LINK_LIBRARIES from 'command'
to
'rspfile_content':
--- rules.ninja.bak 2012-06-28 15:23:35 +0100
+++ rules.ninja 2012-06-28 15:38:09 +0100
@@ -40,10 +40,10 @@
# Rule for linking C executable.
rule C_EXECUTABLE_LINKER_RSPFILE
- command = cmd.exe /c $PRE_LINK C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @$out.rsp $FLAGS
/Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
$LINK_FLAGS $LINK_LIBRARIES $POST_BUILD
+ command = cmd.exe /c $PRE_LINK C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @$out.rsp $FLAGS
/Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
$LINK_FLAGS $POST_BUILD
description = Linking C executable $out
rspfile = $out.rsp
- rspfile_content = $in
+ rspfile_content = $in $LINK_LIBRARIES
Best,
--Zaheer
[1]: BEGIN: testcase.sh
---
#!/bin/bash -e
NUM_LIBRARIES=500
# Use a long path to quickly exhaust the command-line length limit.
SRC_DIR=src/abcdefghijklmnopqrstuvwxyz0123456789
# Root directory: application and CMakeLists.txt
echo int main() { return 0; } hello.c
cat EOF CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(Hello)
add_subdirectory($SRC_DIR)
add_executable(hello hello.c)
target_link_libraries(hello
EOF
for ((i = 1; i = $NUM_LIBRARIES; i++)); do
echo library$i CMakeLists.txt
done
echo ) CMakeLists.txt
# Libraries: sources and CMakeLists.txt
mkdir -p $SRC_DIR
[[ -f $SRC_DIR/CMakeLists.txt ]] rm $SRC_DIR/CMakeLists.txt
for ((i = 1; i = $NUM_LIBRARIES; i++)); do
echo int function$i() { return $i; } $SRC_DIR/function$i.c
echo add_library(library$i function$i.c) $SRC_DIR/CMakeLists.txt
done
echo Testcase has been setup: now build with CMake and Ninja generator.
[1]: END: testcase.sh
---
--
[CMake] LINK_LIBRARIES not spilled to response file
Hello,
I encountered an issue while building a CMake project where one target is linked
against a large number of libraries. Unlike object files, libraries are not
placed into a response file, which can lead to build commands which exceed the
length limits on Windows. For reference, I am using the CMake 2.8.9-rc1 and
Ninja generator with Microsoft compilers.
Following this mail is a testcase generator [1] to demonstrate this issue
(sample project attached for convenience). The build fails with this error (for
readibility I replaced a long sequence of libraries with ...):
FAILED: cmd.exe /c cd. C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @hello.exe.rsp /DWIN32
/D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /Fehello.exe
/Fdhello.pdb -link /implib:hello.lib /version:0.0 /STACK:1000
/machine:X86 /debug /INCREMENTAL /subsystem:console
src\abcdefghijklmnopqrstuvwxyz0123456789\library1.lib
src\abcdefghijklmnopqrstuvwxyz0123456789\library2.lib ...
kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib cd.
The command line is too long.
ninja: build stopped: subcommand failed.
Although this example may seem artificial, with the use case I refer to (i)
libraries are are specified by absolute paths so they are indeed reasonably long
and (ii) since there are third-party libraries involved I would not be able to
simply combine source files into one large library as is possible here. I
should also mention that this issue does not affect the Visual Studio
generators, however it is present with the following: Ninja, MinGW
Makefiles, NMake Makefiles, MSYS Makefiles. For Ninja I suspect that the
indirection via cmd.exe imposes a maximum command length of 8192 KB, whereas for
the others this will likely be 32 KB (CreateProcess).
I would be quite content if this is fixed for the Ninja generator. A simple fix
would be to adapt the build rules by moving $LINK_LIBRARIES from 'command' to
'rspfile_content':
--- rules.ninja.bak 2012-06-28 15:23:35 +0100
+++ rules.ninja 2012-06-28 15:38:09 +0100
@@ -40,10 +40,10 @@
# Rule for linking C executable.
rule C_EXECUTABLE_LINKER_RSPFILE
- command = cmd.exe /c $PRE_LINK C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @$out.rsp $FLAGS
/Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
$LINK_FLAGS $LINK_LIBRARIES $POST_BUILD
+ command = cmd.exe /c $PRE_LINK C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @$out.rsp $FLAGS
/Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
$LINK_FLAGS $POST_BUILD
description = Linking C executable $out
rspfile = $out.rsp
- rspfile_content = $in
+ rspfile_content = $in $LINK_LIBRARIES
Best,
--Zaheer
[1]: BEGIN: testcase.sh ---
#!/bin/bash -e
NUM_LIBRARIES=500
# Use a long path to quickly exhaust the command-line length limit.
SRC_DIR=src/abcdefghijklmnopqrstuvwxyz0123456789
# Root directory: application and CMakeLists.txt
echo int main() { return 0; } hello.c
cat EOF CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(Hello)
add_subdirectory($SRC_DIR)
add_executable(hello hello.c)
target_link_libraries(hello
EOF
for ((i = 1; i = $NUM_LIBRARIES; i++)); do
echo library$i CMakeLists.txt
done
echo ) CMakeLists.txt
# Libraries: sources and CMakeLists.txt
mkdir -p $SRC_DIR
[[ -f $SRC_DIR/CMakeLists.txt ]] rm $SRC_DIR/CMakeLists.txt
for ((i = 1; i = $NUM_LIBRARIES; i++)); do
echo int function$i() { return $i; } $SRC_DIR/function$i.c
echo add_library(library$i function$i.c) $SRC_DIR/CMakeLists.txt
done
echo Testcase has been setup: now build with CMake and Ninja generator.
[1]: END: testcase.sh ---
cmake_testcase_many_libraries_rspfile.tar.bz2
Description: BZip2 compressed data
--
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] link_libraries() deprecated. Why?
So, what am I to do? Should I file a bug report for this? If so, what should I put in it, cause it's not really a bug. It would at least be good to know if deprecated features will ever be removed, or if I need to set one or more policies. Best regards, Marcel Loose. On Thu, 2009-04-02 at 08:27 -0400, Philip Lowman wrote: On Thu, Apr 2, 2009 at 4:03 AM, Marcel Loose lo...@astron.nl wrote: Hi Philip, Thanks for your reply. Your solution is ok, but it looks a bit like a workaround for a feature that is missing, but was once there: link_libraries(). To me, it's not really clear why link_libraries() has been deprecated and, for example, include_directories() has not. IMHO, using target_link_libraries() for a general library has a too fine granularity. Suppose include_directories() were deprecated as well in favour of, say, target_include_directories(). That would create the same problem: carry around variables holding a bunch of include directories that must be supplied to each target. I don't like to use deprecated features, so I would love to see the deprecation of link_libraries() to be reverted. But maybe I'm missing a good reason for not doing so. I'm not sure why the feature was deprecated. I didn't even know about it until you posted the question! I also don't know exactly what CMake's stance is on deprecation although I think the official policy is not to remove old commands because it would break backwards compatibility. The word deprecated can imply that the feature is meant to be removed but doesn't necessarily mean so. The ambiguity there really sucks. Perhaps obsolete is a better choice of words. -- Philip Lowman ___ 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] link_libraries() deprecated. Why?
Hi Alex,
Thanks for the clarification. The difference between the two is subtle,
but I think I understand what you mean. I'll play a bit with both
commands to see which one fits best for me.
Best regards,
Marcel Loose.
P.S.: Our posts crossed, so you can ignore my question about filing a
bug.
On Thu, 2009-04-02 at 09:01 -0400, Brad King wrote:
Alex,
Looking at history I see this was deprecated by a patch you sent me.
Originally we called the command 'discouraged'. Why did we change
to 'deprecated'?
Marcel Loose wrote:
Thanks for your reply. Your solution is ok, but it looks a bit like a
workaround for a feature that is missing, but was once there:
link_libraries().
To me, it's not really clear why link_libraries() has been deprecated
and, for example, include_directories() has not. IMHO, using
target_link_libraries() for a general library has a too fine
granularity.
Suppose include_directories() were deprecated as well in favour of, say,
target_include_directories(). That would create the same problem: carry
around variables holding a bunch of include directories that must be
supplied to each target.
I don't like to use deprecated features, so I would love to see the
deprecation of link_libraries() to be reverted. But maybe I'm missing a
good reason for not doing so.
Marcel, feel free to use link_libraries if there is no better solution.
We do not plan to take it away. The word 'deprecated' is too strong.
One difference between link_libraries and include_directories is that
library dependencies are chained automatically. If you write
add_library(mylib mylib.c)
target_link_libraries(mylib m)
add_executable(myexe myexe.c)
target_link_libraries(myexe mylib)
then 'myexe' will link to both 'mylib' and 'm' (-lmylib -lm).
If you write
link_libraries(m)
add_library(mylib mylib.c)
add_executable(myexe myexe.c)
target_link_libraries(myexe mylib)
then 'myexe' will link 'm', 'mylib', and then 'm' again (-lm -lmylib -lm).
The reason is that the add_executable line copies the current set of
directory-level libraries from link_libraries when it is created. Any
target_link_libraries after that are appended. A strict rule our link
line generator follows is that the original link line for a target is
preserved, so for 'myexe' it starts with 'm' and 'mylib'. Then it sees
that 'mylib' depends on 'm' and appends the library to the final link line.
If your project has a hierarchy of libraries already, just use
target_link_libraries to add the globally required library to the
top-most libraries in the hierarchy. Link dependency analysis will
take care of the rest.
-Brad
On Wed, 2009-04-01 at 23:50 -0400, Philip Lowman wrote:
On Wed, Apr 1, 2009 at 5:35 PM, Marcel Loose lo...@astron.nl wrote:
Hi all,
I was wondering why the link_libraries() command has been
deprecated. Commands like include_directories() and
link_directories() which have the same scope have not been
deprecated. I think that link_libraries() has its virtues too.
My reason for asking this, is that I wonder what's the proper
way to add a library to *all* targets in a project; for
example, a logging library or a threads library. Here,
link_libraries() provides IMHO a much cleaner solution, than
target_link_libraries(). The latter requires me to keep track
of the globally used library in a variable that must be passed
around; and for each target I must explicitly specify its
dependency on this library by using target_link_libraries().
Or, am I missing something, and is there a cleaner way to do
this, without using a deprecated feature?
Often I have seen people write functions to help with this especially
if you have more than one common library.
function(link_target_against_common_libs _target)
target_link_libraries(${_target} ${WHATEVER_LIBRARY})
endfunction()
Another approach is if you have a low level library as part of your
codebase that everyone depends upon you can simply make it dependent
on your threading or logging libraries and anyone that is dependent
against it will automatically link against the threading or logging
library.
--
Philip Lowman
___
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
Re: [CMake] link_libraries() deprecated. Why?
Hi Philip,
Thanks for your reply. Your solution is ok, but it looks a bit like a
workaround for a feature that is missing, but was once there:
link_libraries().
To me, it's not really clear why link_libraries() has been deprecated
and, for example, include_directories() has not. IMHO, using
target_link_libraries() for a general library has a too fine
granularity.
Suppose include_directories() were deprecated as well in favour of, say,
target_include_directories(). That would create the same problem: carry
around variables holding a bunch of include directories that must be
supplied to each target.
I don't like to use deprecated features, so I would love to see the
deprecation of link_libraries() to be reverted. But maybe I'm missing a
good reason for not doing so.
Best regards,
Marcel Loose.
On Wed, 2009-04-01 at 23:50 -0400, Philip Lowman wrote:
On Wed, Apr 1, 2009 at 5:35 PM, Marcel Loose lo...@astron.nl wrote:
Hi all,
I was wondering why the link_libraries() command has been
deprecated. Commands like include_directories() and
link_directories() which have the same scope have not been
deprecated. I think that link_libraries() has its virtues too.
My reason for asking this, is that I wonder what's the proper
way to add a library to *all* targets in a project; for
example, a logging library or a threads library. Here,
link_libraries() provides IMHO a much cleaner solution, than
target_link_libraries(). The latter requires me to keep track
of the globally used library in a variable that must be passed
around; and for each target I must explicitly specify its
dependency on this library by using target_link_libraries().
Or, am I missing something, and is there a cleaner way to do
this, without using a deprecated feature?
Often I have seen people write functions to help with this especially
if you have more than one common library.
function(link_target_against_common_libs _target)
target_link_libraries(${_target} ${WHATEVER_LIBRARY})
endfunction()
Another approach is if you have a low level library as part of your
codebase that everyone depends upon you can simply make it dependent
on your threading or logging libraries and anyone that is dependent
against it will automatically link against the threading or logging
library.
--
Philip Lowman
___
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] link_libraries() deprecated. Why?
On Thu, Apr 2, 2009 at 4:03 AM, Marcel Loose lo...@astron.nl wrote: Hi Philip, Thanks for your reply. Your solution is ok, but it looks a bit like a workaround for a feature that is missing, but was once there: link_libraries(). To me, it's not really clear why link_libraries() has been deprecated and, for example, include_directories() has not. IMHO, using target_link_libraries() for a general library has a too fine granularity. Suppose include_directories() were deprecated as well in favour of, say, target_include_directories(). That would create the same problem: carry around variables holding a bunch of include directories that must be supplied to each target. I don't like to use deprecated features, so I would love to see the deprecation of link_libraries() to be reverted. But maybe I'm missing a good reason for not doing so. I'm not sure why the feature was deprecated. I didn't even know about it until you posted the question! I also don't know exactly what CMake's stance is on deprecation although I think the official policy is not to remove old commands because it would break backwards compatibility. The word deprecated can imply that the feature is meant to be removed but doesn't necessarily mean so. The ambiguity there really sucks. Perhaps obsolete is a better choice of words. -- Philip Lowman ___ 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] link_libraries() deprecated. Why?
Alex,
Looking at history I see this was deprecated by a patch you sent me.
Originally we called the command 'discouraged'. Why did we change
to 'deprecated'?
Marcel Loose wrote:
Thanks for your reply. Your solution is ok, but it looks a bit like a
workaround for a feature that is missing, but was once there:
link_libraries().
To me, it's not really clear why link_libraries() has been deprecated
and, for example, include_directories() has not. IMHO, using
target_link_libraries() for a general library has a too fine
granularity.
Suppose include_directories() were deprecated as well in favour of, say,
target_include_directories(). That would create the same problem: carry
around variables holding a bunch of include directories that must be
supplied to each target.
I don't like to use deprecated features, so I would love to see the
deprecation of link_libraries() to be reverted. But maybe I'm missing a
good reason for not doing so.
Marcel, feel free to use link_libraries if there is no better solution.
We do not plan to take it away. The word 'deprecated' is too strong.
One difference between link_libraries and include_directories is that
library dependencies are chained automatically. If you write
add_library(mylib mylib.c)
target_link_libraries(mylib m)
add_executable(myexe myexe.c)
target_link_libraries(myexe mylib)
then 'myexe' will link to both 'mylib' and 'm' (-lmylib -lm).
If you write
link_libraries(m)
add_library(mylib mylib.c)
add_executable(myexe myexe.c)
target_link_libraries(myexe mylib)
then 'myexe' will link 'm', 'mylib', and then 'm' again (-lm -lmylib -lm).
The reason is that the add_executable line copies the current set of
directory-level libraries from link_libraries when it is created. Any
target_link_libraries after that are appended. A strict rule our link
line generator follows is that the original link line for a target is
preserved, so for 'myexe' it starts with 'm' and 'mylib'. Then it sees
that 'mylib' depends on 'm' and appends the library to the final link line.
If your project has a hierarchy of libraries already, just use
target_link_libraries to add the globally required library to the
top-most libraries in the hierarchy. Link dependency analysis will
take care of the rest.
-Brad
On Wed, 2009-04-01 at 23:50 -0400, Philip Lowman wrote:
On Wed, Apr 1, 2009 at 5:35 PM, Marcel Loose lo...@astron.nl wrote:
Hi all,
I was wondering why the link_libraries() command has been
deprecated. Commands like include_directories() and
link_directories() which have the same scope have not been
deprecated. I think that link_libraries() has its virtues too.
My reason for asking this, is that I wonder what's the proper
way to add a library to *all* targets in a project; for
example, a logging library or a threads library. Here,
link_libraries() provides IMHO a much cleaner solution, than
target_link_libraries(). The latter requires me to keep track
of the globally used library in a variable that must be passed
around; and for each target I must explicitly specify its
dependency on this library by using target_link_libraries().
Or, am I missing something, and is there a cleaner way to do
this, without using a deprecated feature?
Often I have seen people write functions to help with this especially
if you have more than one common library.
function(link_target_against_common_libs _target)
target_link_libraries(${_target} ${WHATEVER_LIBRARY})
endfunction()
Another approach is if you have a low level library as part of your
codebase that everyone depends upon you can simply make it dependent
on your threading or logging libraries and anyone that is dependent
against it will automatically link against the threading or logging
library.
--
Philip Lowman
___
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] link_libraries() deprecated. Why?
On Thursday 02 April 2009, Brad King wrote: Alex, Looking at history I see this was deprecated by a patch you sent me. Originally we called the command 'discouraged'. Why did we change to 'deprecated'? I don't remember why we changed the wording. The deprecated commands are commands which are in general not recommended anymore for use, but they are still available. I.e. as a replacement for LINK_LIBRARIES() there is now TARGET_LINK_LIBRARIES() (since a long time already), which has advantages, and is in general recommended to be used instead, see below. ... I don't like to use deprecated features, so I would love to see the deprecation of link_libraries() to be reverted. But maybe I'm missing a good reason for not doing so. Marcel, feel free to use link_libraries if there is no better solution. We do not plan to take it away. The word 'deprecated' is too strong. One difference between link_libraries and include_directories is that library dependencies are chained automatically. If you write Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] link_libraries() deprecated. Why?
Hi all, I was wondering why the link_libraries() command has been deprecated. Commands like include_directories() and link_directories() which have the same scope have not been deprecated. I think that link_libraries() has its virtues too. My reason for asking this, is that I wonder what's the proper way to add a library to *all* targets in a project; for example, a logging library or a threads library. Here, link_libraries() provides IMHO a much cleaner solution, than target_link_libraries(). The latter requires me to keep track of the globally used library in a variable that must be passed around; and for each target I must explicitly specify its dependency on this library by using target_link_libraries(). Or, am I missing something, and is there a cleaner way to do this, without using a deprecated feature? Best regards, Marcel Loose. ___ 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] link_libraries() deprecated. Why?
On Wed, Apr 1, 2009 at 5:35 PM, Marcel Loose lo...@astron.nl wrote:
Hi all,
I was wondering why the link_libraries() command has been deprecated.
Commands like include_directories() and link_directories() which have the
same scope have not been deprecated. I think that link_libraries() has its
virtues too.
My reason for asking this, is that I wonder what's the proper way to add a
library to *all* targets in a project; for example, a logging library or a
threads library. Here, link_libraries() provides IMHO a much cleaner
solution, than target_link_libraries(). The latter requires me to keep track
of the globally used library in a variable that must be passed around; and
for each target I must explicitly specify its dependency on this library by
using target_link_libraries().
Or, am I missing something, and is there a cleaner way to do this, without
using a deprecated feature?
Often I have seen people write functions to help with this especially if you
have more than one common library.
function(link_target_against_common_libs _target)
target_link_libraries(${_target} ${WHATEVER_LIBRARY})
endfunction()
Another approach is if you have a low level library as part of your codebase
that everyone depends upon you can simply make it dependent on your
threading or logging libraries and anyone that is dependent against it will
automatically link against the threading or logging library.
--
Philip Lowman
___
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] link_libraries vs target_link_libraries
Colin D Bennett schrieb: However, I would argue that target_link_libraries vs. link_libraries is more important than the possible target_include_directories vs. include_directories, since the linked libraries will directly affect the generated output (linking to unnecessary libraries is wasteful). In contrast, including unused include-file-directories in the search path for the compiler will not affect the output (assuming there are no duplicated header file names in different paths, which I would argue should not be allowed). Actually, it's possible that those duplicated names exist. The problem comes up if they have the same API but a different ABI, thus the linking will possibly fail. However, doesn't include_directories() only affect the current dir and the subdirs? It would be a very rare case to have two apps in the same dir that use two different types/versions of the same include files. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
So, I guess I will comment on this... :) Originally CMake was directory based. We are moving towards being target based. For directories, targets, and projects, there should be a way to set: - defines - includes - link libraries - compiler flags Currently you can set: compiler flags: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_FLAGS define symbols: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:DEFINE_SYMBOL libraries with target_link_libraries. config based compile defines: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_DEFINITIONS_CONFIG include_directories can only be set on a per directory basis. At some point a target will have all the links, includes, and flags required to use it stored somewhere, and that will come with the target. This can be done now with macros and functions, the new CMake build for boost does some of this. If someone wants to a bug entry could be created for target specific include files, that would be good. As for the title of the thread target_link_libraries should be used in most cases. However link_libraries could still be a useful short cut. Note, CMake does use the link libraries for a target transitively. If you do not want that, you can use: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LINK_INTERFACE_LIBRARIES -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Bill,
Fernando Cacciola wrote:
Ha I see... that is 2.6 specific right?
There are still too many 2.4 versions shiped with Linux et al, and we
don't want to ask our users to *manually* upgrade cmake when they
already have one installed, so I'm keeping all compatible with at
least 2.4.5
Well, not much we can do about that but wait... :)
\
Indeed :)
We are telling our users to do:
find_packge( CGAL REQUIRED components )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
target_link_libraries
( program ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )
But then I wondered: why am I bothering them with that last line while
everything else is hidden in UseCGAL? After all if they do not won't
to link with that, which would be really odd, they better don't use
UseCGAL at all and rather just use the outcome of FindCGAL manually.
So IMO UseCGAL should be all or nothing. Wouldn't you agree?
For an executable is it not as important since there is no transitive
linking. However, link_libraries is a bit of a blunt instrument as it
will link with all the executables and libraries after it is called into
sub directories. So, I still think linking just specific libraries is
better than not. Also, it will be one less thing you have to change
when 2.6 comes out. What if the project had program1 and program2, and
program2 used VTK and CGAL, but program1 only used CGAL? Then the
link_libraries approach would link too much. The extra includes should
not hurt because VTK and CGAL should not have conflicting headers. So,
there is a still a benefit to specifically linking libraries.
In our case this scenario is just not possible at all since UseCGAL
overrides flags, so everything following UseCGAL must actually use CGAL
in all its glory :)
We tell our users to arrange CMakeLists.txt appropiately taking the
global side effects of UseCGAL into account.
Best
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Bill Hoffman schrieb:
OTOH, it could make sense to do the following:
find_packge( CGAL REQUIRED components )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
use_CGAL( program )
so it works now with 2.4, and eventually upgrade it to use target
properties instead.
That sounds like a good way to go, and is similar to what the boost
folks are doing.
But it is not backwards-compatible and will fail to link on the new
version while it worked fine on the old version.
Additionally, that would make ${CGAL_USE_FILE} obsolete as you can put
the macro into FindCGAL.cmake.
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hendrik Sattler wrote:
Bill Hoffman schrieb:
OTOH, it could make sense to do the following:
find_packge( CGAL REQUIRED components )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
use_CGAL( program )
so it works now with 2.4, and eventually upgrade it to use target
properties instead.
That sounds like a good way to go, and is similar to what the boost
folks are doing.
But it is not backwards-compatible and will fail to link on the new
version while it worked fine on the old version.
Why??
Additionally, that would make ${CGAL_USE_FILE} obsolete as you can put
the macro into FindCGAL.cmake.
Which is far from being a problem, or is it?
Best
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Fernando Cacciola schrieb:
Hendrik Sattler wrote:
Bill Hoffman schrieb:
OTOH, it could make sense to do the following:
find_packge( CGAL REQUIRED components )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
use_CGAL( program )
so it works now with 2.4, and eventually upgrade it to use target
properties instead.
That sounds like a good way to go, and is similar to what the boost
folks are doing.
But it is not backwards-compatible and will fail to link on the new
version while it worked fine on the old version.
Why??
Because if the ${FOO_USE_FILE} doesn't do what it always does (globally
adding this stuff), you _have_ to insert the new macro call to make it
compile again. OTOH, this macro call will fail on the old version
because it doesn't exist.
(Assumed that FindFoo.cmake and ${FOO_USE_FILE} are shipped with cmake)
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Hendrik,
But it is not backwards-compatible and will fail to link on the new
version while it worked fine on the old version.
Why??
Because if the ${FOO_USE_FILE} doesn't do what it always does (globally
adding this stuff), you _have_ to insert the new macro call to make it
compile again. OTOH, this macro call will fail on the old version
because it doesn't exist.
(Assumed that FindFoo.cmake and ${FOO_USE_FILE} are shipped with cmake)
So you where referring to some existing UseFOO then?
UseCGAL doesn't really exist yet (we haven't released it), so at this
point I can do the right thing :)
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Colin, On Tue, 11 Nov 2008 16:13:43 -0200 Fernando Cacciola [EMAIL PROTECTED] wrote: Hi Andreas, On 11 Nov 2008 18:12:33 +0100, Andreas Pakulat wrote: In fact I don't understand why include_directories and add_definitions are not deprecated as well Which is precisely my point!! :) target_link_libraries, which is GREAT, is actually pretty useless without target_include_directories, target_add_definitions and TARGET_CMAKE_CXX_FLAGS. Yet OTOH given that those do not exists, it is just plain silly to recommend not using link_libraries, because it gets less than half the story right. I agree. There should be a target_include_directories. This has bothered me as well. However, I would argue that target_link_libraries vs. link_libraries is more important than the possible target_include_directories vs. include_directories, since the linked libraries will directly affect the generated output (linking to unnecessary libraries is wasteful). Agreed, though definitions and, most important of all by far, compiler and linker flags are much more critical. And UseVTK, for example, changes compiler flags FOR EVERYTHING THAT FOLLOWS, even totally unrelated PARENT directories (because of the ways of the cache). So if target_link_libraries makes sense (and it sure does), imagine TARGET_CMAKE_CXX_FLAGS (or even better target_add_compiler|linker_flags) In contrast, including unused include-file-directories in the search path for the compiler will not affect the output (assuming there are no duplicated header file names in different paths, which I would argue should not be allowed). Except of course that you can't disallow it in all cases since completely different libraries cannot possibly prevent clashing with each other, and that would happen if you have find_package(X) then find_package(Y). But granted, if you have those two lines in the same cmake scripts you are likely to need both X and Y in the same target, so this is an unlikely scenario. So, I think that target_link_libraries is more important than target_include_directories, but we still should have a target_include_directories for the sake of consistency, clarity (specifically show what include directories are used by what files), and robustness. And as I said far much more important: target_add_definitions and a way to target compilers and linker flags, which is something Use files also define globally now. Another aspect of this is that perhaps 'target_include_directories' is not the right concept, but rather, since include files are needed by source code (not compiled targets), the following: source_include_directories(source-files ... INCLUDES include-dirs ...) I wonder if this would be useful in practice? I'm not sure it makes sense to draw a disctinction between stuff needed by source files and compiled targets. While in a makefile these all go as command line parameters to the compiler source by source, in a project files these are global properties of a target within the project, so IMO the conceptual entity the encapsulates all these is the target, not the source files. Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Am Wednesday 12 November 2008 17:03:04 schrieb Fernando Cacciola:
Hi Hendrik,
But it is not backwards-compatible and will fail to link on the new
version while it worked fine on the old version.
Why??
Because if the ${FOO_USE_FILE} doesn't do what it always does (globally
adding this stuff), you _have_ to insert the new macro call to make it
compile again. OTOH, this macro call will fail on the old version
because it doesn't exist.
(Assumed that FindFoo.cmake and ${FOO_USE_FILE} are shipped with cmake)
So you where referring to some existing UseFOO then?
UseCGAL doesn't really exist yet (we haven't released it), so at this
point I can do the right thing :)
Sure but if this stuff is to be consistent with the other modules doing the
USE_FILE thing, then this is a problem.
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Fernando Cacciola wrote:
Ha I see... that is 2.6 specific right?
There are still too many 2.4 versions shiped with Linux et al, and we
don't want to ask our users to *manually* upgrade cmake when they
already have one installed, so I'm keeping all compatible with at least
2.4.5
Well, not much we can do about that but wait... :)
\
We are telling our users to do:
find_packge( CGAL REQUIRED components )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
target_link_libraries
( program ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )
But then I wondered: why am I bothering them with that last line while
everything else is hidden in UseCGAL? After all if they do not won't to
link with that, which would be really odd, they better don't use UseCGAL
at all and rather just use the outcome of FindCGAL manually.
So IMO UseCGAL should be all or nothing. Wouldn't you agree?
For an executable is it not as important since there is no transitive
linking. However, link_libraries is a bit of a blunt instrument as it
will link with all the executables and libraries after it is called into
sub directories. So, I still think linking just specific libraries is
better than not. Also, it will be one less thing you have to change
when 2.6 comes out. What if the project had program1 and program2, and
program2 used VTK and CGAL, but program1 only used CGAL? Then the
link_libraries approach would link too much. The extra includes should
not hurt because VTK and CGAL should not have conflicting headers. So,
there is a still a benefit to specifically linking libraries.
OTOH, it could make sense to do the following:
find_packge( CGAL REQUIRED components )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
use_CGAL( program )
so it works now with 2.4, and eventually upgrade it to use target
properties instead.
That sounds like a good way to go, and is similar to what the boost
folks are doing.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
On Wednesday 12 November 2008, Fernando Cacciola wrote: Hi Bill, ... Ha I see... that is 2.6 specific right? There are still too many 2.4 versions shiped with Linux et al, and we don't want to ask our users to *manually* upgrade cmake when they already have one installed, so I'm keeping all compatible with at least 2.4.5 KDE 4.2 (will be released early next year) will require cmake 2.6.2 (KDE svn trunk does since this monday), so distributions will adapt :-) Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Bill,
So, I guess I will comment on this... :)
:)
Originally CMake was directory based. We are moving towards being
target based. For directories, targets, and projects, there should be
a way to set:
- defines
- includes
- link libraries
- compiler flags
Hard to argue with that :)
Currently you can set:
compiler flags:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_FLAGS
define symbols:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:DEFINE_SYMBOL
libraries with target_link_libraries.
config based compile defines:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_DEFINITIONS_CONFIG
Ha I see... that is 2.6 specific right?
There are still too many 2.4 versions shiped with Linux et al, and we
don't want to ask our users to *manually* upgrade cmake when they
already have one installed, so I'm keeping all compatible with at least
2.4.5
include_directories can only be set on a per directory basis. At some
point a target will have all the links, includes, and flags required to
use it stored somewhere, and that will come with the target. This can
be done now with macros and functions, the new CMake build for boost
does some of this. If someone wants to a bug entry could be created
for target specific include files, that would be good.
As for the title of the thread target_link_libraries should be used in
most cases. However link_libraries could still be a useful short cut.
The *practical* problem I have with target_link_libraries and which
originated this thread is the following:
We are telling our users to do:
find_packge( CGAL REQUIRED components )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
target_link_libraries
( program ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )
But then I wondered: why am I bothering them with that last line while
everything else is hidden in UseCGAL? After all if they do not won't to
link with that, which would be really odd, they better don't use UseCGAL
at all and rather just use the outcome of FindCGAL manually.
So IMO UseCGAL should be all or nothing. Wouldn't you agree?
OTOH, it could make sense to do the following:
find_packge( CGAL REQUIRED components )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
use_CGAL( program )
In this case, the use_CGAL macro would set includes, definitions,
libraries etc, but for the specified target as much as possible
(depending on the current cmake support).
IIUC I can easily write the use_CGAL macro as:
include_directories
( ${CGAL_3RD_PARTY_INCLUDE_DIRS} ${CGAL_INCLUDE_DIRS} )
add_definitions
( ${CGAL_3RD_PARTY_DEFINITIONS}${CGAL_DEFINITIONS} )
link_directories
( ${CGAL_3RD_PARTY_LIBRARIES_DIRS} ${CGAL_LIBRARIES_DIR} )
target_link_libraries
( ${TARGET} ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )
so it works now with 2.4, and eventually upgrade it to use target
properties instead.
What do yo think?
Note, CMake does use the link libraries for a target transitively. If
you do not want that, you can use:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LINK_INTERFACE_LIBRARIES
Ha, interesting.. didn't know that.
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Andreas,
On 11.11.08 14:12:39, Fernando Cacciola wrote:
Hi Andreas,
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such files, call include_directories,
add_definitions and overrides (under certain circumstances) the
compiler/linker flags that were used to build the CGAL library.
These are all settings that affect any target added after the
inclusion of UseCGAL.cmake.
However, following the recommended practice (according to the
documentation of the deprecated link_libraries command), UseCGAL DOES
NOT call link_libraries. Instead, it realies on the user calling
target_link_libraries himself.
Well, I'm questioning this recommended practice because it's half
baked: It makes sense to allow users to control which targets are
linked against CGAL, but NOT if OTOH they cannot control which
targets are given the CGAL include directories, definitions and
flags.
That is, IMO, target_link_libraries makes little sense in the absence
of target_include_directories, target_add_definitions and
target_*_FLAGS.
What it's so special about linking that only that command can be made
target specific???
Or am I missing something?
There are projects that have headers that are usable without linking
against any library. There are also projects installing their headers into
a common place, that have multiple libraries. In that latter case you'd
have include_directories() point to the common place for the headers, but
obviously you can't know which of the libraries needs to be linked in.
Who is you in your sentence?
The UseXYZ modules which depends on the parameters to find_package(XYZ)
certainly knows it.
No it doesn't. UseXXX is a global thing, so it can't know which of the
targets in a project need which files.
Right, but the again a typical UseXYZ would do:
include_directories( ${XYZ_INCLUDE_DIR} )
add_definitions( ${XYZ_DEFINITIOS} )
set( CMAKE_CXX_FLAGS $XYZ_CXX_FLAGS) )
So it doesn't know which of your targets need the include dirs, the
definitions and the flags.. and it doesn't care.
Boost is a good example (albeit it doesn't use cmake to build itself).
There are various libraries shipped with it, they all install their headers
into includedir/boost/libraryname/ and the libs are of course directly
in libdir. And its common practice to have only includedir/boost in the
include-directories.
And BOOST_LIBRARIES is defined as a list of all libraries indicated by
the user as boost components.
Right, but those are all I'm going to use in my project, which might or
might not be different from those that I want on target A and B.
Right.
So, if there where a UseBoost.cmake file
which would do
include_directories( ${BOOST_INCLUDE_DIR} )
add_definitions( ${BOOST_DEFINITIONS} )
then wouldn't it make sense for it to do
link_libraries( ${BOOST_LIBRARIES} )
as well?
That would mean _all_ my targets link against those libraries, which is
completely wrong.
Right.
In fact I don't understand why include_directories and
add_definitions are not deprecated as well
Which is precisely my point!! :)
target_link_libraries, which is GREAT, is actually pretty useless
without target_include_directories, target_add_definitions and
TARGET_CMAKE_CXX_FLAGS.
Yet OTOH given that those do not exists, it is just plain silly to
recommend not using link_libraries, because it gets less than half the
story right.
And IMO is equally silly to follow the recomendation and end up doing
what most Use files typically do: to set so much that affects all
subsequent targets, even compiler and linker flags, BUT simply define a
variable XYZ_LIBRARY so a user can decide which target to link againt
XYZ_LIBRARY.
I mean, being able to control this is cool, sure, but why can I only
control that and not the other equally critical settings???
IMO, if a user won't have real control over which targets actually use
XYZ (in all the extent to which using XYZ, as defined by
find_package(XYZ), means) then I rather don't bother them requiring
users to call target_link_libraries by hand (while everything else is
setup by the Use file itself). It's just silly.
So to restat my point, if a UseFile does this:
include_directories( ${XYZ_INCLUDE_DIR} )
add_definitions( ${XYZ_DEFINITIOS} )
set( CMAKE_CXX_FLAGS $XYZ_CXX_FLAGS) )
which shouldn't under the argument of what if I don't want that for all
my targets, then it should do this as well:
link_libraries( ${XYZ_LIBRARIES} )
Best
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Am Tuesday 11 November 2008 19:13:43 schrieb Fernando Cacciola: target_link_libraries, which is GREAT, is actually pretty useless without target_include_directories, target_add_definitions and TARGET_CMAKE_CXX_FLAGS. Did you notice set_property(TARGET .)? There, you can do add target specific definitions (even per build type) and other stuff. Sadly, this is no replacement for target_include_directories() as you have to know the compiler syntax. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
On 11.11.08 14:12:39, Fernando Cacciola wrote:
Hi Andreas,
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such files, call include_directories,
add_definitions and overrides (under certain circumstances) the
compiler/linker flags that were used to build the CGAL library.
These are all settings that affect any target added after the
inclusion of UseCGAL.cmake.
However, following the recommended practice (according to the
documentation of the deprecated link_libraries command), UseCGAL DOES
NOT call link_libraries. Instead, it realies on the user calling
target_link_libraries himself.
Well, I'm questioning this recommended practice because it's half
baked: It makes sense to allow users to control which targets are
linked against CGAL, but NOT if OTOH they cannot control which
targets are given the CGAL include directories, definitions and
flags.
That is, IMO, target_link_libraries makes little sense in the absence
of target_include_directories, target_add_definitions and
target_*_FLAGS.
What it's so special about linking that only that command can be made
target specific???
Or am I missing something?
There are projects that have headers that are usable without linking
against any library. There are also projects installing their headers into
a common place, that have multiple libraries. In that latter case you'd
have include_directories() point to the common place for the headers, but
obviously you can't know which of the libraries needs to be linked in.
Who is you in your sentence?
The UseXYZ modules which depends on the parameters to find_package(XYZ)
certainly knows it.
No it doesn't. UseXXX is a global thing, so it can't know which of the
targets in a project need which files.
Boost is a good example (albeit it doesn't use cmake to build itself).
There are various libraries shipped with it, they all install their headers
into includedir/boost/libraryname/ and the libs are of course directly
in libdir. And its common practice to have only includedir/boost in the
include-directories.
And BOOST_LIBRARIES is defined as a list of all libraries indicated by
the user as boost components.
Right, but those are all I'm going to use in my project, which might or
might not be different from those that I want on target A and B.
So, if there where a UseBoost.cmake file
which would do
include_directories( ${BOOST_INCLUDE_DIR} )
add_definitions( ${BOOST_DEFINITIONS} )
then wouldn't it make sense for it to do
link_libraries( ${BOOST_LIBRARIES} )
as well?
That would mean _all_ my targets link against those libraries, which is
completely wrong. In fact I don't understand why include_directories and
add_definitions are not deprecated as well, those might not be wanted or
can possibly even cause problems when building targets that don't depend on
them.
My point is that if a UseXYZ file defines taget-wide settings such as
Its not target-wide, its project-wide - or at least directory wide. So even
if you have all boost-linking targets of your project in one directory, you
might not want all of them to link against all the boost libs you use.
Maybe there are one or two libs that only need a subset of the boost-libs.
Andreas
--
You have a reputation for being thoroughly reliable and trustworthy.
A pity that it's totally undeserved.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Andreas,
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such files, call include_directories,
add_definitions and overrides (under certain circumstances) the
compiler/linker flags that were used to build the CGAL library.
These are all settings that affect any target added after the inclusion
of UseCGAL.cmake.
However, following the recommended practice (according to the
documentation of the deprecated link_libraries command), UseCGAL DOES
NOT call link_libraries. Instead, it realies on the user calling
target_link_libraries himself.
Well, I'm questioning this recommended practice because it's half baked:
It makes sense to allow users to control which targets are linked
against CGAL, but NOT if OTOH they cannot control which targets are
given the CGAL include directories, definitions and flags.
That is, IMO, target_link_libraries makes little sense in the absence of
target_include_directories, target_add_definitions and target_*_FLAGS.
What it's so special about linking that only that command can be made
target specific???
Or am I missing something?
There are projects that have headers that are usable without linking
against any library. There are also projects installing their headers into
a common place, that have multiple libraries. In that latter case you'd
have include_directories() point to the common place for the headers, but
obviously you can't know which of the libraries needs to be linked in.
Who is you in your sentence?
The UseXYZ modules which depends on the parameters to find_package(XYZ)
certainly knows it.
Boost is a good example (albeit it doesn't use cmake to build itself).
There are various libraries shipped with it, they all install their headers
into includedir/boost/libraryname/ and the libs are of course directly
in libdir. And its common practice to have only includedir/boost in the
include-directories.
And BOOST_LIBRARIES is defined as a list of all libraries indicated by
the user as boost components. So, if there where a UseBoost.cmake file
which would do
include_directories( ${BOOST_INCLUDE_DIR} )
add_definitions( ${BOOST_DEFINITIONS} )
then wouldn't it make sense for it to do
link_libraries( ${BOOST_LIBRARIES} )
as well?
My point is that if a UseXYZ file defines taget-wide settings such as
includes, definitions etc.. then it should just as well define the link
libraries... hence, link_libraries should not be deprecated and stock
files like UseQt4 and UseVTK should us it (they don't FYI).
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] link_libraries vs target_link_libraries
Hi people,
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such files, call include_directories,
add_definitions and overrides (under certain circumstances) the
compiler/linker flags that were used to build the CGAL library.
These are all settings that affect any target added after the inclusion
of UseCGAL.cmake.
However, following the recommended practice (according to the
documentation of the deprecated link_libraries command), UseCGAL DOES
NOT call link_libraries. Instead, it realies on the user calling
target_link_libraries himself.
Well, I'm questioning this recommended practice because it's half baked:
It makes sense to allow users to control which targets are linked
against CGAL, but NOT if OTOH they cannot control which targets are
given the CGAL include directories, definitions and flags.
That is, IMO, target_link_libraries makes little sense in the absence of
target_include_directories, target_add_definitions and target_*_FLAGS.
What it's so special about linking that only that command can be made
target specific???
Or am I missing something?
TIA
Fernando Cacciola
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such files, call include_directories,
add_definitions and overrides (under certain circumstances) the
compiler/linker flags that were used to build the CGAL library.
These are all settings that affect any target added after the inclusion
of UseCGAL.cmake.
However, following the recommended practice (according to the
documentation of the deprecated link_libraries command), UseCGAL DOES
NOT call link_libraries. Instead, it realies on the user calling
target_link_libraries himself.
Well, I'm questioning this recommended practice because it's half baked:
It makes sense to allow users to control which targets are linked
against CGAL, but NOT if OTOH they cannot control which targets are
given the CGAL include directories, definitions and flags.
That is, IMO, target_link_libraries makes little sense in the absence of
target_include_directories, target_add_definitions and target_*_FLAGS.
What it's so special about linking that only that command can be made
target specific???
Or am I missing something?
There are projects that have headers that are usable without linking
against any library. There are also projects installing their headers into
a common place, that have multiple libraries. In that latter case you'd
have include_directories() point to the common place for the headers, but
obviously you can't know which of the libraries needs to be linked in.
Boost is a good example (albeit it doesn't use cmake to build itself).
There are various libraries shipped with it, they all install their headers
into includedir/boost/libraryname/ and the libs are of course directly
in libdir. And its common practice to have only includedir/boost in the
include-directories.
For the case of a single library with a few headers, for which a UseXXX
file is provided the requirement really doesn't make much sense (IMHO) -
unless you can use some of the headers without linking.
Andreas
--
Don't read any sky-writing for the next two weeks.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi, my 2c...
2008/11/10 Andreas Pakulat [EMAIL PROTECTED]
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
There are projects that have headers that are usable without linking
against any library. There are also projects installing their headers into
a common place, that have multiple libraries. In that latter case you'd
have include_directories() point to the common place for the headers, but
obviously you can't know which of the libraries needs to be linked in.
Boost is a good example (albeit it doesn't use cmake to build itself).
they have just added cmake support, i think it was just added to the trunk
There are various libraries shipped with it, they all install their headers
into includedir/boost/libraryname/ and the libs are of course directly
in libdir. And its common practice to have only includedir/boost in the
include-directories.
i would disagree, its common practice to have only includedir in the
include-directories, and then you
#include boost/shared_ptr.hpp
For the case of a single library with a few headers, for which a UseXXX
file is provided the requirement really doesn't make much sense (IMHO) -
unless you can use some of the headers without linking.
(snipped from above)
On 10.11.08 12:01:13, Fernando Cacciola wrote:
Well, I'm questioning this recommended practice because it's half baked:
It makes sense to allow users to control which targets are linked
against CGAL, but NOT if OTOH they cannot control which targets are
given the CGAL include directories, definitions and flags.
That is, IMO, target_link_libraries makes little sense in the absence of
target_include_directories, target_add_definitions and target_*_FLAGS.
What it's so special about linking that only that command can be made
target specific???
I can specify which headers I want to include by writing #includes in my
.cpp file.
But the ONLY place I can specify which libraries I want to include is within
CMake config files. Thus, you only need target_link_libraries and not
target_add_directories.
As for target_add_definitions, you don't add definitions to a target, you
add them to cpp files you are compiling. I think you can define them for
certain files if you have the add_definition in a subdirectory
CMakeLists.txt, but I'm not sure how else you can limit its 'scope'.
Paul
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] link_libraries
Hi, I have a dir with a lot of small example apps that all link with the same libs. The link_libraries is much more convenient in this case than writing a target_link_libraries line for each example target. Why is the link_libraries deprecated? Will it be removed in the future? Thanx. Ionutz ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries
Ioan Calin Borcoman schrieb:
Hi,
I have a dir with a lot of small example apps that all link with the
same libs. The link_libraries is much more convenient in this case
than writing a target_link_libraries line for each example target.
Why is the link_libraries deprecated? Will it be removed in the future?
In this case, you usually use a foreach anyway, don't you?
set (exampleapps
ex1
ex2
ex3
)
foreach ( ex ${exampleapps} )
add_executable( ${ex} ${ex}.c )
target_link_libraries( ${ex} mylib)
endforeach ( ex )
Easy enough?
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] LINK_LIBRARIES() does not respect SUFFIX/PREFIX
Great! A while ago I tried to cross-compile code for win32 with mingw from linux and ran into the same problem with the library PREFIX and SUFFIX. Setting the PREFIX and SUFFIX globally works great, cross-compiling now works good for my project (and much faster than the native compile with mingw on windows.) SET(CMAKE_STATIC_LIBRARY_PREFIX ) SET(CMAKE_STATIC_LIBRARY_SUFFIX .dll) SET(CMAKE_EXECUTABLE_SUFFIX .exe) Thanks, Peter. This problem is now solved. For anyone else facing this with crosscompiling here are is what I did. In the top level CMakeLists.txt I put in the following: PROJECT(myProj) SET(CMAKE_STATIC_LIBRARY_PREFIX lib) SET(CMAKE_STATIC_LIBRARY_SUFFIX .a) SET(CMAKE_EXECUTABLE_SUFFIX .elf) Some of my leqrnings; 1) The prefix and suffix information must and should be placed after declaring the project. If it is put before, then it gets overwritten when project is declared. Can any of the developers throw more light on the various effects that declaring a project has? 2) When cross-compiling, the CMAKE_C_COMPILER and CMAKE_CXX_COMPILER must be set *before* declaring the project. It gets *committed* when a project is declared and cannot be changed without deleting the build. Warm regards, Kishore ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] LINK_LIBRARIES() does not respect SUFFIX/PREFIX
My setup: Project/CMakeLists.txt: ADD_SUBDIRECTORY(dir) LINK_LIBRARIES(mylib) ADD_EXECUTABLE(myexec main.c) Project/dir/CMakeLists.txt: ADD_LIBRARY(mylib lib.c) SET_TARGET_PROPERTIES(mylib PROPERTIES PREFIX lib SUFFIX .a) Now while building myexec I get a link error cannot find -llibmylib.a.lib. When I do not explicitly set the prefix and suffix, I still get the error cannot find -lmylib.lib. It links fine if I go and rename the library file in the build directory. How do I solve this problem? Why is the .lib being appended in the call to the linker? Forgot to mention. I did try using TARGET_LINK_LIBRARIES() instead of LINK_LIBRARIES() to the same effect. This problem is now solved. For anyone else facing this with crosscompiling here are is what I did. In the top level CMakeLists.txt I put in the following: PROJECT(myProj) SET(CMAKE_STATIC_LIBRARY_PREFIX lib) SET(CMAKE_STATIC_LIBRARY_SUFFIX .a) SET(CMAKE_EXECUTABLE_SUFFIX .elf) Some of my leqrnings; 1) The prefix and suffix information must and should be placed after declaring the project. If it is put before, then it gets overwritten when project is declared. Can any of the developers throw more light on the various effects that declaring a project has? 2) When cross-compiling, the CMAKE_C_COMPILER and CMAKE_CXX_COMPILER must be set *before* declaring the project. It gets *committed* when a project is declared and cannot be changed without deleting the build. Warm regards, Kishore ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] LINK_LIBRARIES() does not respect SUFFIX/PREFIX
My setup: Project/CMakeLists.txt: ADD_SUBDIRECTORY(dir) LINK_LIBRARIES(mylib) ADD_EXECUTABLE(myexec main.c) Project/dir/CMakeLists.txt: ADD_LIBRARY(mylib lib.c) SET_TARGET_PROPERTIES(mylib PROPERTIES PREFIX lib SUFFIX .a) Now while building myexec I get a link error cannot find -llibmylib.a.lib. When I do not explicitly set the prefix and suffix, I still get the error cannot find -lmylib.lib. It links fine if I go and rename the library file in the build directory. How do I solve this problem? Why is the .lib being appended in the call to the linker? Warm regards, Kishore ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] LINK_LIBRARIES() does not respect SUFFIX/PREFIX
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kishore, Jonnalagadda (IE10) Sent: Wednesday, March 21, 2007 1:28 AM To: cmake@cmake.org Subject: [CMake] LINK_LIBRARIES() does not respect SUFFIX/PREFIX My setup: Project/CMakeLists.txt: ADD_SUBDIRECTORY(dir) LINK_LIBRARIES(mylib) ADD_EXECUTABLE(myexec main.c) Project/dir/CMakeLists.txt: ADD_LIBRARY(mylib lib.c) SET_TARGET_PROPERTIES(mylib PROPERTIES PREFIX lib SUFFIX .a) Now while building myexec I get a link error cannot find -llibmylib.a.lib. When I do not explicitly set the prefix and suffix, I still get the error cannot find -lmylib.lib. It links fine if I go and rename the library file in the build directory. How do I solve this problem? Why is the .lib being appended in the call to the linker? Forgot to mention. I did try using TARGET_LINK_LIBRARIES() instead of LINK_LIBRARIES() to the same effect. Warm regards, Kishore ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
