Re: [CMake] What is the default build type?

2017-07-31 Thread Michael Ellery


> On Jul 31, 2017, at 8:48 PM, Florian Lindner  wrote:
> 
> Hello
> 
> ccmake shows CMAKE_BUILD_TYPE as unset. From the compile commands it looks 
> like also nothing like Debug nor Release.
> 
> Why is there no well-defined default set? How can I set a default?
> 
> Thanks,
> Florian
> -- 
> 
> 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


my recollection is that an unspecified build type results in a build that has 
no optimizations and no debug symbols generated. I’m not sure what the 
motivation for those default flags is. If you want to default to DEBUG, 
something like this should work:

if (NOT CMAKE_BUILD_TYPE)
  set(CMAKE_BUILD_TYPE Debug)
endif()


-MIke

-- 

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] What is the default build type?

2017-07-31 Thread Florian Lindner
Hello

ccmake shows CMAKE_BUILD_TYPE as unset. From the compile commands it looks like 
also nothing like Debug nor Release.

Why is there no well-defined default set? How can I set a default?

Thanks,
Florian
-- 

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] The C compiler "/usr/bin/cc" is not able to compile a simple test program.

2017-07-31 Thread jupiter
Thanks Micha and Nils.

Cheers.



On Sun, Jul 30, 2017 at 6:54 PM, Micha Hergarden 
wrote:

> On 30-07-17 04:36, jupiter wrote:
>
> I thought if I add -DCMAKE_CC_COMPILER=gcc that error should go, no, it
> still compile with the specific default cc:
>
> /usr/bin/cc 
>
> How could I fix it?
>
> Thank you.
>
> On Sun, Jul 30, 2017 at 11:51 AM, jupiter  wrote:
>
>> Hi,
>>
>> How can I set up the cmake not to check /usr/bin/cc but to check $CC
>> (which link to gcc without hard corded path in the environment)?
>>
>> Thank you.
>>
>> Regards
>>
>>
>>
>
>
> Hello Jupiter,
>
> Running the following sets the compiler to gcov:
>
> CC=/usr/bin/gcov cmake ../
>
> This outputs:
>
> -- The C compiler identification is unknown
> -- The CXX compiler identification is GNU 7.1.1
> -- Check for working C compiler: /usr/bin/gcov
> -- Check for working C compiler: /usr/bin/gcov -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - failed
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Configuring done
> -- Generating done
>
>
> As you can see cmake definitely uses the CC environment variable. What is
> your OS? What do you set $CC to? What is the full commandline you use to
> call cmake?
> What happens if you set it the way I did?
>
> Regards,
> Micha
>
-- 

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] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what?

2017-07-31 Thread Brian J. Davis


My responses are inline.

As are mine.

On Sat, Jul 29, 2017 at 7:00 PM, Brian J. Davis http://public.kitware.com/mailman/listinfo/cmake>> wrote:
>/@Robert />//>/I created a fresh simple cmake project in 3.9. This appeared to find 
CUDA />/8.0 successfully so it may have something do with my other project 
settings />/that I am trying to get to work with 3.9, VS13, CUDA 7.5/8.0. />//>/Using: />//>/message( CUDACXX = ${CUDACXX}) />/message( CMAKE_CUDA_COMPILER = ${CMAKE_CUDA_COMPILER}) />//>//>/Reports />//>/CUDACXX= />/CMAKE_CUDA_COMPILER=C:/Program Files/NVIDIA GPU Computing />/Toolkit/CUDA/v8.0/bin/nvcc.exe />/Configuring done />/Generating done />//>/The question was at setting the CUDA version say 7.5 or 8.0. />//>/I search doc for CUDACXX and CMAKE_CUDA_COMPILER with no hits. Is this />/stuff documented anywhere. /

Unfortunately the environment variables are not documented anywhere
and this is a known issue
that I hope to have fixed in CMake 3.10.

The CMAKE_CUDA_COMPILER falls under the the CMAKE__COMPILER documentation
now with the new CUDA support (
https://cmake.org/cmake/help/v3.8/variable/CMAKE_LANG_COMPILER.html  ).



So let me get this straight.  Changes appear to begin in 3.7 / 3.8 with 
VS started to be supported in 3.9, but the only way us schleps on the 
internet know how to use it is to wait until 3.10. Wow... seriously.  
And well I am not holding out *hope*.


>//>/Do I really need to say set: />//>/CMAKE_CUDA_COMPILER=C:/Program Files/NVIDIA GPU Computing />/Toolkit/CUDA/v7.5/bin/nvcc.exe />//>/To get CMake to compile for 7.5? I mean: />//>/find_package(CUDA 7.5) />//>/you could agree is/was much simpler. I am becoming frustrated and 
confused />/by these changes. /

It might be possible in the future to provide other hint controls to
tell CMake which
version of CUDA you would like to use before the project /
enable_language call. This
would be something that is best addressed on the cmake developer list or as
a gitlab issue (https://gitlab.kitware.com/cmake/cmake/issues  )
In the future with the robots... anything is possible... provided they 
are not out to kill us.


Why would I bother to seemingly point out the obvious @developers list 
or issue tracker.  Hopefully anyone reading this can tell I am a bit 
frustrated at this point.  Huh here's how that would go:


Me: Hey Devs you forgot to document how to use the tool.  Do you expect 
anyone but you to know how to use it?


Devs: Huh yea we know...  Ugh ... errr... Huhhh were getting to that.

Me: sigh...
>//>/I can't even get a simple CUDA app to run using FindCUDA (will 
compile) or />/compile using v3.9 and new project( CXX CUDA). />//>/Your example at: />//>/https://cmake.org/cmake/help/latest/manual/cmake-compile-features.7.html />//>//>/Used: />//>/add_executable(CudaConsumeCompileFeatures main.cu) />//>/Is is required now that main.cpp be a .cu file now? I wouldn't think so, />/but I am so lost in the woods on this that I am not sure of anything />/anymore. /

So with the new CUDA support you can mix C/C++/CUDA sources together
inside a single library or executable. This example was only using CUDA
in the executable to reduce the complexity of the test.

Only if I can get it to work.  Which I can't ... and would not know how 
anyway as well it is not documented... so why waste my time.
>//>/How do I get all the toolkit and sdk include and lib dir variables now 
as />/FindCUDA provided? /

The toolkit include directory can be found by querying
CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES
As far as CUDA SDK libraries those can simply used with target_link_libraries
as the SDK library path is considered to be an implicit link directory, and will
always be on the link line. This is actually the same for the CUDA sdk include
directory ( it will be placed on the include line when building ).

>//>/I am so curfuffled by these changes. /
These changes are needed to allow targets using CUDA to properly work with
'Modern' CMake 
(https://cmake.org/cmake/help/v3.8/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements).
Without these changes usage requirements and CUDA would never work together.

I assume the term *work* is used loosely VERY loosely.  I hate to 
point out the obvious, but I can't get it to work now and have not clue 
or seemingly hope on figuring it out other than to check out CMake and 
roll my own version after reading impl in order to figure out how it 
does and how to get it to work.  By that time I'd rather revert to 
writing VS xml project file by hand.


Regarding 960M and CUDA  7.5/7.5, 8.0/7.5, and 7.7/9.0

Answer is:

960M was likely released post CUDA  7.5 driver and possibly post 8.0.  
Seems that architecture differences do not allow old drivers to work on 
newer arch cards.   Once 9.0 driver was released... 7.5 run time worked 
with 9.0 driver, but for some reason not 8.0. Seems CUDA and Nvidia 
Runtime/Drivers have a dirty little secret much like Java and the runtimes.


At this poi

Re: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what?

2017-07-31 Thread Robert Maynard
My responses are inline.

On Sat, Jul 29, 2017 at 7:00 PM, Brian J. Davis  wrote:
> @Robert
>
> I created a fresh simple cmake project in 3.9.  This appeared to find CUDA
> 8.0 successfully so it may have something do with my other project settings
> that I am trying to get to work with 3.9, VS13, CUDA 7.5/8.0.
>
> Using:
>
> message( CUDACXX = ${CUDACXX})
> message( CMAKE_CUDA_COMPILER = ${CMAKE_CUDA_COMPILER})
>
>
> Reports
>
> CUDACXX=
> CMAKE_CUDA_COMPILER=C:/Program Files/NVIDIA GPU Computing
> Toolkit/CUDA/v8.0/bin/nvcc.exe
> Configuring done
> Generating done
>
> The question was at setting the CUDA version say 7.5 or 8.0.
>
> I search doc for CUDACXX and CMAKE_CUDA_COMPILER with no hits.  Is this
> stuff documented anywhere.

Unfortunately the environment variables are not documented anywhere
and this is a known issue
that I hope to have fixed in CMake 3.10.

The CMAKE_CUDA_COMPILER falls under the the CMAKE__COMPILER documentation
now with the new CUDA support (
https://cmake.org/cmake/help/v3.8/variable/CMAKE_LANG_COMPILER.html ).


>
> Do I really need to say set:
>
> CMAKE_CUDA_COMPILER=C:/Program Files/NVIDIA GPU Computing
> Toolkit/CUDA/v7.5/bin/nvcc.exe
>
> To get CMake to compile for 7.5?  I mean:
>
> find_package(CUDA 7.5)
>
> you could agree is/was much simpler.  I am becoming frustrated and confused
> by these changes.

It might be possible in the future to provide other hint controls to
tell CMake which
version of CUDA you would like to use before the project /
enable_language call. This
would be something that is best addressed on the cmake developer list or as
a gitlab issue ( https://gitlab.kitware.com/cmake/cmake/issues )

>
> I can't even get a simple CUDA app to run using FindCUDA (will compile) or
> compile using v3.9 and new project( CXX CUDA).
>
> Your example at:
>
> https://cmake.org/cmake/help/latest/manual/cmake-compile-features.7.html
>
>
> Used:
>
> add_executable(CudaConsumeCompileFeatures main.cu)
>
> Is is required now that main.cpp be a .cu file now?  I wouldn't think so,
> but I am so lost in the woods on this that I am not sure of anything
> anymore.

So with the new CUDA support you can mix C/C++/CUDA sources together
inside a single library or executable. This example was only using CUDA
in the executable to reduce the complexity of the test.




>
> How do I get all the toolkit and sdk include and lib dir variables now as
> FindCUDA provided?

The toolkit include directory can be found by querying
CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES
As far as CUDA SDK libraries those can simply used with target_link_libraries
as the SDK library path is considered to be an implicit link directory, and will
always be on the link line. This is actually the same for the CUDA sdk include
directory ( it will be placed on the include line when building ).

>
> I am so curfuffled by these changes.

These changes are needed to allow targets using CUDA to properly work with
'Modern' CMake 
(https://cmake.org/cmake/help/v3.8/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements).
Without these changes usage requirements and CUDA would never work together.

>
> Can I get the CMake doc in one (1) html page again... those were the good
> old days when scanning back and forth I would stumble on some good bits ...
> not that I can seemly find the doc for the new CUDA changes.  This reminds
> me of the days when I could only get doc on things like ExternalProject_Add
> at the command prompt.
>
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what?

2017-07-31 Thread Brian J. Davis


Could this be a Win 10 Pro/Enterprise CMake combo issue.  I brought over 
demo project to OS refreshed M4700.  Was Win7 Pro now Windows 10 
Enterprise.


Dell M4700 combo is:

Device 0: "Quadro K1000M"
  CUDA Driver Version / Runtime Version  8.0 / 7.5

CMake 3.2 or 3.9 will build but not run which is the same as on the Dell 
7559 w 960M.


I am rebuilding, due to OS change a rebuild in CMake is necessary, my 
existing project that was working and will test that.  Though simple 3.2 
project does not work so my hopes are not high that my existing project 
will fair any better.


Samples such as NBody work on M4700.

All worked on M4700 Win7 before OS refresh with exception of 3.9 
attempts as I started trying 3.9 on 7559 w/Win10Pro.


Why would it be that CMake can compile an executable but not run it when 
the CUDA samples work?


CUDA SDK Samples run just fine from VS (well when driver run time is 
9.0/7.5 on 7559 w 960M), but simple CMake generated app does not. Simple 
in that it only finds device (0) and calls cudaMalloc... ya know... the 
ultra basic.





--

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] "Modern" approach to optional/multiple configurations?

2017-07-31 Thread paul via CMake
On Mon, 2017-07-24 at 10:46 +0100, Nicholas Devenish wrote:
> Seen in the boost discussions on the CMake announcements:
>  
> > > The rest can be implemented straightforwardly as cache options so that
> > > you can run cmake with options like
> > >
> > >   -Dvalgrind=OFF -Dtransactional-memory=ON -Dsegmented-stacks=ON [-D…]
> > ...
> 
> Secondly, in cmake 3 we try not to configure things using -D as we did
> in cmake 2. Instead we make targets customised for that build
> combination. The user then chooses to make or link to those targets if
> they want those targets.
>  
> Is this true, and is there a good example of a project with such a
> configuration?
> 
> I've been trying to learn the more modern approaches to writing CMakeLists
> recently, and haven't come across such advice - I was under the impression
> that cache-set options (that the build can make decisions on) was still the
> recommended 'clean' way, and then options (and even extra sources,
> dependencies) can be added to each target as required.
> 
> As I imagine what this is saying, It seems that target-per-configuration
> would just lead to an explosion of duplicated targets and duplicated code,
> especially through every permutation of several different options? 
> 
> Part of the niceness of target-oriented dependencies was just having one
> thing to link to and depending on the configuration, that target would be
> the correct one (and pass through it's configuration).

At least Daniel Pfeifer's presentation of best practices here:

https://www.slideshare.net/DanielPfeifer1/cmake-48475415

Says:

* Dont’t make libraries STATIC/SHARED unless they cannot be built otherwise.
* Leave the control of BUILD_SHARED_LIBS to your clients!

Which would imply a build tree per configuration. I have never seen any
information of best practices that suggests creating multiple targets for each
variant in cmake 2 or 3.



-- 

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