Re: [CMake] Using generator expression with add_library

[Andrew Fuller]

Another option is to use BUILD_SHARED_LIBS to control static vs. shared.  Set 
it to false on MSVC and true everywhere else, then omit the library type in the 
add_library calls that you wish to have controllable behaviour.  Those 
add_library calls will then consult BUILD_SHARED_LIBS to determine whether to 
generate a static or shared lib.

From: CMake  on behalf of David Aldrich 

Sent: November 7, 2019 3:52 AM
To: Petr Kmoch 
Cc: CMake MailingList 
Subject: Re: [CMake] Using generator expression with add_library

Thank you. So I guess I can make it as simple as:

if(MSVC)
add_library(${_star_lib_name} STATIC "")
else()
add_library(${_star_lib_name} SHARED "")
endif()

I just wondered if there was a more elegant way.

On Thu, Nov 7, 2019 at 11:45 AM Petr Kmoch 
mailto:petr.km...@gmail.com>> wrote:
Hi.

The argument STATIC or SHARED is processed at CMake configure time (that is, 
when CMake is executing the add_library() command). However, generator 
expressions are only evaluated at generate time, which comes only after all 
CMake code is processed.

Fortunately for you, compiler ID is something that is already known at 
configure time, meaning you don't need to use a genex to read it. You can just 
do this:

if(MSVC)
  set(LibType STATIC)
else()
  set(LibType SHARED)
endif()
add_library(
  ${_star_lib_name}
  ${LibType}
  ...
)

(Feel free to modify the if(), use CMAKE__COMPILER_ID 
(https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_ID.html) etc. 
as necessary).

Petr

On Thu, 7 Nov 2019 at 12:28, David Aldrich 
mailto:david.aldrich.n...@gmail.com>> wrote:

I want to build a shared library for Linux and a static library for Windows. So 
I have tried:

 set (_star_lib_name "StdStars")

 add_library(${_star_lib_name}
 $<$:SHARED>
 $<$:STATIC>
 ""
 )


but that gives me error:

CMake Error at 
C:/SVNProj/zodiac/branches/TRY_TML_CMake_3Oct2019/StarLibs/StdStars/CMakeLists.txt:7
 (add_library):
Cannot find source file:

STATIC

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx


What is the correct way of doing this please?

--

Powered by www.kitware.com

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] cross-testing support in cmake

[Andrew Fuller]

Does 
https://cmake.org/cmake/help/latest/prop_tgt/CROSSCOMPILING_EMULATOR.html#prop_tgt:CROSSCOMPILING_EMULATOR
 do what you're looking for?

From: CMake  on behalf of Stefan Seefeld 

Sent: November 5, 2019 6:06 PM
To: CMake 
Subject: [CMake] cross-testing support in cmake


Hello,

I'm looking for ways to enable cross-testing with cmake. I imagine some helper 
script that, during test execution, copies the test binary to a test platform, 
runs the binary there, and reports back the test result. Does cmake have 
support for such a scenario ?

Thanks,


[Stefan]
--

  ...ich hab' noch einen Koffer in Berlin...

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake Release Candidate Builds Available for Ubuntu

[Andrew Fuller]

Thanks for the RCs, Kyle (and the rest of the CMake crew).

I tried 3.15~rc1 and it seems to have been built without https support 
file(DOWNLOAD https://foo/bar) gives a status "1;Unsupported protocol".  This 
is with version  3.15.0~rc1-0kitware2 amd64 running on Bionic.
Version 3.14.5-0kitware1ubuntu18.04.1 runs just fine out of the box.

Cheers,
-Andrew

From: CMake  on behalf of Kyle Edwards via CMake 

Sent: June 7, 2019 3:05 PM
To: CMake
Subject: [CMake] CMake Release Candidate Builds Available for Ubuntu

All,

I am pleased to announce that we are now offering Ubuntu builds of the
CMake release candidates, in addition to the production releases. The
first available release candidate build is 3.15.0~rc1-0kitware2.

If you would like to receive release candidate builds, follow the
instructions at https://apt.kitware.com/ to add the release candidate
repository to your installation. (Please note that the release
candidates are optional and opt-in - if you don't explicitly add the
release candidate repository, you will only receive production builds.)

In addition, starting with this release candidate, we are now offering
32-bit builds on Ubuntu. The steps for 32-bit Ubuntu are exactly the
same as 64-bit - just add the repository to your installation and
install it.

Happy coding!

Kyle
--

Powered by www.kitware.com

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Trouble with conditional generator expression inside target_link_libraries

[Andrew Fuller]

What about this:


list(APPEND FOO_LIBRARIES_OPT foo)
list(APPEND FOO_LIBRARIES_DBG foo_d)

target_link_libraries(my_exe
   PUBLIC
debug "$<$:${FOO_LIBRARIES_DBG}>"
optimized "$<$:${FOO_LIBRARIES_OPT}>"
"$<$:bar>"
)

A little more verbose.


From: Björn Blissing 
Sent: October 4, 2018 9:00:28 AM
To: Andrew Fuller; Eric Noulard
Cc: CMake Mailinglist
Subject: RE: [CMake] Trouble with conditional generator expression inside 
target_link_libraries


Hi Andrew,



When I put the genex inside double quotes I get:


optimized.lib;foo.lib;debug.lib;foo_d.lib;bar.lib; --- for both debug and 
release builds

Regards,

Björn





From: Andrew Fuller 
Sent: Thursday, October 4, 2018 5:54 PM
To: Björn Blissing ; Eric Noulard 

Cc: CMake Mailinglist 
Subject: Re: [CMake] Trouble with conditional generator expression inside 
target_link_libraries



What happens if you put the genex inside double quotes?



target_link_libraries(my_exe

PUBLIC

 "$<$:${FOO_LIBRARIES}>"

 "$<$:bar>"

)





From: CMake mailto:cmake-boun...@cmake.org>> on behalf 
of Björn Blissing mailto:bjorn.bliss...@vti.se>>
Sent: October 4, 2018 8:49:19 AM
To: Eric Noulard
Cc: CMake Mailinglist
Subject: Re: [CMake] Trouble with conditional generator expression inside 
target_link_libraries



Hi Eric,



I tried to do a self contained minimal example:



cmake_minimum_required(VERSION 3.12)

project(expension_error LANGUAGES CXX)



add_executable(my_exe main.cpp)



option(USE_FOOLIB "Use foo.lib" ON)

option(USE_BARLIB "Use bar.lib" ON)



list(APPEND FOO_LIBRARIES optimized foo)

list(APPEND FOO_LIBRARIES debug foo_d)





target_link_libraries(my_exe

PUBLIC

 $<$:${FOO_LIBRARIES}>

 $<$:bar>

)



But when I run this script using CMake 3.12.2, it expands to something even 
worse:



$<1:optimized;foo.lib;foo_d>.lib;bar.lib --- for debug builds

$<1:optimized;foo.lib;>.lib;bar.lib-- for release builds



So something goes really wrong when I try to use a list inside a conditional 
generator expression inside target_link_libraries().



Regards,

Björn







From: Eric Noulard mailto:eric.noul...@gmail.com>>
Sent: Thursday, October 4, 2018 5:10 PM
To: Björn Blissing mailto:bjorn.bliss...@vti.se>>
Cc: CMake Mailinglist mailto:cmake@cmake.org>>
Subject: Re: [CMake] Trouble with conditional generator expression inside 
target_link_libraries





Le jeu. 4 oct. 2018 à 16:53, Björn Blissing 
mailto:bjorn.bliss...@vti.se>> a écrit :

Hello Eric,



The minimal example was just to display the expansion error. In real life the 
code uses a Boolean variable (and the rest of the CMake code is much larger as 
well).

It was just to show the expansion error you get if you try to use a conditional 
generator expression inside a target_link_libraries function.



Sometimes the devil is hiding in the details.

Do ou manage to reproduce the genex expansion error on a toy example?



I do agree that using it would be simpler if I could use:

 $<$:${MYLIBS_DEBUG}>

 $<$:${MYLIBS_OPTIMIZED}>



But since I use a third party find module the MYLIB_LIBRARIES variable is not 
separated into these categories. I was hoping to avoid rewriting this external 
find module.



You can perfectly write a CMake helper function which takes MYLIB_LIBRARIES as 
input and spit out MYLIBS_DEBUG, MYLIBS_OPTIMIZED as an output.

This way you don't have to rewrite 3rd party code and keep your code clean.



--

Eric
-- 

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] Trouble with conditional generator expression inside target_link_libraries

[Andrew Fuller]

What happens if you put the genex inside double quotes?


target_link_libraries(my_exe
PUBLIC
 "$<$:${FOO_LIBRARIES}>"
 "$<$:bar>"
)



From: CMake  on behalf of Björn Blissing 

Sent: October 4, 2018 8:49:19 AM
To: Eric Noulard
Cc: CMake Mailinglist
Subject: Re: [CMake] Trouble with conditional generator expression inside 
target_link_libraries


Hi Eric,



I tried to do a self contained minimal example:



cmake_minimum_required(VERSION 3.12)

project(expension_error LANGUAGES CXX)



add_executable(my_exe main.cpp)



option(USE_FOOLIB "Use foo.lib" ON)

option(USE_BARLIB "Use bar.lib" ON)



list(APPEND FOO_LIBRARIES optimized foo)

list(APPEND FOO_LIBRARIES debug foo_d)





target_link_libraries(my_exe

PUBLIC

 $<$:${FOO_LIBRARIES}>

 $<$:bar>

)



But when I run this script using CMake 3.12.2, it expands to something even 
worse:



$<1:optimized;foo.lib;foo_d>.lib;bar.lib --- for debug builds

$<1:optimized;foo.lib;>.lib;bar.lib-- for release builds



So something goes really wrong when I try to use a list inside a conditional 
generator expression inside target_link_libraries().



Regards,

Björn







From: Eric Noulard 
Sent: Thursday, October 4, 2018 5:10 PM
To: Björn Blissing 
Cc: CMake Mailinglist 
Subject: Re: [CMake] Trouble with conditional generator expression inside 
target_link_libraries





Le jeu. 4 oct. 2018 à 16:53, Björn Blissing 
mailto:bjorn.bliss...@vti.se>> a écrit :

Hello Eric,



The minimal example was just to display the expansion error. In real life the 
code uses a Boolean variable (and the rest of the CMake code is much larger as 
well).

It was just to show the expansion error you get if you try to use a conditional 
generator expression inside a target_link_libraries function.



Sometimes the devil is hiding in the details.

Do ou manage to reproduce the genex expansion error on a toy example?



I do agree that using it would be simpler if I could use:

 $<$:${MYLIBS_DEBUG}>

 $<$:${MYLIBS_OPTIMIZED}>



But since I use a third party find module the MYLIB_LIBRARIES variable is not 
separated into these categories. I was hoping to avoid rewriting this external 
find module.



You can perfectly write a CMake helper function which takes MYLIB_LIBRARIES as 
input and spit out MYLIBS_DEBUG, MYLIBS_OPTIMIZED as an output.

This way you don't have to rewrite 3rd party code and keep your code clean.



--

Eric
-- 

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] Parallel builds and auto generated header files

[Andrew Fuller]

Using configure_file() at CMake time will appear to work at first glance, but 
you'll wind up with stale information when you change revisions without any 
CMake change.  CMake won't re-run automatically and thus your header file won't 
get updated.  You'll need to do it at build time to ensure it's always 
up-to-date.

How do the translation units obtain the generated header?  There needs to be 
some form of dependency between the generated header and the consumer(s).  If 
you add the generated header as an input to another target, then CMake should 
ensure the file is generated before processing the dependant target.

Also note that AFAICT add_custom_command will not re-run if the output file 
already exists (unless invalidated by a dependency).  Since you're grabbing 
dynamic information like the commit hash, then you likely want it to run 
_every_ time.  add_custom_target might be better suited for your needs.

From: CMake  on behalf of Robert Dailey 

Sent: July 19, 2018 8:05:06 AM
To: CMake
Subject: [CMake] Parallel builds and auto generated header files

I have a Version.hpp file that I have a custom command tied to which
basically runs CMake in script mode to perform configure_file() on it
during build time. The reason it does this is because it builds
Version.hpp using dynamic information, such as defining a macro with
the current SHA1 being built, etc.

I notice in parallel builds, this header file gets built too late,
because of parallel builds. What if a file includes the header and its
translation unit is built before Version.hpp is generated by the
custom command? Would it be better/simpler to do configure_file() at
configuration time instead of at build time as a custom command?
Here's the logic (some variables are defined elsewhere, but should
give you the gist):


set( generated_source_dir ${CMAKE_CURRENT_BINARY_DIR}/Source )
set( version_file_in  ${CMAKE_CURRENT_SOURCE_DIR}/Version.cpp.in )
set( version_file_out ${generated_source_dir}/Main/Version.cpp )

add_custom_command(
OUTPUT ${version_file_out}
COMMAND ${CMAKE_COMMAND}
-D IN_FILE=${version_file_in}
-D OUT_FILE=${version_file_out}
-D GIT_EXECUTABLE=${GIT_EXECUTABLE}
-D BUILD_VERSION=${ZIOSK_BUILD_VERSION}
-P ${CMAKE_CURRENT_SOURCE_DIR}/build_version_header.cmake
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
)

source_group( Generated FILES ${version_file_out} )
list( APPEND source_files ${version_file_out} )
--

Powered by www.kitware.com

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Generating include files

[Andrew Fuller]

> Hm, it's the same info I've already found in other places.

> Unfortunately, I still don't see a way to generate a source file that
> should be #include'd instead of linked into an executable.

I missed that you wanted a .h file that other libraries would pick up.  Since 
CMake isn't aware of which header files a library #includes, you're not getting 
that dependency information which I guess is what you're running into.  I 
haven't needed to do it myself, but have you tried setting your generated 
header file in the SOURCES property of your library PUBLICly (or possibly 
INTERFACE).  CMake knows the custom command that OUTPUTs a file, so when it 
tracks the file it should know the dependency to make it happen.  By exporting 
the header it should convey the dependency to the consumer(s).
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Generating include files

[Andrew Fuller]

> Is there a way to specify that foo.o depends on tab.c?  For some

> reason cmake's scan does not seem to find this.

Does the following work for you?  The first bit is just putting some fixed 
files for convenience.  The second bit is the interesting bit.  In your build 
directory you won't have a data.c file until you compile.  When it compiles, 
data.c will first be generated, placed in your build directory, then compiled 
into data.c.o and archived into libdata.a.  Finally the executable links 
against libdata.a


cmake_minimum_required( VERSION 3.0 )

# Files that exist before the build starts:

# Header file with with no matching .c file
file( WRITE ${CMAKE_CURRENT_SOURCE_DIR}/data.h "extern int somevalue;" )
# main() that references the header
file( WRITE ${CMAKE_CURRENT_SOURCE_DIR}/hello.c "
#include \"data.h\"
#include 
int main()
{
   printf( \"Magic data: %d\\n\", somevalue );
}
" )



# This file is generated at build time and is relative to the binary dir
add_custom_command( OUTPUT data.c
 COMMAND echo "int somevalue = 42; " > data.c
 VERBATIM
)

add_library( data ${CMAKE_CURRENT_BINARY_DIR}/data.c )
add_executable( hello hello.c )

target_link_libraries( hello
 PRIVATE data
)


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Trouble with FindPNG module

[Andrew Fuller]

Try adding this to your toolchain file:


set( CMAKE_C_LIBRARY_ARCHITECTURE "i386-linux-gnu" )

set( CMAKE_CXX_LIBRARY_ARCHITECTURE "i386-linux-gnu" )



From: rcdai...@gmail.com <rcdai...@gmail.com> on behalf of Robert Dailey 
<rcdailey.li...@gmail.com>
Sent: April 24, 2017 10:22:53 AM
To: Andrew Fuller
Cc: CMake
Subject: Re: [CMake] Trouble with FindPNG module

The output is:

x86_64-linux-gnu

How can I tell CMake to look for 32-bit libraries? I would like to
force this from my toolchain file (which I posted a few minutes ago)

On Mon, Apr 24, 2017 at 10:16 AM, Andrew Fuller <aful...@teradici.com> wrote:
> Where did the library get installed on your system?  What's the value of
> CMAKE__LIBRARY_ARCHITECTURE?
>
>
> Since you're on a 64-bit system, I'd expect CMake to be looking for 64-bit
> libraries unless you've told it otherwise.
>
> 
> From: CMake <cmake-boun...@cmake.org> on behalf of Robert Dailey
> <rcdailey.li...@gmail.com>
> Sent: April 24, 2017 7:54:18 AM
> To: CMake; CMake Developers
> Subject: Re: [CMake] Trouble with FindPNG module
>
> Sorry to bump; any info on this? I'm completely blocked :-(
>
> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>>
>> find_package(PNG REQUIRED)
>>
>> Which gives me the output in CMake:
>>
>> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>>
>> The CMakeCache.txt file has these variables set:
>>
>> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
>> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
>> PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>>
>> So it found the headers, but not the libs. Why did it not find the
>> libs? Note that my version of Ubuntu is 64-bit, and I've installed the
>> 32-bit libs like so:
>>
>> $ sudo apt-get install libpng12-dev:i386
>>
>> Would the find module be confused because it is trying to find the
>> 64-bit library? What's the issue?
> --
>
> Powered by www.kitware.com<http://www.kitware.com>
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Trouble with FindPNG module

[Andrew Fuller]

Where did the library get installed on your system?  What's the value of 
CMAKE__LIBRARY_ARCHITECTURE?


Since you're on a 64-bit system, I'd expect CMake to be looking for 64-bit 
libraries unless you've told it otherwise.


From: CMake  on behalf of Robert Dailey 

Sent: April 24, 2017 7:54:18 AM
To: CMake; CMake Developers
Subject: Re: [CMake] Trouble with FindPNG module

Sorry to bump; any info on this? I'm completely blocked :-(

On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey  wrote:
> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>
> find_package(PNG REQUIRED)
>
> Which gives me the output in CMake:
>
> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>
> The CMakeCache.txt file has these variables set:
>
> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
> PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>
> So it found the headers, but not the libs. Why did it not find the
> libs? Note that my version of Ubuntu is 64-bit, and I've installed the
> 32-bit libs like so:
>
> $ sudo apt-get install libpng12-dev:i386
>
> Would the find module be confused because it is trying to find the
> 64-bit library? What's the issue?
--

Powered by www.kitware.com

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

[CMake] Clarifying PUBLIC_HEADER property and non-FRAMEWORK / STATIC / INTERFACE libraries

[Andrew Fuller]

I'm finding the PUBLIC_HEADER target property to be quite convenient for 
clarity's sake.  Specifically it spells out quite unambiguously that "hey, 
these are the headers I want to be published" while at the same time providing 
locality to the export details with "PUBLIC_HEADER DESTINATION foo" and 
"INCLUDES DESTINATION foo".  Less code by not needing a separate "install( 
FILES … )" stanza is a bonus.


The documentation for the PUBLIC_HEADER property seems to stress (framework) 
shared libraries.  I'm left wondering if I'm abusing PUBLIC_HEADER by using it 
on static libraries as well.  Am I going to get bit down the road by doing 
this, or is this use perfectly acceptable?


Assuming it's fine to use on static libraries, then how about interface 
libraries?  I see there have been previous discussions on the mailing list 
about whether more properties should be whitelisted for interface targets, but 
I didn't see PUBLIC_HEADER brought up.  Updating the interface includes 
directory using the "INCLUDES DESTINATION foo" when exporting an interface 
library already works, so it would be very nice to be able to leverage 
PUBLIC_HEADER at the same time.  Again, for clarity/consistency/less code.  Is 
there a technical limitation, or is it just a matter of adding public_header to 
the whitelist?  For now I've just got an extra "install( FILES … )" stanza.


Thanks in advance.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Improved handling of %directives in CPACK_RPM_USER_FILELIST

[Andrew Fuller]

Attached is a patch to improve the handling of %directives in 
CPACK_RPM_USER_FILELIST.  Specifically it accepts any characters (even spaces) 
inside the parenthesis so it doesn't need to keep changing every time there's a 
new valid symbol.  The current open ticket is 
https://gitlab.kitware.com/cmake/cmake/issues/13468 which is asking to use an 
underscore.  %caps requires the use of '+' and also spaces.


I've created a merge request here: 
https://gitlab.kitware.com/cmake/cmake/merge_requests/23? with the same 
contents as this format-patch, but the contribution guidelines say a 
format-patch to this list is desired.


Cheers,

-Andrew??
From 13717c3943e11848233f6c8e95ee69ba3bda3ec1 Mon Sep 17 00:00:00 2001
From: Andrew Fuller <aful...@teradici.com>
Date: Fri, 24 Jun 2016 10:45:40 -0700
Subject: [PATCH] Adjust the regex to handle %foo and %foo(anything)
 directives.

Directives that are legal inside the %files section of an RPM spec may contain a variety of characters particularly when specifying %caps which can include +, _, and space.  Watch for parenthesis to determine what forms the prefix vs. path.

Fixes issue #14362
---
 Modules/CPackRPM.cmake | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index d231ff0..cb8cdc8 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -1683,8 +1683,8 @@ function(cpack_rpm_generate_package)
 
 set(CPACK_RPM_USER_INSTALL_FILES "")
 foreach(F IN LISTS CPACK_RPM_USER_FILELIST_INTERNAL)
-  string(REGEX REPLACE "%[A-Za-z0-9\(\),-]* " "" F_PATH ${F})
-  string(REGEX MATCH "%[A-Za-z0-9\(\),-]*" F_PREFIX ${F})
+  string(REGEX REPLACE "%[A-Za-z]+(\\(.*\\))? " "" F_PATH ${F})
+  string(REGEX MATCH "%[A-Za-z]+(\\(.*\\))?" F_PREFIX ${F})
 
   if(CPACK_RPM_PACKAGE_DEBUG)
 message("CPackRPM:Debug: F_PREFIX=<${F_PREFIX}>, F_PATH=<${F_PATH}>")
-- 
2.7.4

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] generator expressions

[Andrew Fuller]

On Fri, Jun 6, 2014 at 8:28 AM, Brad King brad.k...@kitware.com wrote:

 On 06/06/2014 11:07 AM, Andrew Fuller wrote:
  On Fri, Jun 6, 2014 at 6:08 AM, Brad King brad.k...@kitware.com
 mailto:brad.k...@kitware.com wrote:
 
  I cannot reproduce these.  Can you provide a complete CMakeLists.txt
  example please?
 
  Attached

 Thanks.  I meant to quote the whole outermost $ expression as one
 argument.  Also you are missing some closing '' in the last block.
 For example:

 -$$PLATFORM_ID:Windows:${_windowsLibListL}
 -$$PLATFORM_ID:Linux:$JOIN:${_linuxLibListL}, -l
 +$$PLATFORM_ID:Windows:${_windowsLibListL}
 +$$PLATFORM_ID:Linux:$JOIN:${_linuxLibListL}, -l

 -Brad


Oh my!  I wouldn't have thought of doing that.  Oops about the missed
closing ''; with the closing  but not adjusting the quotes still gives
the syntax error.

But adding quotes around the entire thing ...  now that works!  (even for
test #2 where I'm not using $JOIN  That's an easy fix for my project.

Should I be quoting all my generator expressions?  Is that the proper
syntax?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] generator expressions

[Andrew Fuller]

On Fri, Jun 6, 2014 at 8:43 AM, Brad King brad.k...@kitware.com wrote:

 On 06/06/2014 11:37 AM, Andrew Fuller wrote:
  Should I be quoting all my generator expressions?
  Is that the proper syntax?

 The CMake language does not actually know anything about generator
 expressions.  They are just strings like any other command arguments
 as far as it knows.  See the command argument syntax documentation
 here:


 http://www.cmake.org/cmake/help/v3.0/manual/cmake-language.7.html#command-arguments

 In order to ensure the command receives a generator expression in
 its entirety it should be double-quoted if it contains any literal
 spaces or ${var} evaluations that may have ; in them.  Otherwise
 it is not necessary to quote and sometimes looks nicer not to.  It
 is always safe to quote generator expressions though.

 -Brad


I agree it often looks better without the quotes.  But correctness trumps
aesthetics.  I guess where I went astray was that it appeared to work
unquoted when doing a simple test with add_executable and so I standardized
on unquoted which then came back to bite me unexpectedly later.  I think
I'm understanding better the situation thanks to your explanation combined
with that link.

I shall quote them all!
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] --graphviz and generator expressions

[Andrew Fuller]

I'm trying out the --graphviz option to visualize link dependencies -- very
useful!

It seems to me that it does not understand generator expressions.  We make
use of generator expressions to bring in platform-specific libraries and
when I generate the graphviz on Linux I'm still seeing Windows libraries in
the graph.

What is the proper way to generate the graph for a particular configuration?

Thanks,
-Andrew
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] --graphviz and generator expressions

[Andrew Fuller]

Sorry, I meant to keep this on the mailing list.  Hit reply without
checking.

On Thu, Jun 5, 2014 at 1:33 PM, Andrew Fuller mactalla.ob...@gmail.com
wrote:

 A non-trivial overhaul of the graphviz option implementation will
 be needed to make it useful on projects using modern features.


 Okay, I understand.

 As I've continued to investigate this I think my issue is actually deeper.

 When setting compiler definitions I can set a list within a generator
 expression and the entire set is handled correctly.

 eg:
 target_compile_definitions( my_target PRIVATE
  $$PLATFORM_ID:Windows:winone;wintwo
  $$PLATFORM_ID:Linux:linuxone;linuxtwo )
 gives -Dlinuxone -Dlinuxtwo on the command line under Linux.

 However, trying to do the same with target_link_libraries yields different
 results:
 target_link_libraries( my_target PRIVATE
  $$PLATFORM_ID:Windows:win.1;win.2
  $$PLATFORM_ID:Linux:lin.1;lin.2 )
 gives a link line of -lwin.2 -llin.1 -llin.2

 As I was experimenting I discovered that $JOIN:... provides an
 interesting perspective into the issue:
 target_link_libraries( my_target PRIVATE
  $$PLATFORM_ID:Windows:$JOIN:win.1;win.2, -I
  $$PLATFORM_ID:Linux:lin.1;lin.2 )
 gives a link line of -llin.1 -llin.2
 $JOIN... seems to correctly group the list so the elements don't leak
 out of the generator expression.  At least when the condition evaluates to
 0.

 However,
 target_link_libraries( my_target PRIVATE
  $$PLATFORM_ID:Windows:$JOIN:win.1;win.2, -I
  $$PLATFORM_ID:Linux:$JOIN:lin.1;lin.2, -l )
 Gives
 CMake Error:

   Error evaluating generator expression:

 $JOIN:lin.1

   $JOIN expression requires 2 comma separated parameters, but got 1
   instead.

 It appears in this instance as though the list is being split before the
 generator expression is being evaluated.  $JOIN... seems to function as
 expected when used in target_compile_definitions.

 Is there a limitation in target_link_libraries I should be aware of?  I
 didn't find anything obvious in the documentation.
 I should mention I'm running 3.0.0-rc3 and set cmake_policy( VERSION 3.0 ).

 Thanks,
 -Andrew



-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] target_include_directories and relative paths inside generator expressions.

[Andrew Fuller]

On Thu, Apr 24, 2014 at 1:21 AM, Stephen Kelly steve...@gmail.com wrote:

 Andrew Fuller wrote:

  It seems absolute paths are necessary. eg:
 
  target_include_directories( MyTarget PRIVATE
  $$PLATFORM_ID:Linux:${CMAKE_CURRENT_SOURCE_DIR}/some/dir )
 
  will perform as expected.
 
  Is this behaviour expected (and should be documented) or should I file a
  bug?

 CMake doesn't know at configure-time what the $... at the start of the
 path will evaluate to at generate time (It could even be different things,
 depending on the config).


Oh okay.  I didn't realize that expanding relative paths to absolute would
be done prior to evaluating the generator expression.  Now that I know that
detail the current behaviour is understandable.

Thanks for the clarification.
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] target_include_directories and relative paths inside generator expressions.

[Andrew Fuller]

Running CMake 3.0-rc3 and the docs for target_include_directories say the
paths may be absolute or relative.  Indeed the following works as desired:

target_include_directories( MyTarget PRIVATE some/dir )

The docs also mention that generator expressions can be used.  However the
following produces an error:

target_include_directories( MyTarget PRIVATE
$$PLATFORM_ID:Linux:some/dir )

CMake Error in CMakeLists.txt:
Found relative path while evaluating include directories of
  foo:
some/dir

It seems absolute paths are necessary. eg:

target_include_directories( MyTarget PRIVATE
$$PLATFORM_ID:Linux:${CMAKE_CURRENT_SOURCE_DIR}/some/dir )

will perform as expected.

Is this behaviour expected (and should be documented) or should I file a
bug?

Thanks,
-Andrew
-- 

Powered by www.kitware.com

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

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

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

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

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