Re: [CMake] Syntax to document cmake files, functions and macros

[Oleksii Vilchanskyi]

On 12/24/18 12:01 PM, Olivier Croquette wrote:
> I have quite a few .cmake files that I want to document. They define
> functions, macros, and variables, and I was wondering if there is any
> standard or tooling to help.

Yes, see [1]. You can find concrete examples at [2].

[1]:

[2]: 



signature.asc
Description: OpenPGP digital signature
-- 

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] Fwd: cmake cannot find source file (new to cmake)

[Oleksii Vilchanskyi]

Forwarding to the list and replying to some parts.

> I removed add_subdirectories and added path to each of the source
> file according to your instruction and things worked! I just have a
> quick question: why should I remove the add_subdirectories in the src
> CMakeLists.txt? I thought add_subdirectories should tell cmake to look
> for files in the directories?

add_subdirectory() tells CMake that there's yet another listfile
(CMakeLists.txt) in a subdirectory, which will be processed recursively
until no further listfiles are found inside. Then the normal procedural
flow continues. So it doesn't say anything about project files, just
that new script code that might involve the project files needs to be
processed.

>>> Toplevel
>>> 
>>>|- CMakeLists.txt
>>> 
>>>|- src |--CMakeLists.txt
>>> 
>>>| 
>>> |--common---|---CMakeLists.txt
>>> 
>>>|  |--dir1-| 
>>>  |--- src1.h
>>> 
>>>|  |-CMakeLists.txt
>>> 
>>>|bin|-src2.c
>>> 
>>>   |-src3.c
>> 
>> It's quite hard to figure out what's going on here, but I assume src1.h
>> is under src/common. Please post the output of 'tree' command next time,
>> if you are on a Unix.
>> 
>>> set(src_files src1.h src2.c src3.c)
>> 
>> You don't have to add headers as target dependencies unless you program
>> in an IDE (just fyi).
>> 
>>>  CMakeLists.txt in common and dir1 are empty.
>> 
>> So, either partially move your CMake scripts into these subdirectories,
>> or don't do `add_subdirectory()`. For example:
>> 
>> src/CMakeLists.txt:
>> add_executable(exec dir1/src1.c dir1/src2.c dir1/src3.c)
>> target_include_directories(exec PRIVATE
>> "${CMAKE_CURRENT_SOURCE_DIR}/common")

-- 
Alex
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] cmake cannot find source file (new to cmake)

[Oleksii Vilchanskyi]

>     Toplevel
> 
>        |- CMakeLists.txt
> 
>        |- src |--CMakeLists.txt
> 
>        |                     
> |--common---|---CMakeLists.txt
> 
>        |                      |--dir1-|                 
>  |--- src1.h
> 
>        |                                          |-CMakeLists.txt
> 
>        |bin                                |-src2.c
> 
>                                                   |-src3.c

It's quite hard to figure out what's going on here, but I assume src1.h
is under src/common. Please post the output of 'tree' command next time,
if you are on a Unix.

>                 set(src_files src1.h src2.c src3.c)

You don't have to add headers as target dependencies unless you program
in an IDE (just fyi).

>      CMakeLists.txt in common and dir1 are empty.

So, either partially move your CMake scripts into these subdirectories,
or don't do `add_subdirectory()`. For example:

src/CMakeLists.txt:
add_executable(exec dir1/src1.c dir1/src2.c dir1/src3.c)
target_include_directories(exec PRIVATE
"${CMAKE_CURRENT_SOURCE_DIR}/common")

-- 
Alex



signature.asc
Description: OpenPGP digital signature
-- 

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] INTERFACE library and path to source.

[Oleksii Vilchanskyi]

> I'm not that sure that this is the "expected" behavior

Yes, now it looks like a bug to me, too. Being written as it was in the
last message,
> target_sources(lib INTERFACE lib.h)
can be treated as the equivalent of
> target_sources(main PRIVATE lib.h)
(and therefore generating an error).

However,
> target_include_directories(lib INTERFACE "${CMAKE_CURRENT_SOURCE_DIR}")
on the command line resolves to
> -I/home/l2y/<...>/lib
and
> target_include_directories(lib INTERFACE ".")
resolves to
> -I/home/l2y/<...>/lib/.

Also, looking at `/main/CMakeFiles/main.dir/depend.internal`:

> main/CMakeFiles/main.dir/main.c.o
>  ../lib/lib.h
>  /home/l2y/<...>/main/main.c
So, all elements in `target_include_directories()` resolve to full
paths, as well as `target_sources()`, while `target_sources(INTERFACE)`
stay relative, which causes trouble.

On 11.12.2017 09:20, Eric Noulard wrote:
> 
> 
> 2017-12-09 1:37 GMT+01:00 Oleksii Vilchanskyi
> <oleksii.vilchans...@gmail.com <mailto:oleksii.vilchans...@gmail.com>>:
> 
> Hello Eric,
> 
> > Why should I do that?
> > Is this the expected behavior / way to create header only library?
> 
> Yes, this is the expected behaviour. CMake interprets a relative path to
> the file according to the target's add_library() or add_executable()
> call directory. I will provide a minimal, reproducible example:
> 
> 
> Hi Oleksii,
> 
> Thanks you for the minimal reproducible example.
> I'm bot that sure that this is the "expected" behavior
>  
> 
> Listfile under `lib`:
> 
> > add_library(lib INTERFACE)
> > target_include_directories(lib INTERFACE
> "${CMAKE_CURRENT_SOURCE_DIR}")
> > target_sources(lib INTERFACE "lib.h")
> 
> 
> With the previous one would expect that any target linking to this
> interface target
> will be provided with the include directories provided in its interface.
> In your case (and in mine too) this is given with **full path**
>  
> 
> 
> Listfile under `main`:
> 
> > add_executable(main "main.c")
> > target_link_libraries(main PRIVATE lib)
> 
> Now, let's look at the diagnostics:
> 
> > CMake Error at main/CMakeLists.txt:1 (add_executable):
> >   Cannot find source file:
> >
> >     lib.h
> 
> So, the problem occurs when CMake cannot find `lib.h` relatively to
> `add_executable(main "main.c")` call. Whether it's the expected
> behaviour is debatable (I personally would prefer CMake to search
> relatively to `add_library(lib INTERFACE)`), and the documentation is
> silent on this caveat either, so there's that.
> 
> 
> Yes precisely. This seems to work OK for imported targets but not for
> header-only in-project lib.
>  
> 
> 
> One way to solve this is to provide a path to `lib.h` relatively to
> `main` directory, another way is to provide a full path.
> 
> 
> We (you and me) already provide 
>  target_include_directories
> with full path.
> 
> I cannot provide the file themselves with relative path since they may
> be used
> from different place.
> 
> I guess I will open an issue unless someone explain me the rational
> behind that behavior.
> 
> 
> -- 
> Eric

-- 
Regards,
Oleksii Vilchanskyi
PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338



signature.asc
Description: OpenPGP digital signature
-- 

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] INTERFACE library and path to source.

[Oleksii Vilchanskyi]

Hello Eric,

> Why should I do that?
> Is this the expected behavior / way to create header only library?

Yes, this is the expected behaviour. CMake interprets a relative path to
the file according to the target's add_library() or add_executable()
call directory. I will provide a minimal, reproducible example:

> .
> ├── CMakeLists.txt
> ├── lib
> │   ├── CMakeLists.txt
> │   └── lib.h
> └── main
> ├── CMakeLists.txt
> └── main.c

First listfile:

> cmake_minimum_required(VERSION 3.10)
> project(main LANGUAGES C)
> add_subdirectory(lib)
> add_subdirectory(main)

Listfile under `lib`:

> add_library(lib INTERFACE)
> target_include_directories(lib INTERFACE "${CMAKE_CURRENT_SOURCE_DIR}")
> target_sources(lib INTERFACE "lib.h")

Listfile under `main`:

> add_executable(main "main.c")
> target_link_libraries(main PRIVATE lib)

Now, let's look at the diagnostics:

> CMake Error at main/CMakeLists.txt:1 (add_executable):
>   Cannot find source file:
> 
> lib.h

So, the problem occurs when CMake cannot find `lib.h` relatively to
`add_executable(main "main.c")` call. Whether it's the expected
behaviour is debatable (I personally would prefer CMake to search
relatively to `add_library(lib INTERFACE)`), and the documentation is
silent on this caveat either, so there's that.

One way to solve this is to provide a path to `lib.h` relatively to
`main` directory, another way is to provide a full path.
On 12/8/17 4:42 PM, Eric Noulard wrote:
> Hi there,
> 
> I encounter a weird issue with header-only library.
> 
> Somewhere in my source tree I have an header library which consist in a
> bunch of headers:
> 
> The concerned CMakeLists.txt looks like this:
> 
> add_library(MyHeaderLIB INTERFACE)
> 
> target_include_directories(MyHeaderLIB INTERFACE
>     ${CMAKE_CURRENT_SOURCE_DIR})
> 
> target_sources(MyHeaderLIB INTERFACE
>   whatever.h)
> 
> 
> Somewhere else (in another directory) I have another CMakeLists.txt:
> 
> add_executable(myexe myexe.cpp)
> target_link_libraries(myexe MyHeaderLIB)
> 
> and CMake complains when processing it that he cannot find "whatever.h"...
> 
> The problem disappear if I use full path in target_source, i.e.:
> 
> target_sources(MyHeaderLIB INTERFACE
>  ${CMAKE_CURRENT_SOURCE_DIR}/whatever.h)
> 
> 
> Why should I do that?
> I this the expected behavior / way to create header only library?
> 
> 
> -- 
> Eric
> 
> 

-- 
Regards,
Oleksii Vilchanskyi
PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338

***
All the world's a pipeline,
And all the men and women merely instructions.



signature.asc
Description: OpenPGP digital signature
-- 

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] CPack OS X bundle : generator expression for CPACK_BUNDLE_STARTUP_COMMAND

[Oleksii Vilchanskyi]

Hi,

`set()` is evaluated at configuration time and as of CMake 3.10 does not
accept genexps. You can refer to this diagram for better understanding
of the general CMake pipeline:
<https://cgold.readthedocs.io/en/latest/_images/cmake-environment.png>

Therefore,

>   SET ( APP_LOCATION "$" )
>   SET ( CPACK_BUNDLE_STARTUP_COMMAND ${APP_LOCATION} )

is interpreted exactly how it's written:

> CPack Error: Error copying $ to...

Due to this limitation your [probably] sole option to introduce genxps
in CPack config would be to use `file(GENERATE)`. Otherwise, use
single-configuration generators and you won't have
configuration-dependent paths.

On 29.11.2017 01:50, Nicholas Yue wrote:
> I am using CMake 3.10
> 
> I can't seems to find a way to tell the OS X bundle where to find the
> compiled binary.
> 
> I get the following errors:
> 
> Run CPack packaging tool...
> CPack: Create package using Bundle
> CPack: Install projects
> CPack: - Run preinstall target for: OSXBundle
> CPack: - Install project: OSXBundle
> CPack: Create package
> CPack Error: Error copying $ to
> /Users/nicholas/projects/OSX_BundleRPath/build/_CPack_Packages/Darwin/Bundle/OSXBundle-0.1.1-Darwin/MyApp.app/Contents/MacOS/MyApp
> CPack Error: Error copying startup command.  Check the value of
> CPACK_BUNDLE_STARTUP_COMMAND.
> CPack Error: Problem compressing the directory
> CPack Error: Error when generating package: OSXBundle
> make: *** [package] Error 1
> 
> 
> I have the following CMakeLists.txt:
> 
> CMAKE_MINIMUM_REQUIRED(VERSION 3.8)
> 
> PROJECT (OSXBundle)
> 
> FIND_PACKAGE (Boost REQUIRED)
> 
> ADD_EXECUTABLE (myapp
>   src/main.cpp
>   )
> 
> INSTALL ( TARGETS
>   myapp
>   DESTINATION
>   ./bin
>   )
> 
> IF (APPLE)
>   # GET_TARGET_PROPERTY ( APP_LOCATION myapp LOCATION )
>   SET ( APP_LOCATION "$" )
>   
>   SET ( CPACK_BUNDLE_NAME "MyApp" )
>   
>   SET ( CPACK_GENERATOR "Bundle" )
>   SET ( CPACK_BUNDLE_PLIST
> ${CMAKE_CURRENT_SOURCE_DIR}/resources/Info.plist )
>   SET ( CPACK_BUNDLE_ICON ${CMAKE_CURRENT_SOURCE_DIR}/resources/MyApp.icns )
>   SET ( CPACK_PACKAGE_ICON
> ${CMAKE_CURRENT_SOURCE_DIR}/resources/MyApp.icns )
>   SET ( CPACK_BUNDLE_STARTUP_COMMAND ${APP_LOCATION} )
> ENDIF ()
> 
> INCLUDE ( CPack )
> 
> 
> 

-- 
Regards,
Oleksii Vilchanskyi
PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338

***
All the world's a pipeline,
And all the men and women merely instructions.



signature.asc
Description: OpenPGP digital signature
-- 

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] Handling of generator expressions

[Oleksii Vilchanskyi]

UPD. forgot to CC the mailing list

Hi,

I am also confused by this and decided to test it. I found a long thread
from 2012
<https://cmake.org/pipermail/cmake-developers/2012-August/thread.html#16509>
that discusses list expansion issues. It doesn't tell though whether the
patch was mainlined.

tldr; if you quote the whole genexpr, the list will expand properly.
Below is the working code.

--
cmake_minimum_required(VERSION 3.3 FATAL_ERROR)

project(recipe-09 CXX)

set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_EXTENSIONS OFF)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

list(APPEND CXX_BASIC_FLAGS "-g3" "-O1")

include(CheckCXXCompilerFlag)

set(ASAN_FLAGS "-fsanitize=address -fno-omit-frame-pointer")
set(CMAKE_REQUIRED_FLAGS ${ASAN_FLAGS})
check_cxx_compiler_flag(${ASAN_FLAGS} asan_works)
unset(CMAKE_REQUIRED_FLAGS)

add_executable(asan-example asan-example.cpp)
string(REPLACE " " ";" _asan_flags ${ASAN_FLAGS})
target_compile_options(asan-example
  PUBLIC
${CXX_BASIC_FLAGS}
$<$<BOOL:${asan_works}>:${_asan_flags}>
  )
target_link_libraries(asan-example
  PUBLIC
"$<$<BOOL:${asan_works}>:${_asan_flags}>" # <-- NOTE THIS
  )
--

On 19.11.2017 19:16, Roberto Di Remigio wrote:
> Hello,
> I am trying to compile the following code snippet:
> 
> int main(int argc, char ** argv) {
>   int stack_array[100];
>   stack_array[1] = 0;
>   return stack_array[argc + 100]; // BOOM
> }
> 
> The followin CMakeLists.txt works fine, but you can notice that
> target_compile_options takes a list, while target_link_libraries takes a
> string. Always using the string will result in a compilation error,
> because the compiler flags are passed quoted to the compiler. Always
> using the list doesn't work either, because the generator expression is
> evaluated as $<1:-fsanitize=address -fno-omit-frame-pointer> and then
> passed as-is to the linker, which doesn't know what to do with it.
> Is this supposed to be like this? If yes, what's the rationale?
> Thanks in advance!
>   Roberto
> 
> cmake_minimum_required(VERSION 3.3 FATAL_ERROR)
> 
> project(recipe-09 CXX)
> 
> set(CMAKE_CXX_STANDARD 11)
> set(CMAKE_CXX_EXTENSIONS OFF)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
> 
> list(APPEND CXX_BASIC_FLAGS "-g3" "-O1")
> 
> include(CheckCXXCompilerFlag)
> 
> set(ASAN_FLAGS "-fsanitize=address -fno-omit-frame-pointer")
> set(CMAKE_REQUIRED_FLAGS ${ASAN_FLAGS})
> check_cxx_compiler_flag(${ASAN_FLAGS} asan_works)
> unset(CMAKE_REQUIRED_FLAGS)
> 
> add_executable(asan-example asan-example.cpp)
> string(REPLACE " " ";" _asan_flags ${ASAN_FLAGS})
> target_compile_options(asan-example
>   PUBLIC
>     ${CXX_BASIC_FLAGS}
>     $<$<BOOL:${asan_works}>:${_asan_flags}>
>   )
> target_link_libraries(asan-example
>   PUBLIC
>     $<$<BOOL:${asan_works}>:${ASAN_FLAGS}>
>   )
> 
> 

-- 
Regards,
Oleksii Vilchanskyi
PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338



signature.asc
Description: OpenPGP digital signature
-- 

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] Create Mac OS Bundle with VTK and Qt

[Oleksii Vilchanskyi via CMake]

Hello,

> 1) I try to add an icon without success
> When I launch my app, the default icon is used and not my icon.

Can you elaborate on this? You say that the .icns file is under
Resources and the final Info.plist contains the proper key with the
proper value and that a non-default icon is used when the application is
launched. If you do actually see the icon on the application [for
example] in Launchpad, then the bundle is correctly built and macOS can
recognize the icon. If instead you see something like this[0], then the
bundle is built incorrectly.

However, you also say "when I launch my app", which, if you mean
application's runtime in particular, is unrelated to CMake or bundling.
If the tray icon is broken etc. it's something your application is not
doing (for example, we use RCC and /image for the icon).

So, if this is the former, then the bundling part is incorrect, if it's
the latter, the program's behaviour is incorrect.

As a side note, I don't rely on MACOSX_PACKAGE_LOCATION property and
install() the icon where it belongs.

> 2) For the libraries of VTK I tried to use macdeployqt (found using
find_program) but it doesn’t found the libraries (installed in a custom
directories)
> Is there a simple way to copy all found libraries/framework?

I would recommend using DeployQt5.cmake module[1] instead of
macdeployqt. Initially found on this list and later edited by Marcus D.
Hanwell, the module (I believe) is distributed under BSD 3-clause.

Usage example[2], also under BSD 3-clause (I believe).

[0]: <https://doc.qt.io/archives/qq/qq09-demo-icon.png>
[1]:
<https://github.com/OpenChemistry/avogadroapp/blob/master/cmake/DeployQt5.cmake>
[2]:
<https://github.com/OpenChemistry/avogadroapp/blob/master/avogadro/lastinstall/CMakeLists.txt>

Regards,
Oleksii Vilchanskyi

On 8.9.2017 18:11, Romain LEGUAY wrote:
> Hello everyone,
> 
> Since this morning, I try to create a Bundle Application using CMake (3.9.1).
> 
> My application use VTK (8.x) and Qt (5.x). The find_package of those two 
> libraries works greats (no problem to build and run the application).
> 
> I have many problems:
> 
> 1) I try to add an icon without success.
> 2) I don’t know how (and where) to copy VTK dynamic libraries.
> ( Optional / not really related ) 3) When I try to use only some components 
> of VTK, my application is linking to all VTK modules
> 
> I’m going to details each points:
> 
> 1) For the icon issue, I proceed this way:
> 
>  
> set(ICON_NAME "appIcon.icns") # I try without the icns extension without 
> success.
> set(ICON_PATH "${CMAKE_CURRENT_SOURCE_DIR}/resources/icons/${ICON_NAME}")
> set_source_files_properties("${ICON_PATH}" PROPERTIES MACOSX_PACKAGE_LOCATION 
> Resources)
> 
> add_executable(MYAPP MACOSX_BUNDLE ${ICON_PATH} ${other_sources})
> 
> set_target_properties(CRAFPACK_GUI PROPERTIES
>   MACOSX_BUNDLE_ICON_FILE ${ICON_NAME})
> 
> 
> The icon is copied inside the Resources folder of my bundle and the 
> Info.plist is well updated (the CFBundleIconFile key is set to 
> "appIcon.icns").
> 
> When I launch my app, the default icon is used and not my icon.
> 
> 
> 2) For the libraries of VTK I tried to use macdeployqt (found using 
> find_program) but it doesn’t found the libraries (installed in a custom 
> directories)
> 
> I tried to use BundleUtilities without any success (except to tell me that 
> cmake doesn’t found the libraries).
> 
> I attach you my CMakeLists.
> 
> Is there a simple way to copy all found libraries/framework?
> 
> Thank you!
> 
> 
> 
-- 

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] POSITION_INDEPENDENT_CODE's [un]expected behaviour

[Oleksii Vilchanskyi via CMake]

Hello,

I would like to ask about POSITION_INDEPENDENT_CODE target property. As
of CMake 3.8.2 POSITION_INDEPENDENT_CODE appends -fPIE or -fPIC to
CMAKE__FLAGS and CMAKE_EXE_LINKER_FLAGS when building an
executable or a library respectively. However, to build a PIE -pie
linker flag is additionally required. Thus POSITION_INDEPENDENT_CODE is
not behaving as expected being a really easy to fix for someone aware
with CMake codebase.

Is there any reason why it wasn't added when the property was
introduced? Somebody proposed introducing
POSITION_INDEPENDENT_EXECUTABLE later on in addition to
POSITION_INDEPENDENT_CODE to maintain backwards compatibility (I suppose
policies are also a solution?).

This email is the result of the thread
<https://github.com/arsenm/sanitizers-cmake/issues/13> and the message
<https://github.com/arsenm/sanitizers-cmake/issues/13#issuecomment-315532253>
by Juan Navarro (big thanks to him), which fully summarizes CMake's
POSITION_INDEPENDENT_CODE treatment and links to multiple bugs: this one
<https://cmake.org/Bug/view.php?id=14983>, so far without attention, and
this one <https://gitlab.kitware.com/cmake/cmake/issues/16382>, resolved
for Android.

Thank you.

Regards,
Oleksii Vilchanskyi

-- 

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