[cmake-developers] FindCUDA: Clang/CUDA Support

[Huebl, Axel]

Hi everyone,


I was wondering if someone is already working on Clang/CUDA support for
the FindCUDA module.

With clang 3.8 the --cuda-arch and --cuda-path directives allow to
compile .cu files as an alternative to nvcc. Maybe we could just specify
a steering variable such as

  set(CUDA_COMPILE_CHAIN "clang")
  set(CUDA_COMPILE_CHAIN "nvcc")

before find_package(CUDA) to steer it (and of course adding the
implementation).

Alternatively,
  CUDA_HOST_COMPILER
and adding
  CUDA_DEVICE_COMPILER
  (or reusing the advanced CUDA_NVCC_EXECUTABLE)

might also be a way to go.

Currently, you still need to have the CUDA toolkit from Nvidia installed
to compile .cu files to ptx with clang, so I guess my question is really
just about replacing nvcc and it's options with clang (using different
options).

What do you think?


Best regards,
Axel Huebl
-- 

Axel Huebl
Phone +49 351 260 3582
https://www.hzdr.de/crp
Computational Radiation Physics
Laser Particle Acceleration Division
Helmholtz-Zentrum Dresden - Rossendorf e.V.

Bautzner Landstrasse 400, 01328 Dresden
POB 510119, D-01314 Dresden
Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey
  Prof. Dr.Dr.h.c. P. Joehnk
VR 1693 beim Amtsgericht Dresden



smime.p7s
Description: S/MIME Cryptographic 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-developers

Re: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL

[Charles Huet]

> This is per-target and is different than add_subdirectory
EXCLUDE_FROM_ALL.
We should still honor this.

Ok, done.

> The rules we're generating here could work like that too.  Each one
depends on all the targets defined in its own directory and on the
directory-level target for subdirectories.  The goal is to match the
Makefile generator behavior for target selection in each directory.
I don't think matching subdirectory name prefixes is needed for that.

Ah, yes, this makes a lot of sense. Now I feel a bit dumb for not going
this way in the first place.

> I think the names can instead use a "/all" suffix e.g. "sub/dir/all".
This would be consistent with the "ninja all" one can now do at the
top.

Sure, done.

If you have other ideas on how to improve this patch, I'll be happy to
implement them.
I've been using Cmake 3.5 with this added feature and I must say it's
pretty sweet for my use case.

Best

Le mar. 15 mars 2016 à 18:58, Brad King  a écrit :

> On 03/14/2016 05:04 AM, Charles Huet wrote:
> > I modified my patch a bit to use C++98 only, and try to stick
> > to the coding conventions.
>
> Thanks.  While reviewing the logic I realized my suggestion to include
> all targets was not quite consistent with my observation that this matches
> the Makefile generator "cd dir; make" behavior.  The latter still excludes
> targets that have the EXCLUDE_FROM_ALL target property, as seen by this
> code in cmGlobalUnixMakefileGenerator3::WriteDirectoryRule2:
>
> >  if((!check_all || !gtarget->GetPropertyAsBool("EXCLUDE_FROM_ALL")) &&
>
> This is per-target and is different than add_subdirectory EXCLUDE_FROM_ALL.
> We should still honor this.  Such targets are meant to be built only upon
> explicit request.  Also later in WriteDirectoryRule2 is this section:
>
> > // The directory-level rule should depend on the directory-level
> > // rules of the subdirectories.
>
> The rules we're generating here could work like that too.  Each one
> depends on all the targets defined in its own directory and on the
> directory-level target for subdirectories.  The goal is to match the
> Makefile generator behavior for target selection in each directory.
> I don't think matching subdirectory name prefixes is needed for that.
>
> > These targets are prefixed with "path/" in order to set them apart of
> > normal CMake targets.
>
> I think the names can instead use a "/all" suffix e.g. "sub/dir/all".
> This would be consistent with the "ninja all" one can now do at the
> top.
>
> Thanks,
> -Brad
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] find_package with NO_MODULE while cross-compiling

[Julien Schueller]

Oh, I did not see this one at all, thanks a lot Nils! 
Julien 

- Mail original -

> De: "Nils Gladitz" 
> À: "Julien Schueller" , "CMake Developers"
> 
> Envoyé: Mardi 15 Mars 2016 23:24:05
> Objet: Re: [cmake-developers] find_package with NO_MODULE while
> cross-compiling

> On 15.03.2016 23:01, Julien Schueller wrote:

> > Hi,
> 

> > When using find_package ( NO_MODULE) while cross-compiling,
> 
> > cmake may find an existing Config.cmake in the host root path if
> > Config.cmake is not available in the target root path.
> 

> > For example let's say that I have Qt5 project in my host Linux box, which
> > provides a /usr/lib/cmake/.../Qt5WidgetsConfig.cmake.
> 
> > In my cmake project I use: find_package (Qt5Widgets NO_MODULE), everything
> > goes as planned.
> 
> > Now I want to cross-compile using MinGW-w64, I install qt5 in my mingw
> > target
> > root, so I have a
> > /usr/i686-w64-mingw32/lib/cmake/.../Qt5WidgetsConfig.cmake
> 
> > I set CMAKE_FIND_ROOT_PATH to /usr/i686-w64-mingw32 and stuff via a
> > toolchain
> > file, and everything goes fine too.
> 
> > No if I remove the qt5 target package for mingw, or it is unavailable in
> > the
> > first place, cmake prefers the host qt5 config file, and the compilation
> > fails.
> 

> > I found a workaround, which is to not let cmake use host rules to find
> > Config.cmake in the case of cross-compiling:
> 
> > if (CMAKE_CROSSCOMPILING)
> 
> > set (NO_MODULE_ARGS NO_MODULE NO_SYSTEM_ENVIRONMENT_PATH
> > NO_CMAKE_SYSTEM_PATH)
> 
> > endif ()
> 
> > find_package (Qt5Widgets ${NO_MODULE_ARGS})
> 
> > Would there be a smarter way to do this instead of invading each CMakeLists
> > that uses a find_package relying on package-provided cmake configs ?
> 

> Setting
> https://cmake.org/cmake/help/v3.5/variable/CMAKE_FIND_ROOT_PATH_MODE_PACKAGE.html
> to ONLY in your toolchain file should prevent cmake from picking up native
> packages.

> Nils

-- 
Julien Schueller 
Phimeca Engineering 
www.phimeca.com 
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Patch to only consider build dependencies between files in the source directory

[Attila Krasznahorkay]

Hi Brad,

All valid points. Will try to make a new patch today.

Cheers,
   Attila

> On 15 Mar 2016, at 19:13, Brad King  wrote:
> 
> On 03/15/2016 10:48 AM, Attila Krasznahorkay wrote:
>> https://cmake.org/pipermail/cmake-developers/2015-December/027197.html
>> 
>> With the following patch, when setting the CMAKE_ONLY_IN_SOURCE_DEPENDENCIES
>> variable to 1/ON/TRUE, this file size goes down to just a few kilobytes.
>> Speeding up our build noticeably.
> 
> Thanks.  As Ben pointed out in the original thread the build tree should
> be included as well.  Perhaps a name like
> 
>  CMAKE_DEPENDS_IN_PROJECT_ONLY
> 
> could be used to indicate that it includes only dependencies in the project
> directories (source or build tree).
> 
>> As far as I can see, the "cmake -E cmake_depends" call is only used by
>> the Makefile generator at the moment. So I only taught that generator
>> about this new variable.
> 
> The Makefile generator is the only one for which CMake takes responsibility
> for implicit dependency scanning.
> 
>> I just didn't see what I should do in the Ninja generator for instance
>> to apply this setting. Even though I would be very interested in implementing
>> the feature in that generator as well.
> 
> The Ninja generator uses the compiler's information about dependencies
> as generated by options like `gcc -MD`.  Since that occurs along with
> the compilation there is little cost to including all dependencies
> except for stat during rebuilds.  See discussion here:
> 
>  https://cmake.org/Bug/view.php?id=14914
> 
> about the opposite use case (including system dependencies instead of
> excluding them).
> 
>> +  infoFileStream
>> +<< "set(CMAKE_ONLY_IN_SOURCE_DEPENDENCIES "
>> +<< ( this->Makefile->IsOn( "CMAKE_ONLY_IN_SOURCE_DEPENDENCIES" ) ?
>> + "1" : "0" )
>> +<< ")\n";
> 
> Rather than communicating this to the dependency scanning step and
> doing the filtering there, please look at applying the filter during
> generation of CMAKE__TARGET_INCLUDE_PATH.
> 
> Thanks,
> -Brad
> 

-- 

Powered by www.kitware.com

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

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

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

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

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