Re: [CMake] How to generate a non-standard platform and non-standard project file with the Visual studio generator

[jeff]

OK, no response yet.  I'm not sure if that means this is a problem that isn't 
interesting to most or if it is a good hard problem that no one knows how to 
solve.

Thinking a little more, I'm starting to lean toward a solution where I have a 
build_src folder where I put something like the sample .vcxproj file that I 
pasted in my first e-mail.  I can update the file substituting CMake variables 
for some of the information that needs to be updated and use 
configure_package_config_file() to replace the data according to the execution 
of cmake against the current CMakeLists.txt file.  Then, maybe I could copy the 
output file over the standard cmake process generated .vcxproj file as a post 
build step.  Not sure if this would work, particularly the bit about copying 
over the standard .vcxproj file, but one way to find out, right?

This is the approach I'm going to attempt unless anyone has a better 
suggestion.  Trying not to beg for help here.  😉

-Original Message-
From: CMake  On Behalf Of j...@22ndtech.com
Sent: Sunday, April 14, 2019 9:27 PM
To: cmake@cmake.org
Subject: [CMake] How to generate a non-standard platform and non-standard 
project file with the Visual studio generator

Hi all,

Do you have any suggestions for generation of a non-standard platform and 
project file from Visual Studio.  I'm trying to generate a file compatible with 
the Magic Leap Visual Studio Extension.  The first problem I have is that the 
platform is ML, not the standard x86 or x64.  The next problem is that it is 
not a standard msbuild project file, but an nmake file.  I've included the 
.vcxproj file from their simple OpenGL app sample below.


http://schemas.microsoft.com/developer/msbuild/2003";>
  

  Debug
  ML


  Release
  ML


  Debug
  x64


  Release
  x64

  
  

{"$mlprojguid$"}
$mlprojfile$
$mlprojkind$
$ml_mfit_extra_args$
  
  


  
  
True
  
  
  
Makefile
$platformtoolset$
  
  
Makefile
$platformtoolset$
  
  
Makefile
$platformtoolset$
  
  
Makefile
$platformtoolset$
  
  
  
  
  
  
  
  
 
false
false
  
  


  Project









  PropertySheet



  File

  
  
$mlsdkpath$
$device_debug_certificate$

$ml_extra_build_options$
$device_debug_full_spec$
$(MLSDK);$(PATH)



mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t 
device_debug -v --set-options=ide/visualstudio 
$(MLExtraBuildOption)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t 
device_debug -r -v --set-options=ide/visualstudio 
$(MLExtraBuildOption)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t 
device_debug -c -v --set-options=ide/visualstudio 
$(MLExtraBuildOption)
 
$device_debug_preprocessor_defines$
 
$device_debug_include_paths$
 
$(LOCALAPPDATA)\Microsoft\VisualStudio\MagicLeap\ml_is.
h
$device_debug_packagefile$
$device_debug_outputdir$
$(ProjectDir)\$(IntDir)
$(IntDir)\$device_debug_outputfile$
$(NMakeOutput)
MLDebugger

false
true
main
true
true
  
  
$mlsdkpath$
$device_release_certificate$
$ml_extra_build_options$
$device_release_full_spec$
$(MLSDK);$(PATH)



mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t 
device_release -v --set-options=ide/visualstudio 
$(MLExtraBuildOption)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t 
device_release -r -v --set-options=ide/visualstudio 
$(MLExtraBuildOption)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t 
device_release -c -v --set-options=ide/visualstudio 
$(MLExtraBuildOption)
 
$device_release_preprocessor_defines$
 
$device_release_include_paths$
 
$(LOCALAPPDATA)\Microsoft\VisualStudio\MagicLeap\ml_is.
h
$device_release_packagefile$
$device_release_outputdir$
$(ProjectDir)\$(IntDir)
$(IntDir)\$device_release_outputfile$
$(NMakeOutput)
MLDebugger

false
false

true
true
  
  
$mlsdkpath$
$host_debug_certificate$
$ml_extra_build_options$
$host_debug_full_spec$
$(MLSDK);$(PATH)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t 
msvc-$msvcversion$_debug -v VCDIR="$(VCInstallDir) 
$(MLExtraBuildOption)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t 
msvc-$msvcversion$_debug -r -v VCDIR="$(VCInstallDir) 
$(MLExtraBuildOption)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t 
msvc-$msvcversion$_debug -c -v VCDIR="$(VCInstallDir) 
$(MLExtraBuildOption)
 
$host_debug_preprocessor_defines$
 
$host_debug_include_paths$
$host_debug_packagefile$
$host_debug_outputdir$
$(ProjectDir)\$(IntDir)
$(IntDir)\$host_debug_outputfile$
WindowsLocalDebugger

false
true

 
PATH=$(MLSDK)\VirtualDevice\bin;$(MLSDK)\VirtualDe
vice\lib;$(MLSDK)\lib\win64

 
$(ProjectDir)\$ml_asset_folder$
  
  
$mlsdkpath$
$host_release_certificate$
$ml_extra_build_options$
$host_release_full_spe

Re: [CMake] Boost 1.70.0 -- FindBoost issues? No linker libraries found (Mateusz Loskot)

[Andrew Maclean]

Thank you so much, this works perfectly.


>
> -- Forwarded message --
> From: Mateusz Loskot 
> To: cmake@cmake.org
> Cc:
> Bcc:
> Date: Tue, 16 Apr 2019 01:10:44 +0200
> Subject: Re: [CMake] Boost 1.70.0 -- FindBoost issues? No linker libraries
> found
> On Tue, 16 Apr 2019 at 01:01, Andrew Maclean 
> wrote:
> >
> >  In build.ninja all the requested linker libraries are there e.g.
> /usr/local/lib/libboost_date_time.so>
> > Boost 1.70
> > When using Boost 1.70 all I get in the CMakeLists.txt file are entries
> like:
> > //The directory containing a CMake configuration file for
> boost_date_time.
> > boost_date_time_DIR:PATH=/usr/local/lib/cmake/boost_date_time-1.70.0
>
> Installation of Boost 1.70 generates and deploys a brand new
> BoostConfig.cmake
> machinery which is still being tested.
>
> Try setting -DBoost_NO_BOOST_CMAKE=ON to get the old FindBoost.cmake
> behaviour
> https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L238
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
>
>
>
> --
___
Andrew J. P. Maclean

___
-- 

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] Linked Imported Library in Visual Studio Showing NOTFOUND

[Dustyn Blasig]

Hi All,

I'm trying to debug an issues where an imported shared library is showing
up in the linker command as not found, but within the CMake generation the
target seems to exist.

# CMakeLists.txt 

include(bar.cmake)

add_library(foo SHARED)

if(TARGET bar)
  target_link_libraries(foo PUBLIC bar)
endif()

# bar.cmake ###

add_library(bar SHARED IMPORTED)

...


On Linux, the link command contains the correct *-L* and *-lbar*
options. However, on Windows (Visual Studio) the linker command has
"bar-NOTFOUND" instead of bar.lib as it should, even though bar should only
be added as a dependency *if* it exists.

How can I debug why this would happen? Is there a way to have CMake dump
more information about that target?

Thanks!
-- 

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] CXX and CUDACXX

[Robert Maynard via CMake]

I don't have any other suggestions. In general I recommend the script
approach or using enable_language(CUDA). The enable_language approach
should work, so I am curious what other issues you are seeing.

On Tue, Apr 16, 2019 at 2:24 PM Dustyn Blasig  wrote:
>
> Thx for the info.
>
> Since CXX and CUDA are defined together in the project() command, I don't see 
> a way to inject code to use the CXX compiler if no CUDAHOSTCXX or 
> CMAKE_CUDA_HOST_COMPILER is given without replicating the CXX search. I tried 
> moving CUDA out to an enable_language(CUDA) call instead so I could set those 
> variables between project(foo LANGUAGES CXX) and enable_language(CUDA), but 
> I'm seeing other issues with that approach.
>
> Any other suggestions? If not, we'll just wrap our cmake invocation in a 
> script to help setup the environment properly for now.
>
> Thx!
>
> On Tue, Apr 16, 2019 at 1:10 PM Robert Maynard  
> wrote:
>>
>> The default implementation is to defer to  CUDA for selecting what
>> ever host compiler it would like. To make sure that CMake uses the
>> same CXX and CUDACXX compiler you will need to explicitly state that
>> either through the CUDAHOSTCXX env variable (
>> https://cmake.org/cmake/help/v3.12/envvar/CUDAHOSTCXX.html ) or with
>> CMAKE_CUDA_HOST_COMPILER on the initial configuration of a project.
-- 

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] CXX and CUDACXX

[Dustyn Blasig]

Thx for the info.

Since CXX and CUDA are defined together in the project() command, I don't
see a way to inject code to use the CXX compiler if no CUDAHOSTCXX or
CMAKE_CUDA_HOST_COMPILER is given without replicating the CXX search. I
tried moving CUDA out to an enable_language(CUDA) call instead so I could
set those variables between project(foo LANGUAGES CXX) and
enable_language(CUDA), but I'm seeing other issues with that approach.

Any other suggestions? If not, we'll just wrap our cmake invocation in a
script to help setup the environment properly for now.

Thx!

On Tue, Apr 16, 2019 at 1:10 PM Robert Maynard 
wrote:

> The default implementation is to defer to  CUDA for selecting what
> ever host compiler it would like. To make sure that CMake uses the
> same CXX and CUDACXX compiler you will need to explicitly state that
> either through the CUDAHOSTCXX env variable (
> https://cmake.org/cmake/help/v3.12/envvar/CUDAHOSTCXX.html ) or with
> CMAKE_CUDA_HOST_COMPILER on the initial configuration of a project.
>
-- 

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] CXX and CUDACXX

[Robert Maynard via CMake]

The default implementation is to defer to  CUDA for selecting what
ever host compiler it would like. To make sure that CMake uses the
same CXX and CUDACXX compiler you will need to explicitly state that
either through the CUDAHOSTCXX env variable (
https://cmake.org/cmake/help/v3.12/envvar/CUDAHOSTCXX.html ) or with
CMAKE_CUDA_HOST_COMPILER on the initial configuration of a project.
-- 

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] Correct use of VS_DEBUGGER_WORKING_DIRECTORY etc.

[Stephen Morris]

I’m trying to use the new VS_DEBUGGER_WORKING_DIRECTORY and VS_DEBUGGER_COMMAND 
properties to facilitate debugging in a CMake-generated Visual Studio project 
file (in my case Visual Studio 2013).

Everything else in my configuration works except this…

I’ve noted from ‘regular’ Visual Studio project files (i.e. ones not generated 
from CMake that, in the “Configuration Properties/Debugging” dialog, the 
‘Command’ and ‘Working Directory’ fields are populated by default with 
$(TargetPath) and $(TargetDir) respectively. So in my CMakeLists.txt file, I 
have:

set_target_properties(myApplication PROPERTIES 
VS_DEBUGGER_WORKING_DIRECTORY "$(TargetDir)"

   VS_DEBUGGER_COMMAND"$(TargetPath)"

   VS_DEBUGGER_ENVIRONMENT  
"%PATH%;C:\\Qt\\5.9.7\\msvc2013_64\\bin")

[In fact I've tried this with and without the quotes around $(TargetDir) and 
$(TargetPath) and the result is the same each time; they're absolutely 
necessary around the path.]

What happens is that I then build the application, go to the “Configuration 
Properties/Debugging” dialog and verify that it looks exactly the same as a 
normal project file, with $(TargetDir) and $(TargetPath) appearing exactly 
where they should do. It doesn't work though; when I try to debug I get a 
message saying "Unable to start debugging. Check your debugger settings..."

So I delete the text $(TargetDir) and $(TargetPath) from the dialog, then type 
them in again exactly as before: and then it works perfectly.

What am I doing wrong?
-- 

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] CXX and CUDACXX

[Dustyn Blasig]

Hi All,

I'd like to understand the expectations with CMake 3.12+ with the following
setup.

project(foo LANGUAGES CXX CUDA)

By default, should the CUDACXX compiler be using the found compiler for CXX
for host-side compilation?

What I'm seeing is that host-side compilation for CUDA is not passing
-ccbin to NVCC or setting up the environment in a way that nvcc will use
the CXX configured compiler but rather just using the c++ it finds on PATH.

Is there a best practice for telling the CUDA language to use the CXX
settings for host-side compilation?

Thanks!
-- 

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] ctest // fixtures and --repeat-until-fail

[Sergei Nikulov]

>
> On Tue, Apr 16, 2019 at 10:07 PM Sergei Nikulov  
> wrote:
>>
>> Hello All,
>>
>> Has anybody knows how FIXTURES_SETUP/FIXTURES_CLEANUP should work with
>> --repeat-until-fail  option?
>>
>> My expectation, if I requesting a test run for example 10 times, the
>> sequence should be as follows:
>>
>> fixture_setup, then test, then fixture_cleanup repeats 10 times
>>
>> But in practice, I've got following sequence
>>
>> 1. fixture_setup runs 10 times
>> 2. test runs 10 times
>> 3. fixture_cleanup runs 10 times
>>
>> Is it expected behavior?
>> I'm using ctest version 3.14.2
>
>
> The documentation for the --repeat-until-fail option says "Require each test 
> to run  times without failing in order to pass". A fixture setup or 
> cleanup test is still a test, so they will also be run  times. The logic 
> that implements repeating tests sets up a counter on each test and it runs 
> that test  times before marking that test as complete. This is why you see 
> fixture_setup run 10 times, then test runs 10 times and lastly 
> fixture_cleanup runs 10 times.
>

I understand that fixture is still a test.
To achieve repeatable behavior -R "test_continues_*" is enough.

But if it calls FIXTURE why not apply the specific behavior as
expected from fixture (init/teardown)?

-- 
Best Regards,
Sergei Nikulov
-- 

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] ctest // fixtures and --repeat-until-fail

[Craig Scott]

On Tue, Apr 16, 2019 at 10:07 PM Sergei Nikulov 
wrote:

> Hello All,
>
> Has anybody knows how FIXTURES_SETUP/FIXTURES_CLEANUP should work with
> --repeat-until-fail  option?
>
> My expectation, if I requesting a test run for example 10 times, the
> sequence should be as follows:
>
> fixture_setup, then test, then fixture_cleanup repeats 10 times
>
> But in practice, I've got following sequence
>
> 1. fixture_setup runs 10 times
> 2. test runs 10 times
> 3. fixture_cleanup runs 10 times
>
> Is it expected behavior?
> I'm using ctest version 3.14.2
>

The documentation for the --repeat-until-fail option says "Require each
test to run  times without failing in order to pass". A fixture setup or
cleanup test is still a test, so they will also be run  times. The logic
that implements repeating tests sets up a counter on each test and it runs
that test  times before marking that test as complete. This is why you
see fixture_setup run 10 times, then test runs 10 times and lastly
fixture_cleanup runs 10 times.

Whenever I've wanted to use --repeat-until-fail (admittedly not all that
common for me), I'm generally only interested in repeatedly running one
particular test. For that case, I would typically run the test once with
fixture cleanups disabled (i.e. use a command line "ctest -FC . -R
myFlakeyTest"). I can then run ctest again for just my flaky test with all
fixtures disabled (e.g. "ctest -FA . -R myFlakeyTest --repeat-until-fail
10"). This strategy won't work for everyone's situation, but it has been
effective for me.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide 
-- 

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] ctest // fixtures and --repeat-until-fail

[Sergei Nikulov]

Hello All,

Has anybody knows how FIXTURES_SETUP/FIXTURES_CLEANUP should work with
--repeat-until-fail  option?

My expectation, if I requesting a test run for example 10 times, the
sequence should be as follows:

fixture_setup, then test, then fixture_cleanup repeats 10 times

But in practice, I've got following sequence

1. fixture_setup runs 10 times
2. test runs 10 times
3. fixture_cleanup runs 10 times

Is it expected behavior?
I'm using ctest version 3.14.2

Thank you in advance.

-- 
Best Regards,
Sergei Nikulov
-- 

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