Re: [CMake] Setting CPACK_PACKAGE_FILE_NAME per COMPONENT

2015-01-29 Thread Iosif Neitzke
Where for a single run of CPack, each component name produces a corresponding named .deb file or ...? Have you tried using CPACK_PROJECT_CONFIG_FILE [0]? This allows you to set a few options at packaging time which can change the final output package file name. [0] http://www.cmake.org/cmake/hel

Re: [CMake] automoc autorcc

2015-01-29 Thread Norbert Pfeiler
> > > When i use qt5_add_resources and some of my resources change they get > > recompiled during the next invocation of my build tool. Whereas when i > use > > cmakes autorcc this is not the case. > This was fixed in CMake 3.1. Well, I’m using CMake 3.1.1, so apparently it’s not. > Secondly, wi

[CMake] Adding module CheckFortranCompilerFlag.cmake

2015-01-29 Thread Nicolas Bock
Hi, please find attached for potential inclusion into CMake a new Module that tests Fortran compiler flags. It is a modified copy of the existing CheckCCompilerFlag.cmake module. Thanks, nick # - Check whether the Fortran compiler supports a given flag. # CHECK_Fortran_COMPILER_FLAG( ) # - the

Re: [CMake] Generated files?

2015-01-29 Thread Chris Johnson
Thanks; I appreciate the suggestions. One thing that jumped out is the thought that foreach() is executed at "configuration" time, not "run" time. To me, that was counter-intuitive, but makes more sense once more thoroughly considered. But I have to admit, I've never seen anything in the documen

Re: [CMake] automoc autorcc

2015-01-29 Thread Stephen Kelly
Norbert Pfeiler wrote: > Hello, > i’m curious about 2 things and therefore wanted to ask: > > When i use qt5_add_resources and some of my resources change they get > recompiled during the next invocation of my build tool. Whereas when i use > cmakes autorcc this is not the case. This was fixed i

Re: [CMake] target_link_libraries replacing fully-qualified library with -l

2015-01-29 Thread Stephen Kelly
Chris Green wrote: > this library is found with > find_library as part of a config.cmake file invoked as part of > find_package() Consider reading http://www.cmake.org/cmake/help/v3.1/manual/cmake-packages.7.html at some point. find_library and config files don't go together. Thanks, Stev

Re: [CMake] CMake Eclipse & Resource Filters

2015-01-29 Thread Robert Dailey
Submitted here: http://public.kitware.com/Bug/view.php?id=15382 Thanks. On Wed, Jan 28, 2015 at 3:55 PM, Alexander Neundorf wrote: > On Wednesday, January 28, 2015 12:56:24 Robert Dailey wrote: >> Hello, >> >> I generate my project using Eclipse CDT4 - Ninja. I have a >> subdirectory called "Thi

Re: [CMake] target_link_libraries replacing fully-qualified library with -l

2015-01-29 Thread Chris Green
Hi, On 1/29/15 11:11 AM, Alexander Neundorf wrote: just to make sure: you did check that the library directory is not part of LIBRARY_PATH ? Alex I have verified that the presence or absence of LIBRARY_PATH (or LD_LIBRARY_PATH) is irrelevant in the presence of a linker script. Best, Chris.

Re: [CMake] target_link_libraries replacing fully-qualified library with -l

2015-01-29 Thread Alexander Neundorf
On Thursday, January 29, 2015 08:39:33 Chris Green wrote: > On 1/29/15 7:41 AM, Brad King wrote: > > On 01/28/2015 03:12 PM, Chris Green wrote: > >> target_link_libraries( /X/Y/libtbb.so) > >> > >> results in link.txt files containing -ltbb. > > > > This happens when the library is in an implicit

Re: [CMake] target_link_libraries replacing fully-qualified library with -l

2015-01-29 Thread Chris Green
Hi, On 1/29/15 9:36 AM, Brad King wrote: If you link tothis library using a full path manually, what is recorded in the NEEDED field of the resulting binary? Without SONAME many linkers record the full path. Does INPUT avoid that? With the caveat that a -L is necessary for the linker to find t

Re: [CMake] target_link_libraries replacing fully-qualified library with -l

2015-01-29 Thread Brad King
On 01/29/2015 10:53 AM, Nils Gladitz wrote: > Perhaps failing to read a SONAME should imply that a SONAME is available > (in context of cmComputeLinkInformation). > > Might be easier/more reliable than guessing if the given file is > actually a linker script? We don't actually know anything abo

Re: [CMake] Generated files?

2015-01-29 Thread Petr Kmoch
Hi Chris. I believe a function should do the trick: function(ProcessFile inFile) get_filename_component(outFile ${inFile} NAME_WE) set(outFile ${outFile}.out) add_custom_command( OUTPUT ${outFile} COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/${inFile} ${CMAKE_CURRENT

Re: [CMake] Generated files?

2015-01-29 Thread Thompson, KT
Hi Chris, Why not use a foreach loop? Something like this… add_executable(myprog myprog.cpp) set( files file001 fiile002 …) foreach( file in files) add_custom_command(OUTPUT ${file}.out COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/${file}.in . COMMAND myprog ${file}.in ${file}.

Re: [CMake] target_link_libraries replacing fully-qualified library with -l

2015-01-29 Thread Nils Gladitz
On 01/29/2015 04:36 PM, Brad King wrote: If you link tothis library using a full path manually, what is recorded in the NEEDED field of the resulting binary? Without SONAME many linkers record the full path. Does INPUT avoid that? Thanks, -Brad The actual library referenced by INPUT() [1]

Re: [CMake] target_link_libraries replacing fully-qualified library with -l

2015-01-29 Thread Brad King
On 01/29/2015 10:32 AM, Chris Green wrote: > I can confirm that replacing the text libtbb.so file containing the > INPUT instruction with a link to the library with the SONAME is > sufficient to solve the problem, at least as a short term workaround. > There is no importing of targets: this libr

Re: [CMake] target_link_libraries replacing fully-qualified library with -l

2015-01-29 Thread Chris Green
Hi, On 1/29/15 9:06 AM, Brad King wrote: then I'm guessing there's no SONAME: It can only be this if something tells CMake that it has no SONAME. That can only happen when it is an imported target with an appropriate property set. CMake doesn't try to read the binary IIRC. I can confirm that re

Re: [CMake] target_link_libraries replacing fully-qualified library with -l

2015-01-29 Thread Nils Gladitz
On 01/29/2015 04:06 PM, Brad King wrote: CMake doesn't try to read the binary IIRC. I think cmComputeLinkInformation uses "cmSystemTools::GuessLibrarySOName" which uses the elf parser to check for a SONAME. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMa

[CMake] Generated files?

2015-01-29 Thread Chris Johnson
​I am looking for suggestions on how to solve the following problem. I need a solution which is easy to understand and safe from future maintenance errors. There is a project directory with one C++ program and a large number of "input" data files. The C++ program needs to be compiled, and then r

Re: [CMake] target_link_libraries replacing fully-qualified library with -l

2015-01-29 Thread Brad King
On 01/29/2015 09:39 AM, Chris Green wrote: > Assuming that the list of implicit link directories is internal to CMake > and nobody has added to it by mistake CMake detects it from the compiler. Run grep IMPLICIT_LINK_DIRECTORIES CMakeFiles/*/CMake*Compiler.cmake in the top of the build tree t

Re: [CMake] target_link_libraries replacing fully-qualified library with -l

2015-01-29 Thread Chris Green
On 1/29/15 7:41 AM, Brad King wrote: On 01/28/2015 03:12 PM, Chris Green wrote: target_link_libraries( /X/Y/libtbb.so) results in link.txt files containing -ltbb. This happens when the library is in an implicit link directory, or possibly when the library does not have an SONAME field set. T

Re: [CMake] target_link_libraries replacing fully-qualified library with -l

2015-01-29 Thread Brad King
On 01/28/2015 03:12 PM, Chris Green wrote: > target_link_libraries( /X/Y/libtbb.so) > > results in link.txt files containing -ltbb. This happens when the library is in an implicit link directory, or possibly when the library does not have an SONAME field set. For the former case, use an imported