[CMake] Custom Configurations and CMAKE__FLAGS__INIT

[Marek Vojtko (Firaxis)]

Hi,

Do CMAKE__FLAGS__INIT variables not automatically populate 
CMAKE__FLAGS_ variables for *custom* configurations? 

When I use the _INIT variables for one of the default configuration names, e.g. 
CMAKE_C_FLAGS_DEBUG_INIT or CMAKE_C_FLAGS_RELEASE_INIT, they correctly populate 
their "usage" counterparts, i.e. CMAKE_C_FLAGS_DEBUG and CMAKE_C_FLAGS_RELEASE 
respectively.

But when I set the _INIT variables for a custom configuration name (created 
through CMAKE_CONFIGURATION_TYPES), e.g. CMAKE_C_FLAGS_LALALAND_INIT, CMake 
fails the compiler tests, because CMAKE_C_FLAGS_LALALAND does not exist.

My setup:

*CMakeLists.txt*
set( CMAKE_USER_MAKE_RULES_OVERRIDE 
"${CMAKE_CURRENT_LIST_DIR}/CompilerOptions.cmake" )
project( Test )
add_executable( "${CMAKE_CURRENT_LIST_DIR}/main.c" )

*CompilerOptions.cmake*
set( CMAKE_CONFIGURATION_TYPES "Debug" "Release" "Lalaland" )

set( CMAKE_C_FLAGS_DEBUG_INIT "/Od" )
set( CMAKE_C_FLAGS_RELEASE_INIT "/Ox" )
set( CMAKE_C_FLAGS_LALALAND_INIT "/Ob2" )

set( CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "/machine:x64" )
set( CMAKE_EXE_LINKER_FLAGS_RELEASE_INIT "/machine:x64" )
set( CMAKE_EXE_LINKER_FLAGS_LALALAND_INIT "/machine:x64" )

The error I get is:

> CMake Error: Error required internal CMake variable not set, cmake may not be 
> built correctly.
> Missing variable is:
> CMAKE_C_FLAGS_LALALAND

> CMake Error: Error required internal CMake variable not set, cmake may not be 
> built correctly.
> Missing variable is:
> CMAKE_EXE_LINKER_FLAGS_LALALAND

> CMake Error at C:/Program 
> Files/CMake/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:37 
> (try_compile):
> Failed to generate test project build system.

This is just a simplified example, in my actual usecase I have two custom 
configurations and both fail to populate their CMAKE__FLAGS_ 
variables from their CMAKE__FLAGS__INIT variables.

Do I have to set the CMAKE__FLAGS__INIT variables for the default 
CMake configuration names, but set the actual CMAKE__FLAGS_ 
variables for any custom configurations?
 
I am using CMake 3.10.3 and Visual Studio 11/14 Win64 generator.

Thanks,
Marek

-- 

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] Cygwin DS-5 Arm Cross-compiling and how to get past Compiler Check error w/ Absolute path

[Jimi Damon]

Hi,

I have an issue running the 16.1  DS-5  Arm compiler tool suite that is
based around the GNU arm embedded toolchain.

The problem is that these compilers cannot process the Cygwin path
structure ( Ie /cygdrive/c/path/to/file ).

I have a build that works perfectly under Linux using CMake and a
CMAKE_TOOLCHAIN_FILE using this same DS-5 compiler build for Linux.
The problem is that my teammates develop under Cygwin and I wanted to port
this build (hence the reason for Cmake ) to Cygwin.



1. The first problem I have is that when I try to run
cmake  -DCMAKE_TOOLCHAIN_FILE=../../Toolchain-arm.cmake  ..


Is that Cmake tries to run testCCompiler.cc , but it uses the Cygwin
absolute path to this file and fails.

As a result my compiler errors out saying


/cygdrive/c/intelFPGA/16.1/embedded/ds-5/sw/gcc/bin/arm-linux-gnueabihf-gcc
  -o CMakeFiles/cmTC_05821.dir/testCCompiler.c.obj -c

/home/JDamon/device-mcb-apps/mavcore/build/CMakeFiles/CMakeTmp/testCCompiler.c


  arm-linux-gnueabihf-gcc.exe: error:

/home/JDamon/device-mcb-apps/mavcore/build/CMakeFiles/CMakeTmp/testCCompiler.c:
  No such file or directory  #< This is the indicator that it doesn't like
Cygwin paths.


You can verify this very easily just by creating a simple hello_world.c and
run the compiler with the absolute path to that file.



How can I get past this compiler check ?



2. Is there a way to force Cmake to use relative file names or Native file
names  ( something like TO_NATIVE_PATH ) when when performing the regular
compilation ? I ask this because I already ran into the problem porting the
manual Makefile from Linux to Cygwin and  expressions like   $(CC)
-I/absolute/path/to/file  ( rest of the line )  all failed because the
compiler cannot handle the Cygwin paths.



Thanks,

-Jimi
--

-- 
WARNING - This e-mail or its attachments may contain controlled technical 
data or controlled technology within the definition of the International 
Traffic in Arms Regulations (ITAR) or Export Administration Regulations 
(EAR), and are subject to the export control laws of the U.S. Government. 
Transfer of this data or technology by any means to a foreign person, 
whether in the United States or abroad, without an export license or other 
approval from the U.S. Government, is prohibited. The information contained 
in this document is CONFIDENTIAL and property of ACCES I/O Products, Inc. 
Any unauthorized review, use, disclosure or distribution is prohibited 
without express written consent of ACCES I/O Products, Inc. If you are not 
the intended recipient, please contact the sender and destroy all copies of 
the original message and enclosed attachments.
-- 

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] file(TO_NATIVE_PATH ... ) and cross-compiling

[Stephen McDowell]

Disclaimer: I cannot speak to intent, and have never used these before.

So since you’re cross compiling, when looking at the docs ( 
https://cmake.org/cmake/help/v3.0/command/file.html 
 ), I think you can get 
away with using TO_CMAKE_PATH.  I do not know how you actually determine this, 
but the idea would be

if (CMAKE_CROSSCOMPILING)
  if (… host is windows …)
  if (… target is unix …)
… use TO_CMAKE_PATH …
  else()
… use TO_NATIVE_PATH …
  endif()
  else() # … host is unix …
if (… target is unix …)
  … use TO_CMAKE_PATH or TO_NATIVE_PATH …
else() # … target is windows
  … PROBLEM …
endif()
endif()

That is, I think if you are compiling on Windows for Unix, you can cheat and 
use TO_CMAKE_PATH to get unix style paths.  But if you are compiling on unix 
for Windows, I don’t know how you get it to be Windows paths.

But if this does solve Windows -> Unix, you could maybe just 
message(FATAL_ERROR …) saying that cross compiling for Windows from Unix is not 
supported.  You could also take a look at the implementation of TO_NATIVE_PATH 
and just snag the Windows code and make your own function that converts it, 
maybe calling it to_windows_path() or something?

I hope that is helpful, but I really don’t know if anything in the above is 
possible :/

-- 

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] Advice on how to remove duplicated code for object and interface library setup

[Stephen McDowell]

Hi Deniz,

Thanks for the response!  I tested it out and it seems to work exactly as you 
describe :)

I don’t want to depend on an un-released version of CMake though.  The original 
desire is because I kept making mistakes / adding definitions for one and not 
the other (code duplication at its finest…).

I discovered that I can populate one, e.g. only modify mylib_obj and then later 
grab these properties to add to the interface:

get_target_property(MYLIB_OBJ_INTERFACE_COMPILE_DEFINITIONS mylib_obj 
INTERFACE_COMPILE_DEFINITIONS)

and also the same for INTERFACE_COMPILE_OPTIONS etc. (Note: for anybody reading 
this, understand that INTERFACE_COMPILE_DEFINITIONS is desired here, 
COMPILE_DEFINITIONS includes private items which I do not want in this case).

Is getting the properties and then later setting them a reasonable solution 
here, or is this a bad idea?

-Stephen

-- 

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] Choosing SSE / AVX Flag Advice

[Stephen McDowell]

Hello,

I was originally using -march=native for non-windows, but in my attempts to 
support embedded architectures learned that this flag is broken and/or does 
nothing for many compilers (fixed for ARM in gcc 8 I think though).  Enter the 
glorious work of the folks at Vc: 
https://github.com/VcDevel/Vc/blob/master/cmake/OptimizeForArchitecture.cmake 


It’s quite comprehensive, and though it may not be ready for cross-compiling 
(still testing that, but I have to learn how to cross compile first!), it does 
appear to support native optimizations for embedded architectures.  Here is my 
concern, the following flags are generated:

-march=haswell;-msse2;-msse3;-mssse3;-msse4.1;-msse4.2;-mavx;-mfma;-mbmi2;-mavx2;-mno-sse4a;-mno-xop;-mno-fma4;-mno-avx512f;-mno-avx512vl;-mno-avx512pf;-mno-avx512er;-mno-avx512cd;-mno-avx512dq;-mno-avx512bw

I am concerned only because these flags will be a part of the PUBLIC compile 
features of a library, Eigen is the main math library backend as well as there 
are some templated image conversion routines that use SSE2 intrinsics to 
operate in my library.  Having that many additional flags could ultimately lead 
to undesirable consequences such as command line arguments being too long?

I’m currently reworking it so that just the highest version (e.g. -mavx2) is 
used, but I’m not sure if I should even be worried about this.

Thanks for any thoughts!

-Stephen

-- 

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] file(TO_NATIVE_PATH ... ) and cross-compiling

[Miroslav Keš]

Hi!

I have question concerning the file(TO_NATIVE_PATH ...) behavior.
The documentation says: "The TO_NATIVE_PATH mode converts a cmake-style  
into a native path with platform-specific slashes (\ on Windows and / 
elsewhere)."
 ... but it doesn't say if the decision is made based on the CMAKE_SYSTEM_NAME 
or the CMAKE_HOST_SYSTEM_NAME variable.

I have a project that builds the code for multiple platforms. The conversion 
works OK when building for Linux on Linux host or when building for Windows on 
a Windows host.
But if I cross-compile on a Windows for a non-Windows platform, the 
file(TO_NATIVE_PATH ...) converts paths to the target "non Windows" platform 
convention.
Is this the expected behavior?
I was going to use it when calling external programs on the build host (e.g. to 
generate Doxygen config file from a template using configure_file() ). But it 
doesn't work because of the target host path convention output.

Thanks.

Mira
-- 

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] should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

[Stephen McDowell]

Hi Mario,

Do you get different results if you set CMAKE_MODULE_PATH rather than 
CMAKE_PREFIX_PATH?  I wrote a tutorial for how to install a library called 
librealsense, at the very bottom is what will interest you:

https://gist.github.com/svenevs/f00ed3898d2af6248921b63254aa8cc1#enable-librealsense-for-other-cmake-projects
 


# Allow for `find_package(realsense2)` in CMake projects
export 
CMAKE_MODULE_PATH="/opt/librealsense/lib/cmake${CMAKE_MODULE_PATH:+:${CMAKE_MODULE_PATH}}"

This environment variable can either be set, or specified like you are doing 
with cmake .. -DCMAKE_MODULE_PATH=“/data/thirdparty”, noting that depending on 
where it got installed you may also need an extra lib on that path

/data/thirdparty/lib

I’m sure others on this list know the “right” practice, but when 
CMAKE_INSTALL_PREFIX=/usr/local, it’s very common to see two possible install 
locations:

/usr/local/cmake
/usr/local/lib/cmake

AKA just make sure that the zlib folder is a child directory.  In the 
librealsense2 example, I have

$ ls /opt/librealsense2/lib/cmake/
realsense2/

So since /opt/librealsense2/lib/cmake is in my CMAKE_MODULE_PATH, when I do 
find_package(realsense2), it will find that directory.

I don’t know exactly what Zlib’s install looks like, and I know it matters 
whether they are using “new” or “old” cmake installation tactics, but hopefully 
this gets you closer to solving it!

-Stephen

-- 

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] should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

[Mario Emmenlauer]

Dear All,

I use find_package(ZLIB) to detect zlib on Ubuntu 16.04 Linux.
I have a newer zlib in /data/thirdparty that I'd like to use. To
prefer my newer version I add -DCMAKE_PREFIX_PATH="/data/thirdparty".
In my understanding, the documentation says CMAKE_PREFIX_PATH is
searched first (1). But cmake behaves different than I'd expect:

It detects the system zlib first:

-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.8")

And then complains that zlib exists twice:

CMake Warning at CMakeLists.txt:693 (add_library):
  Cannot generate a safe runtime search path for target bdaimage because
  files in some directories may conflict with libraries in implicit
  directories:
runtime library [libz.so.1] in /usr/lib/x86_64-linux-gnu may be hidden by 
files in:
  /data/thirdparty/lib
  Some of these libraries may not be found correctly.

Why am I misunderstanding the documentation? Is CMAKE_PREFIX_PATH
not preferred over system directories?

All the best,

Mario Emmenlauer


(1) https://cmake.org/cmake/help/v3.0/command/find_package.html



--
BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
D-81669 München  http://www.biodataanalysis.de/
-- 

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] find_package() for static only / shared only

[Mario Emmenlauer]

I've googled this issue for a while now but found only few
references (1,2) and no solution. I'd like to enforce that
find_package() will only accept static or shared libraries.
I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF).

I.e. I'd love to have something like:
if(BUILD_SHARED_LIBS)
BUILD_TYPE="SHARED"
else()
BUILD_TYPE="STATIC"
endif()
find_package(XXX ${BUILD_TYPE})
find_package(YYY ${BUILD_TYPE})
find_package(ZZZ ${BUILD_TYPE})
...


It seems that this does not exist? I could also not find a
good workaround. The best I can find is to use 'NAMES' and
add the static or shared library names manually.

This is not very suitable, because I have a project with more
than 30 dependencies. The project should either build (fully)
static or (fully) shared. I can not easily maintain lists of
30 static and shared library names on several platforms.

Is there a solution or good workaround?

All the best,

Mario Emmenlauer


(1) https://cmake.org/pipermail/cmake/2012-September/052059.html
(2) https://cmake.org/pipermail/cmake/2010-December/041326.html


--
BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
D-81669 München  http://www.biodataanalysis.de/
-- 

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