Re: [CMake] [cmake-developers] libc++ usage in CMake with Clang?

[Stephen McDowell]

Hello,

I wanted to revisit this topic.  Craig gave a great answer for using
add_{compile,link}_options which mostly answers the question -- this is the
most modern way at this time.

However, I believe that CMake would really benefit from standardizing
this.  For example, CMAKE_CXX_STL_TYPE.  I would argue that this should
also be a public "compile feature" in some form, so that it propagates to
consuming targets.

Some projects I work with do what Craig suggested and when Clang is
detected, default to using libc++ and also usually libc++-abi.  While kind
of nice, it's mostly annoying to me.  You're forcing an incompatible ABI on
me for Linux, when there's no reason to.  If I want to install to /usr/local
and use this with other dependencies say from my package manager installs,
I cannot because libc++ and libstdc++ are not compatible.  Instead of
asking projects to do some kind of option(MYLIB_USE_LIBCXX ...) and do
their own detection logic, setting the default to ON when Clang is the
compiler or whatever, if CMake supports this natively it would be a great
feature.

For example, I can compile with clang and use libstdc++ on Linux no
problem.  Similarly, when compiling with gcc, I *can* also use libc++
(assuming it's installed of course).  A rough prototype of the values
accepted (modelled after the android module):

- gnustl_shared (GNU libstdc++ shared)
- gnustl_static (GNU libstdc++ static)
- c++_shared (LLVM libc++ shared)
- c++_shared (LLVM libc++ static)
- c++_abi_shared (LLVM libc++-abi sharedi)
- c++_abi_static (LLVM libc++-abi static)

Where I do not have answers is how to make libc++ and libc++-abi more
ubiquitous.  As far as I know (which is not very far), libc++-abi cannot be
used unless you are also using libc++.  So I guess c++_abi_shared implies
c++_abi?

What about default values?

Linux: gnustl_shared seems like a reasonable choice, regardless of compiler
(e.g., don't always default to libc++ with clang [???]).
MacOS: ???
Windows: ???

I don't feel there is an immediate need for this, but long term I think
having CMAKE_CXX_STL_TYPE as well as a compile feature cxx_stl_type would
be really useful.  I started looking at possible implementation (hence the
long pause here), but ultimately gave up because I always try and implement
things for CMake that are beyond my capabilities of doing correctly.

Just soliciting feedback as to what people think about having this kind of
cmake-level STL type support, especially with respect to choosing defaults,
and in extra-specific case of Windows, ummm, what to do in general.

-Stephen

P.S. I think if CMAKE_CROSSCOMPILING is set then if the user sets either
CMAKE_CXX_STL_TYPE or cxx_stl_type this should be an error (informing them
to possibly instead set CMAKE_ANDROID_STL_TYPE if applicable)?  I don't
know what to do about cross compiling in general, but an agreement should
be reached on what to do when these proposed new variable / features are
used in conjunction with cross compiling.


On Wed, Aug 22, 2018 at 2:05 AM, Craig Scott 
wrote:

>
>
> On Wed, Aug 22, 2018 at 1:39 PM, Ian Henriksen  gmail.com> wrote:
>
>>
>>
>> On Tue, Aug 21, 2018 at 6:40 PM Craig Scott 
>> wrote:
>>
>>>
>>> On Wed, Aug 22, 2018 at 7:18 AM, Robert Dailey >> > wrote:
>>>
 On Tue, Aug 21, 2018 at 3:47 PM Craig Scott 
 wrote:
 > Excuse the brevity, but it sounds like you might be looking for the
 CXX_EXTENSIONS target property (sorry if I've misunderstood your problem,
 let me know why it isn't appropriate if so). See the following article for
 a more complete overview of this and related properties:
 >
 > https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/

 Unfortunately that's not the same. Extensions manage C++ language
 features and STL capabilities, but -stdlib is for selecting an STL
 implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++
 to clang).

>>>
>>> Sorry, yes I misunderstood your problem. After a little digging, it
>>> seems like you probably shouldn't be using the -stdlib option on Linux
>>>  anyway. FWIW, for
>>> Android, the roadmap
>>> 
>>> is converging on a single STL implementation too.
>>>
>>
>> All that first link says is that -stdlib is a flag that is specific to
>> clang and that it shouldn't be used with gcc. You can use clang on Linux
>> with either libstdc++ or libc++. I often use libc++ on Linux by setting
>> CMAKE_CXX_FLAGS on the command line, though I'll admit that for me it's
>> usually just to check if problems that come up are OS dependent, compiler
>> dependent, or standard library dependent. You have to be careful since
>> libstdc++ and libc++ have incompatible ABIs, but it's a useful feature.
>> That said, I have no idea if specifying the standard library implementation
>> merits handling at the CMake level since only clang supports switching

[CMake] Relation Between CMP0074 and Installed Config Files

[Stephen McDowell]

Hello,

I am on the task force for modernizing the CMake build system of a large
project, the Point Cloud Library (PCL).  Satisfying policy CMP0074 [1] has
us somewhat confused about what we should be doing.

At *build time*, we understand.  Our numerous FindStuff.cmake modules (some
of which we will be removing, e.g., Eigen, some we cannot, e.g.,
libusb-1.0) should be checked and verified that when finding paths /
libraries, we need to verify that we also check both ${Package_ROOT} and
$ENV{Package_ROOT} in the search paths.  This makes sense and is relatively
straightforward to check for each of our Find modules.

Where we are confused is about PCLConfig.cmake [2].  Ignoring the fact that
the file needs some love in general, the current scheme needs modification
to fully satisfy CMP0074.  Choosing an arbitrary example, here is what is
done for qhull

macro(find_qhull)
  if(PCL_ALL_IN_ONE_INSTALLER)
set(QHULL_ROOT "${PCL_ROOT}/3rdParty/Qhull")
  elseif(NOT QHULL_ROOT)
get_filename_component(QHULL_ROOT "@QHULL_INCLUDE_DIRS@" PATH)
  endif(PCL_ALL_IN_ONE_INSTALLER)

  set(QHULL_USE_STATIC @QHULL_USE_STATIC@)
  find_package(Qhull)
endmacro(find_qhull)

When considering the usage of this in a consuming project that issues
a find_package(PCL
X.Y.Z REQUIRED), the motivation behind this approach was to help facilitate
that the library path that was used when PCL was built will be recovered,
unless the consuming project defines / is configured with
-DQHULL_ROOT=/some/path.  In other words, the scheme here was created to
make sure that the same dependencies that were found when *compiling* PCL
are found when *using* PCL.

I asked about this on the cpplang slack, and one of the cmake devs (whose
word I generally follow blindly without question xD) told me this

> basically provide the necessary find modules themselves, but don't cache
the results of your find calls when installing.

AKA instead of renaming these variables e.g. QHULL_ROOT -> PCL_QHULL_ROOT
to satisfy CMP0074, we should delete them.  The conversation was brief and
I did not include much context, but I am wondering if people here could
share their thoughts on this.

(a) Why is providing measures to make sure the same libraries used at
compilation of PCL are the same ones found when using PCL bad?
(b) Even if we create proper imported interface libraries to do
target_link_libraries(pcl
PUBLIC qhull::qhull), this will not help us in terms of installation -- the
find modules still need to be installed / called in PCLConfig.cmake, right?
(c) Since we need to more carefully analyze our project with respect to
CMP0074, is it advisable to set it to OLD for the imminent release?  The
release will go out before we have time to properly update our CMake code
for this policy, and we want to make sure that setting it to OLD (rather
than just *not* setting it to NEW) is the correct approach *for this
release only*.

Thank you for any insights!

[1]: https://cmake.org/cmake/help/latest/policy/CMP0074.html

[2]: https://github.com/PointCloudLibrary/pcl/blob/master/PCLConfig.cmake.in

P.S. To the original advisor who told me not to cache the results, I
apologize in advance for having the audacity to doubt your infinite CMake
wisdom.  I don't understand why caching the results for installation is bad
/ what can go wrong by this, and would like to ;)
-- 

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] libc++ usage in CMake with Clang?

[Stephen McDowell]

Good question. The only official thing I could find that is _somewhat_
related is this:
https://cmake.org/cmake/help/latest/variable/CMAKE_ANDROID_STL_TYPE.html#variable:CMAKE_ANDROID_STL_TYPE

Doesn't really help if you aren't targeting Android though

On Mon, Aug 20, 2018, 10:48 AM Robert Dailey 
wrote:

> Is the only way to use libc++ to muck with compile flags? Or is there
> a proper find module for this or something? Is there a more
> CMake-esque way of specifying the STL library to use with the
> toolchain?
> --
>
> 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] CMAKE doesn't pass NVCC flags?

[Stephen McDowell]

I think you are mixing old and new approaches. Since you have enabled the
CUDA language (via your project(...) call), you should be using either
CUDAFLAGS or CMAKE_CUDA_FLAGS.

I think CUDA_NVCC_FLAGS is only used for the old cuda_add_library or
executable functions.

Note that finding the cuda package should no longer be necessary. If you
support non-CUDA builds you should use CheckLanguage and
enable_language(CUDA), and remove CUDA from the project(...) call.
Currently if nvcc is not found, configuration will fail because you have
CUDA in the project command which makes it required.

Hope that helps!

-Stephen

On Tue, Jul 24, 2018, 1:48 PM Quang Ha  wrote:

> So, it doesn't seem that my setting in NVCC flags is being used:
>
> In CMakeLists.txt:
>
> project(tangram LANGUAGES CXX CUDA)
> [...]
>
> FIND_PACKAGE(CUDA REQUIRED)
> if(CUDA_FOUND)
>   add_definitions(-DCUDA_CALLABLE="__host__ __device__")
>   set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};-Xcompiler="-fopenmp -fPIC")
>   set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--std=c++11
> --expt-relaxed-constexpr)
>   set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};-gencode
> arch=compute_70,code=sm_70)
>   set(CUDA_PROPAGATE_HOST_FLAGS ON)
>   set(CUDA_SEPARABLE_COMPILATION OFF)
>   message(STATUS "CUDA include directories ${CUDA_INCLUDE_DIRS}")
>   message(STATUS "Overwriting THRUST_DIR to point to
> ${CUDA_INCLUDE_DIRS}/thrust")
>   set(THRUST_DIR "${CUDA_INCLUDE_DIRS}")
>   set(EXTRA_LIBS ${CUDA_LIBRARIES})
>   message("CUDA flags" ${CUDA_NVCC_FLAGS})
> else(CUDA_FOUND)
>   message(FATAL "CUDA not found")
> endif(CUDA_FOUND)
> [...]
>
> Then, at cmake stage:
> [...]
> -- Overwriting THRUST_DIR to point to
> /projects/opt/centos7/cuda/9.0/include/thrust
> CUDA flags-Xcompiler="-fopenmp
> -fPIC"--std=c++11--expt-relaxed-constexpr-gencodearch=compute_70,code=sm_70
> -- Adding application directory app
> [...]
>
> But then, build fail, and when I do make VERBOSE=1:
> [...]
> [ 60%] Building CUDA object
> app/simple-vfgen-cuda/CMakeFiles/simple-vfgen-cuda.dir/simple-vfgen-cuda.cu.o
> cd /home/qth20/develop/tangram/build/app/simple-vfgen-cuda &&
> /projects/opt/centos7/cuda/9.0/bin/nvcc  -DCUDA_CALLABLE="\"__host__
> __device__\"" -DHAVE_LAPACKE -DTHRUST
> -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA
> -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP -I/home/qth20/develop/tangram
> -I/home/qth20/develop/tangram/build
> -I/home/qth20/develop/tangram/cinch/logging
> -I/home/qth20/installed/jali/include
> -I/home/qth20/installed/jali-tpls/include
> -I/home/qth20/installed/jali-tpls/trilinos-12-10-1/include
> -I/projects/opt/centos7/openmpi/3.1.0-gcc_8.1.0/include
> -I/home/qth20/installed/jali-tpls/trilinos-12-10-1/lib/cmake/Zoltan/../../../include
> -I/home/qth20/installed/jali-tpls/include/UnitTest++ -I/usr/include/lapacke
> -I/home/qth20/installed/xmof2d/include
> -I/projects/opt/centos7/cuda/9.0/include  -O3 -DNDEBUG   -std=c++11 -x cu
> -c /home/qth20/develop/tangram/app/simple-vfgen-cuda/simple-vfgen-cuda.cu
> -o CMakeFiles/simple-vfgen-cuda.dir/simple-vfgen-cuda.cu.o
> [...]
>
> None of the flags was passed into nvcc. This is with cmake/3.11.1. Does
> upgrading to 3.12 recommended to solve the issue?
>
> Thanks,
> Quang
> --
>
> 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] Packaging dylibs into app bundles

[Stephen McDowell]

Hi Harry,

I don't know how useful this will be, but the Instant Meshes application
creates an app bundle that has always worked reliably for me. Looking at
the code, it doesn't appear like there's much custom stuff going on either.
It starts here

https://github.com/wjakob/instant-meshes/blob/011fa44ab72037cbc16535090a63ead41963c1e5/CMakeLists.txt#L151

And there's an if APPLE block below that appears to be the core.

Hope that is useful :) I've never actually done this for any of my own
projects though. And I'm pretty sure them setting the underlying GUI
library and TBB to be static (as opposed to shared) is skirting around the
issue that you are trying to solve (dylib stuff)...

-Stephen

On Thu, Jul 19, 2018, 9:03 AM Harry Mallon 
wrote:

> Hello all,
>
>
>
> Is there a good tutorial/article on getting CMake to package required
> dylibs and frameworks into an app bundle for you on mac. We have a lot of
> custom stuff to do it and it is fragile and breaks a lot.
>
>
>
> Thanks,
>
> Harry
>
> Harry Mallon
>
> Senior Software Engineer
>
> 
>
> T +44 203 7000 989 
>
> 60 Poland Street | London | England | W1F 7NT
> Three Billboards Blade Runner 2049  I, Tonya
>
> --
>
> 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] specifying path for license file for commercial compiler?

[Stephen McDowell]

I agree that a toolchain file is more appropriate, noting that typically
modifying the environment variables is much more common for there's
compilers (particularly using environment modules).

However, since you've started clearly you would rather not set the
environment variables, there may be an easier "hack".

Intel also looks in /opt/intel/licenses for any .lic files. So if you want,
you can just create a symbolic link or copy your license file there :)

On Fri, Jul 6, 2018, 10:49 PM Marc CHEVRIER  wrote:

> May be using a toolchain file is more appropriate. See
> https://cmake.org/cmake/help/v3.12/manual/cmake-toolchains.7.html
>
>
> Le ven. 6 juil. 2018 à 22:59, Clune, Thomas L. (GSFC-6101) <
> thomas.l.cl...@nasa.gov> a écrit :
>
>> To use the Intel compiler, one must use an environment variable that
>> specifies the path to the license file.  E.g.,
>>
>> export INTEL_LICENSE_FILE=/usr/local/intel/license
>>
>> Other commercial compilers use a very similar mechanism.I had hoped
>> to capture such information in a cache file so that I could avoid polluting
>> the shell where I am invoking cmake:
>>
>> % cmake -C my-cache 
>>
>> Such a cache file could  look like:
>>
>> set(CMAKE_Fortran_COMPILER
>> "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort"
>> CACHE path "Fortran compiler")
>> set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path
>> "Intel license")
>>
>>
>> Unfortunately, the compiler is not “seeing” the env variable and
>> complains that there is no license. Is there a solution to this, or am
>> I forced to set the env variable each time I try to build?
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> 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
>
-- 

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] Spaces in conditional output of generator expressions

[Stephen McDowell]

It should be a CMake list, which is delineated by semicolons.

add_compile_options($<$-Wall;-Wextra>)

I am writing this from a phone so untested, but that has worked for me in
the past.

-Stephen


On Sat, Jun 2, 2018, 3:47 PM Neil Carlson  wrote:

> I'm attempting to use a generator expression to conditionally add compile
> options. No problem if it is a single option, but I can't figure out how to
> manage multiple options (in a single command).
>
> For example, this works:
> add_compile_options($<$-Wall>)
>
> As does this:
> add_compile_options(-Wall -Wextra)
>
> But not this:
> add_compile_options($<$-Wall -Wextra>)
>
> Nor this:
> add_compile_options($<$"-Wall -Wextra">)
>
> Or any other variation I could think of.  Either the space breaks the
> generator expression, or I get a quoted version of the options that the
> compiler sees as a single "option" it doesn't understand.
>
> Is there some way of doing this?
>
> PS: I'm trying to avoid using CMAKE_C_FLAGS. My understanding is that
> variable is meant for the end user's use.  Am I mistaken about that?
>
> --
>
> 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] advice for resolving errors with CMake 3.8

[Stephen McDowell]

If you don't want to have to keep switching to Windows and back to test,
the most reliable way to know with absolute certainty is to install CMake
3.8 on OSX and use that.

Fortunately building cmake is actually quite easy, you can even use the
newer cmake from brew to configure the older one (use cmake to build
cmake!).

Make sure you set CMAKE_INSTALL_PREFIX to somewhere you know about (e.g.
/opt/cmake-3.8). When you need to test this project, update your path to
point there

export PATH="/opt/cmake-3.8/bin:$PATH"

You need to run that export command for every terminal, or put it in your
~/.bashrc while developing this project.

If you don't set CMAKE_INSTAL_PREFIX, `make install` will put it in
/usr/local by default which will make it more challenging to uninstall in
the future when you want to use cmake 3.11 from brew. Putting it in /opt
makes it so you can just delete that entire /opt/cmake-3.8 folder and/or
comment out the export command in your ~/.bashrc (making sure to launch a
new terminal and verify cmake --version after editing your ~/.bashrc).
-- 

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] Help Accommodating Ninja when including CMAKE_CURRENT_BINARY_DIR

[Stephen McDowell]

​After much deliberation, I was never successful in getting a synthetic
target to work as expected.  The dilemma is that `add_custom_command`
cannot specify both `TARGET` and `OUTPUT`, the work flow was something like

add_custom_target(resource-dependency)
add_custom_command(TARGET resource-dependency ... PRE_BUILD)
add_custom_command(OUTPUT  DEPENDS
resource-dependency)
...
add_library(actual-obj-library OBJECt  ... others
...)
add_dependencies(actual-obj-library resource-dependency)

I'm sure that's a flawed approach, but in the end I realized I can actually
generate these files at *configure* time <3  The add_custom_command was
just a call to ${CMAKE_COMMAND} ... resources/bin2c.cmake.  So in the end,
it's actually a lot cleaner for us to just include(resources/bin2c.cmake).

I doubt this solution will be widely applicable to many projects, but if
you ever find yourself in a situation where you are doing
add_custom_command, where the custom command is calling ${CMAKE_COMMAND},
don't rely on PRE_BUILD because it's not a guarantee.  If you can, just
execute the script at configure time via an include(...) call.
-- 

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] Help Accommodating Ninja when including CMAKE_CURRENT_BINARY_DIR

[Stephen McDowell]

Upon further inspection, it seems more related to PRE_BUILD.  The step to 
generating the files is through a add_custom_command call, which from the docs 
apparently may end up being PRE_LINK.

I tried generating into the ${CMAKE_CURRENT_SOURCE}/include/nanogui, which will 
work for Makefiles but not for Ninja.

So it seems that maybe this is not a pathing issue at all, but instead an order 
of operations issue.  If the Ninja generator ends up having this as PRE_LINK, 
the files haven’t been generated yet.

That doesn’t quite explain why it worked previously, but perhaps the original 
setup was inherently flawed by relying on PRE_BUILD which is not a guaranteed 
order.

Does anybody have thoughts on how to change things?  The files cannot be 
compiled on their own, but maybe I should instead create a fake target and make 
it a dependency of the real (object) library that needs them.  I keep messing 
that up, but this seems the most promising.

-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] Help Accommodating Ninja when including CMAKE_CURRENT_BINARY_DIR

[Stephen McDowell]

Hello,

I have looked around and seen a few issues discussing this, but have not seen 
any solutions.

It seems related to this: https://gitlab.kitware.com/cmake/cmake/issues/17450 


In the sense that absolute paths are desired.

1. Previously, we were generating a file called 
`${CMAKE_CURRENT_BINARY_DIR}/nanogui_resources.h` and performing 
`include_directories(${CMAKE_CURRENT_BINARY_DIR})`.

This **works correctly**.

2. The setup was changed to generate the file 
`${CMAKE_CURRENT_BINARY_DIR}/nanogui/resources.h`.  That is, the introduction 
of a new folder `nanogui`.  With the same 
`include_directories(${CMAKE_CURRENT_BINARY_DIR})`, there is now a failure 
being unable to find ``.

Strangely, building with `ninja || ninja` (just building again after first 
failure) will succeed.

I was reading this discussion: 
https://public.kitware.com/pipermail/cmake-developers/2013-March/018398.html 


and the underlying cause seems to be the that Ninja wants relative paths.

Why is creating this sub-directory causing this issue?  Is there a way to keep 
generating ${CMAKE_CURRENT_BINARY_DIR}/nanogui and be able to include it with 
Ninja?  I tried forcing a add_definitions(-I${CMAKE_CURRENT_BINARY_DIR}) just 
for shiggles, but that resulted in the same scenario.  So it seems like I need 
a way to force a verbatim include path “after” the Ninja generator makes things 
relative?

Reverting to the old version is not ideal, since it creates installation 
problems (the reason the subdirectory nanogui was created).

Thank you for any advice!

-Stephen

P.S. This is with CMake 3.11.1 and ninja 1.8.2 if it matters.

-- 

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] How to build CMake so it works on an older Linux?

[Stephen McDowell]

Hi Suzuki,

(Note: to other CMake mailing list readers, this pertains very little to CMake 
itself.  I’m sending it to the mailing list so that future users with this 
issue may also have a possible solution).

Getting a newer version of GCC is quite challenging by yourself indeed, but you 
may be interested in the Spack package manager: 
http://spack.readthedocs.io/en/latest/getting_started.html 


It’s designed for high performance computing, but has a special emphasis on 
supporting older distributions (since updating HPC cluster operating systems is 
the devil).

Some quick tips:

1. Once you start installing things, you cannot move the spack directory.  So 
decide where you want it and clone it there.  For example, I keep all of my 
installations in /opt/spack

cd /opt
sudo git clone https://github.com/spack/spack.git

Assuming you are `user` on this system (echo $USER)
sudo chown -R user spack/

Then proceed with the getting started tutorial.

2. You have many possible newer versions of GCC available, by default `spack 
install gcc` installs the newest one.  Run `spack info gcc` to see the versions 
available.  Suppose you installed gcc@6.4.0 (which will as you know take a 
while).  You will want to make this available as a compiler, so you `spack load 
gcc@6.4.0` (it might tell you to source a script, so do that) and run `spack 
compiler find`.  When `spack compiler list` shows your shiny new GCC compiler, 
you can now `spack install cmake %gcc@6.4.0` to use GCC 6.4.0 to compile Cmake! 
 Note you don’t need to install GCC 6.4.0, that was purely an example.  I know 
there have been some issues with really old GCC versions compiling newer 
versions, but I think we fixed the underlying problem that caused that.  AKA my 
hope is this works seamlessly, but you may run into trouble.  If you do, you 
might try installing an older version of GCC (in this example, say 6.4.0 didn’t 
work, maybe try GCC 5.5.0).

I hope this is helpful for you!  There’s a lot more to spack, but if you get 
stuck raise an issue on GitHub.  The spack user community is very helpful and 
friendly to newcomers :)

Good luck!

-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

Re: [CMake] CMake Version Specific Code and Testing

[Stephen McDowell]

Ok cool thank you for explaining!  Somewhat related, I really enjoy that I can 
build CMake 2.8.12 with CMake 3.10 :)


-- 

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] CMake Version Specific Code and Testing

[Stephen McDowell]

Hello,

Suppose I have a cmake_minimum_required(VERSION 2.8.12) project I would like to 
contribute to.

So when I am testing code for a v2.8.12 project, but my installed CMake version 
is say 3.10, if I (accidentally, or through ignorance) write code that would 
only work in CMake 3.x but not in 2.8.12, will the build fail or should I make 
sure to install 2.8.12 and test using that?

For example, my understanding is that for things like policies, I can do

if (POLICY CMP)
  cmake_policy(SET CMP NEW)
endif()

and this will mean that an older version of CMake running this code that does 
not know about policy  will still work.  But if I ended up using an 
entirely new command that did not exist at the time of 2.8.12, but does exist 
in 3.10 of my installed CMake, should the build fail or succeed?

Thanks for any guidance, I’m sorry if this question doesn’t make any sense…

-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

Re: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

[Stephen McDowell]

That’s progress though? :)

Hmmm.  I understand your problem now, but I don’t know how to fix it.  You can 
do things like

   find_package(ZLIB NO_DEFAULT_PATH)

That makes it so the system Zlib won’t be found, but I couldn’t then get `cmake 
.. -DZLIB_ROOT=xxx` to work :/  There are other NO_* variables mentioned on 
that page too, maybe one of those and setting CMAKE_PREFIX_PATH could work?  
I’m not familiar with these path variables in 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] should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

[Stephen McDowell]

Hi Mario,

Very sorry, I should have looked more closely!  CMAKE_MODULE_PATH is for 
libraries that install their own CMake scripts.  You are correct, Zlib only 
installs a pkg-config script.  However, FindZLIB.cmake doesn’t appear to use 
that at all (aka I don’t believe you need to be setting PKG_CONFIG_PATH).  You 
should be able to get away with setting ZLIB_ROOT.  So for you I think it would 
look like

cmake .. -DZLIB_ROOT=/data/thirdparty

FindZLIB.cmake will proceed to look for ZLIB_ROOT/include/zlib.h and look in 
ZLIB_ROOT/lib for the library.

The XXX_ROOT is typically available for any built-in CMake FindXXX.cmake 
modules (see hint at bottom: 
https://cmake.org/cmake/help/v3.0/module/FindZLIB.html 
 ).  These 
FindXXX.cmake modules are for this exact scenario: there is a library that many 
users want access to that does not install cmake scripts (typically because the 
library uses a different build system such as autotools).

- - - - -

If you are still having trouble, this is what I used to test this.  I didn’t 
actually write code that uses it, but I suspect if you remove setting of 
CMAKE_PREFIX_PATH (I think that’s where your conflict originates from) and just 
specify ZLIB_ROOT your problem will be solved (I hope!).

With a very crude CMakeLists.txt:

cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
project("find_zlib")

find_package(ZLIB)
if (ZLIB_FOUND)
  message(FATAL_ERROR "Found Zlib:\n- ZLIB_INCLUDE_DIRS: 
${ZLIB_INCLUDE_DIRS}\n- ZLIB_LIBRARIES: ${ZLIB_LIBRARIES}")
else()
  message(FATAL_ERROR "Did not find Zlib :/")
endif()

Without setting ZLIB_ROOT:

$ cmake ..
-- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.8")
CMake Error at CMakeLists.txt:6 (message):
  Found Zlib:
  - ZLIB_INCLUDE_DIRS: /usr/include
  - ZLIB_LIBRARIES: /usr/lib/libz.dylib

That’s the default Zlib that comes with OS X.  However, if I specify ZLIB_ROOT:

$ cmake .. -DZLIB_ROOT=/usr/local/Cellar/zlib/1.2.11/
-- Found ZLIB: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib (found version 
"1.2.11")
CMake Error at CMakeLists.txt:6 (message):
  Found Zlib:
  - ZLIB_INCLUDE_DIRS: /usr/local/Cellar/zlib/1.2.11/include
  - ZLIB_LIBRARIES: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib

Let us know if it works or if you still need help!

-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

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

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

Re: [CMake] Generator for Visual Studio Code (Ubuntu)

[Stephen McDowell]

You may also find this article useful, it seems to explain how to configure the 
JSON files you need to for more complicated build systems: 
https://medium.com/audelabs/c-development-using-visual-studio-code-cmake-and-lldb-d0f13d38c563
 


They were writing for Linux / OS X, and you’ll see that they’re just using 
cmake -G 'Unix Makefiles’ in their tasks.json.


-- 

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

[Stephen McDowell]

I am trying to obey modern CMake target-based practices, with a twist that 
everything is available as an OBJECT library if desired.  I have this working 
and can explain why if desired, but I feel it is extraneous for this question.  
What I create:

- mylib <- the main library
- mylib_obj <- contains all of the actual objects for the library (OBJECT 
library)
- mylib_interface <- linked with mylib

So it looks like this:

add_library(mylib_obj OBJECT "")
add_library(mylib_interface INTERFACE)

Based on various options / settings, target_sources(mylib_obj) will be set and 
all of the various compiler operations etc.  At the end, I have

# MYLIB_LIBRARY_TYPE is either SHARED or STATIC
add_library(mylib ${MYLIB_LIBRARY_TYPE} $)
target_link_libraries(mylib mylib_interface)

This works nicely, but internally I have to do the same operations for both 
mylib_obj and mylib_interface.

target_include_directories(mylib_obj PUBLIC ${SomeLib_INCLUDE_DIRS})
target_include_directories(mylib_interface INTERFACE 
${SomeLib_INCLUDE_DIRS})
target_link_libraries(mylib_interface INTERFACE ${SomeLib_LIBRARIES})

Without mylib_interface, I cannot include the future linking information as 
well as include / compiler directive information will not be propagated with 
target_link_libraries(something mylib).  But mylib_obj also needs include 
information, etc.  But I can’t do

target_link_libraries(mylib_obj mylib_interface)

because mylib_obj is an object library.

Is there a way to avoid having to set the same thing for both mylib_obj and 
mylib_interface given the requirement that mylib_obj is intended to house all 
of the actual objects?

Thank you for any guidance, I’m sorry if this question doesn’t make much sense. 
 I’m trying to unlearn all of my outdated self-taught CMake!

-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

Re: [CMake] Modern CMake + CUDA + Clang

[Stephen McDowell]

Whoops… sorry I replied to the mail server, please ignore this thread and let 
it die, see issue tracker linked in second post.

-- 

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] Modern CMake + CUDA + Clang

[Stephen McDowell]

Excellent, this is very useful — thanks Robert!

I think I have some answers to some of these, but as I make progress will 
probably reach out to the LLVM mailing lists for help / suggestions 
(particularly with separable compilation and device linking).

I’m still ramping up to speed on developing CMake.  You had mentioned 
CMake_TEST_CUDA which will be helpful down the line, but intermediately is it 
“ok” to just modify *.cmake modules in-place underneath the installed Modules 
and Modules/Compiler directories?  I’ve got a custom install / am not concerned 
about breaking things in it, I’m just wondering if this is a typical practice 
or if I should be re-compiling and re-installing every time I make changes.

-- 

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] Modern CMake + CUDA + Clang

[Stephen McDowell]

I found the GitLab tracker: https://gitlab.kitware.com/cmake/cmake/issues/16586 



-- 

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] Modern CMake + CUDA + Clang

[Stephen McDowell]

Hello!

I stumbled across the new 3.8+ CUDA as a language capabilities, and am very 
excited about this!

1. Does anybody know when CMAKE_CUDA_COMPILER_ID and 
CMAKE_CUDA_COMPILER_VERSION were fixed?

With cmake 3.9.4 some of the cuda compiler variables were unset:

   message("CXX compiler stuff:")
   message(STATUS "CMAKE_CXX_COMPILER: ${CMAKE_CXX_COMPILER}")
   message(STATUS "CMAKE_CXX_COMPILER_ID:  ${CMAKE_CXX_COMPILER_ID}")
   message(STATUS "CMAKE_CXX_COMPILER_VERSION: ${CMAKE_CXX_COMPILER_VERSION}")
   message("CUDA compiler stuff:")
   message(STATUS "CMAKE_CUDA_COMPILER: ${CMAKE_CUDA_COMPILER}")
   message(STATUS "CMAKE_CUDA_COMPILER_ID:  ${CMAKE_CUDA_COMPILER_ID}")
   message(STATUS "CMAKE_CUDA_COMPILER_VERSION: ${CMAKE_CUDA_COMPILER_VERSION}")
   message(FATAL_ERROR "bye bye")

CMAKE_CUDA_COMPILER was set, but COMPILER_ID and COMPILER_VERSION were not.  I 
just updated to 3.10.2 and they were giving values I would expect.  I dug 
around under the diffs on Modules but got really turned around.

I would like to set my minimum required version to whenever this was 
introduced, as I would like to wield it.

2. Is there any existing work / discussion on the new world order (CUDA as a 
full-fledged language) and Clang?  I noticed that the following happens:

   if(CMAKE_CUDA_COMPILER_ID)
 include(Compiler/${CMAKE_CUDA_COMPILER_ID}-CUDA OPTIONAL)
   endif()

leaving room for a Compiler/Clang-CUDA.cmake to be created.  Is there an 
eventual goal to write this?  I think I can maybe help get a prototype working 
if that was the goal for this setup.

3. Supposing CMake + Clang + CUDA was working, the working assumption would be 
that a user sets CUDACXX to clang++, right?  I’m trying to understand if Clang 
as a cuda compiler already works and I have bad local configurations, or if 
they are needing to be written.

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