Re: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug

[Mate Nagy-Egri via cmake-developers]

 I was just about to write a mail with similar content than this one, so allow 
me to add my 5 cents.
Fear of reyling on defaults in case Microsoft decides to change them?
1) Defaults don't change often. BTW, don't we rely on defaults for GCC and 
Clang anyway?2) Defaults change to benefit users. If the default changes from 
/W3 to /W4 per say, it would be because windows.h headers and the STL would be 
cleaned up for the warnings in /W4 and MS felt that it would be better if users 
relied on all the warning they packed there. (Currently it is not the case)
As for having to call string() on CMAKE_CXX_FLAGS to up my warning level for a 
single compiler... these sort of idiosincrecies are the ones that drive people 
away from CMake to Meson and other, more modern build systems. Not being able 
to clean up decades worth of sediments in script style will result in CMake's 
demise.

if (MSVC)  string(REGEX REPLACE "/W[0-9]""" CMAKE_CXX_FLAGS 
${CMAKE_CXX_FLAGS})endif (MSVC) add_executable(${PROJECT_NAME}main.cpp) 
target_compile_options(${PROJECT_NAME}PRIVATE$<$,$>:-Wall-Wextra
 -pedantic>  
$<$:/W4>) 
Instead of
 add_executable(${PROJECT_NAME}main.cpp) 
target_compile_options(${PROJECT_NAME}PRIVATE$<$,$>:-Wall-Wextra
 -pedantic>  
$<$:/W4>)
Or even
add_executable(${PROJECT_NAME}main.cpp)
set_target_properties(${PROJECT_NAME}PROPERTIES WARNING_LEVEL HIGH)
is nonsense. There should be direct support for a few pre-defined, commonly 
accepted warning levels. If not this, having to explain to C++ freshmen why 
we're running regexes over lists default args to clean them up BEFORE even 
stating our bussiness...


Please, remove this default because it hurts CMake as a whole.
Cheers,Máté

-Original Message-
From: Mateusz Loskot 
To: marc.chevrier 
Cc: cmake-developers ; cmake 
Sent: Sun, Dec 9, 2018 2:55 pm
Subject: Re: [cmake-developers] [CMake] [MSVC] Setting warning level on target 
feels like long-time bug

On Sun, 9 Dec 2018 at 14:09, Marc CHEVRIER  wrote:
>
> I think the discussion is shifting from the initial problem which was 
> unwanted warning « Command line warning D9025: overriding '/W3' with '/W4' ».

I disagree with your opinion.
Fixing just the warning would be a symptomatic treatment.

> Changing defaults is not a good idea from my point of view because relying on 
> defaults can be problematic if Microsoft decide to change the default 
> behaviour.

Although I think it is a long shot at something that is (highly)
unlikely to change, YAGNI consideration,
I understand CMake developers may be reluctant to change the long-time defaults.

> The real question is how to manage cleanly target specific flags overriding 
> global or directory defaults?

>From end-user point of view (I have not checekd CMake implementation),
I'd either do not explicitly set -W defaults or strip any -W option
prior re-setting
with (possibly) new value passed to target_compile_options.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
-- 

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-developers
-- 

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-developers

Re: [cmake-developers] [Discussion] Add python support forCMakeLists

[Mate Nagy-Egri via cmake-developers]

This all rhymes fairly well with an earlier suggestion of mine, CMake IR, a 
stateless intermediate representation. Though I originally suggested this 
feature to facilitate the authoring of generators, it could’ve also act as an 
alternative front-end, other than the CMake script language (which is still the 
least friendliest part in CMake, hence these attempts of ridding it in favor of 
friendlier scripting languages).

The scenario depicted here is pretty much doable already, but not in CMake 
terms. The stateless part is pretty much MSBuild, built atop XML with well 
defined schemas for the various build steps (C++ build, C++ link, C# build, 
etc.), and there is a custom target that has pre-build, build, and post-build 
steps (as all other targets as well). If you’d invoke Python there, you’re 
pretty much at the place you depict here. Using MSBuild, you’d only need a 
schema to invoke CMake targets to interoperate with current CMake projects.

One of the reasons why VS is so successful, is because you don’t need to invoke 
voodoo to acomplish something as simple as a build. Click-click and you’re 
done. This is because the build representation is SIMPLE (just XML). I 
understand that the reason why CMakes script language only has one type, the 
string type is because it is the common denominator for all the target 
generators and it is easy to handle inside generator implementations, but heck, 
it’s a pain to use. The fact that source files to add_executable() may be a 
list, but target_compile_definitions cannot… it’s a joke. I have to manually 
insert spaces in between compiler options.

Apologies if my tone is harsh at times, but I believe CMake could do a lot 
better. Server Mode is welcome sight, but it’s pretty much a workaround, or at 
least half the job. I believe CMake really needs to open to other front-ends 
than its script language, and Server Mode only compliments this. I understand 
that it becomes an N*M issue at this point, but heck; we have lived with 
containers and iterators (abstractions in general) that go around this issue.

MSBuild going cross-platform thanks to .Net Core renders it a compelling 
alternative for everyday tasks. (And I still have not touched upon Scons, Cake, 
Fake, Psbuild and the likes.)

Feladó: Shmuel H,
Elküldve: 2017. január 14., szombat 9:27
Címzett: Brad King
Másolatot kap: CMake Developers
Tárgy: Re: [cmake-developers] [Discussion] Add python support forCMakeLists

Maybe we could combine them together: the configuration process would be 
separated into two stages:
1. Script stage: Look for and run build script, that will generate a [JSON] 
configuration file.
2. Look for a configuration file, and generate build files according to it.
Then, a programmer should decide if he need to use the script stage. If not, he 
would be able to edit it all with its favorite IDE. If he need the script 
stage, he would not be able to edit it with a automatic tools.

I think we should make the configuration files as simple as we can (`cbp` files 
are not a good example for a simple file): usable defaults for fields, etc.

Adding named condition \ variables would serve only a part of developers needs 
(for example, choosing source files according to the current OS) but it would 
prevent developers from being able to customize their building with functions 
(For example, applying a long set of configurations for each build target to be 
used as a plugin for an application with a lot of restrictions).

On Fri, Jan 13, 2017 at 9:28 PM, Brad King  wrote:
On 01/13/2017 11:45 AM, Shmuel H, wrote:
> * From the other side, programmers should be able to use a script
>   language to customize their build process.
>
> For example, a simple declaration (pseudo code):
> cmake_libraries += {
>                                    ["name":      "myLib",
>                                     "files":         "myLib.c",
>                                     "link_type": "static"]
>                                 }

The declarative part needs to be self-standing so that it can be loaded
by an IDE, edited by the user, and saved back out in the original format
with a minimal diff.  An IDE will have no idea how to write snippets back
into a procedural script.  This is one reason CMakeLists.txt files cannot
be edited through an IDE except as text files.

My proposal is that the declarative part would have most of the build,
but with some kind of named condition/config variables.  Then the
procedural part will introspect the system to determine the values of
the configuration variables so that CMake can evaluate the conditions.

-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: 

Re: [cmake-developers] Debug through config/gen inside Visual Studio

[Mate Nagy-Egri via cmake-developers]

Thank you Brad. I took the aggressive way and completely wiped the environment 
inside the debugged process. For those anyone wishing to do something similar, 
here’s what I’ve done:

I wrote a PowerShell oneliner:

gci Env: | foreach { $_.Name + "=" + $_.Value } | Out-File -FilePath 
.\Desktop\env.txt -Append

When invoked inside a Visual Command Prompt this outputs a complete environment 
into a file in a format that can be copy-pasted into the Visual Studio Project 
Property Page. Make sure to set Merge Environment option to No. After this it 
worked like a charm.

Now it’s only up to me to understand the entire process of Makefile generation. 
Global/Local Generators, LocalMakeFileGenerator3 (does 3 correspond to the 
third layer of makefiles? If yes, where is 2?)… The code is fairly convoluted 
(seems a bit more complex than neccessary, but it might be my lack of 
understanding that makes me feel this way).

One sidequestion: what is the reason for eliding STL algorithms? There are nice 
iterators all over the place, yet no algorithms used, even when it were 
possible. Algorithms make the code much easier to understand (the name of the 
algorithm states the intent of the for-loop), plus when C++17 hits 
(configure-time check?), parallel STL invocations could speed up the 
configuration process automatically with minimal code impact. Would you accept 
such patches, where loops are exchanged for algorithms where possible?


Feladó: Brad King-- 

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] Debug through config/gen inside Visual Studio

[Mate Nagy-Egri via cmake-developers]

Some very interesting things are happening. I am walking through the code with 
F11, F10, Shift+F10 and trying to understand what’s happening. What really 
makes this process hard is that occasionally it succeeds generating the 
Makefile and the exit code is 0. Ultimately if I try to run the generated 
makefile it terminates with a linker error:

PS C:\Users\Matty> Import-VisualEnvironment -Version 14 -Architecture Win64
PS C:\Users\Matty> cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]
PS C:\Users\Matty> cd .\Build\CMake_Example\NMake\
PS C:\Users\Matty\Build\CMake_Example\NMake> nmake clean

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

PS C:\Users\Matty\Build\CMake_Example\NMake> nmake

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

[ 20%] Building CXX object phys/CMakeFiles/Phys.dir/src/stuff.cpp.obj
stuff.cpp
[ 40%] Building CXX object phys/CMakeFiles/Phys.dir/src/more.cpp.obj
more.cpp
[ 60%] Linking CXX static library Phys.lib
[ 60%] Built target Phys
[ 80%] Building CXX object app/CMakeFiles/Application.dir/src/main.cpp.obj
main.cpp
[100%] Linking CXX executable Application.exe
[100%] Built target Application

Import-VisualEnvironment is a PowerShell Commandlet made by me which 
essentially calls vcvarsall.bat.

The extra info I gained through the VERBOSE=1 env var is this:

Linking C executable cmTC_14330.exe

C:\Users\Matty\Build\CMake\VS14\bin\Debug\cmake.exe -E vs_link_exe
  --intdir=CMakeFiles\cmTC_14330.dir --manifests --
  C:\Kellekek\MICROS~1\VISUAL~1\14.0\VC\bin\amd64\link.exe /nologo
  @CMakeFiles\cmTC_14330.dir\objects1.rsp
  @C:\Users\Matty\AppData\Local\Temp\nm32CF.tmp

  Visual Studio Incremental Link with embedded manifests

  Create CMakeFiles\cmTC_14330.dir/manifest.rc

  Create empty: CMakeFiles\cmTC_14330.dir/embed.manifest

  RC Pass 1:

   /foCMakeFiles\cmTC_14330.dir/manifest.res 
CMakeFiles\cmTC_14330.dir/manifest.rc

  RC Pass 1 failed to run.

However, this part I do not understand. I believe something is not quite 
consistent within the generation process, sometimes succeeding and somethimes 
not. Any ideas?


Thanks Brad for the tips thus far,
Máté


Feladó: Brad King
Elküldve: 2016. szeptember 15., csütörtök 15:11
Címzett: csiga.b...@aol.com
Másolatot kap: cmake-developers@cmake.org
Tárgy: Re: [cmake-developers] Debug through config/gen inside Visual Studio

On 09/15/2016 09:04 AM, csiga.b...@aol.com wrote:
> That is exactly what I’m doing. I am generating a VS solution, and
> inside that I setup the debugging environment, but the process I want
> to debug is not the VS solution generation, but the NMake Makefile
> generation process.

Okay, misread your original message.  I've never actually tried that.

> What should I put inside the Environment dialog to make things work?
> Even when it’s empty, it finds cl.exe, but cmake fails trying to use it.

Add "VERBOSE=1" to the environment to get a little more output about
the "RC Pass 1 failed to run" failure.

-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] Debug through config/gen inside Visual Studio

[Mate Nagy-Egri via cmake-developers]

Apologies, there is one important moment I failed mention. If I do not set any 
env vars for the debugger, cmake still finds cl.exe with the „NMake Makefiles” 
generator, which clearly states that it is not a clean user environment I get 
inside the debugger.


Feladó: csiga.b...@aol.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

[cmake-developers] Debug through config/gen inside Visual Studio

[Mate Nagy-Egri via cmake-developers]

Hi everyone!

I wanted to see how CMake actually Works under the covers to see how much 
actual work it would take to implement a feature I proposed quite a while ago. 
My problem is that even though I built CMake with the  „Visual Studio 14 2015 
Win64” generator, I setup the cmake target to use:

Command Arguments: -G "NMake Makefiles" 
C:\Users\Matty\OneDrive\Develop\Tests\CMake\CMake_example
Working Directory: C:\Users\Matty\Build\CMake_Example\NMake

There is even an option to create new environtment variables prior to 
debugging. My problem is that even though I checked what vcvarsall.bat creates 
on the command line, I exported the same variables, but the compiler fails 
according to CMake (see at the end).

How do you setup Visual Studio to debug through a config/gen process?

Thanks in advance,
Máté


-- The C compiler identification is MSVC 19.0.24213.1
-- The CXX compiler identification is MSVC 19.0.24213.1
-- Check for working C compiler: C:/Kellekek/Microsoft/Visual 
Studio/14.0/VC/bin/amd64/cl.exe
-- Check for working C compiler: C:/Kellekek/Microsoft/Visual 
Studio/14.0/VC/bin/amd64/cl.exe -- broken
CMake Error at 
C:/Users/Matty/Source/Repos/CMake/Modules/CMakeTestCCompiler.cmake:61 (message):
  The C compiler "C:/Kellekek/Microsoft/Visual
  Studio/14.0/VC/bin/amd64/cl.exe" is not able to compile a simple test
  program.

  It fails with the following output:

   Change Dir: C:/Users/Matty/Build/CMake_Example/NMake/CMakeFiles/CMakeTmp



  Run Build Command:"nmake" "/NOLOGO" "cmTC_064d4\fast"

"C:\Kellekek\Microsoft\Visual Studio\14.0\VC\bin\amd64\nmake.exe" -f
  CMakeFiles\cmTC_064d4.dir\build.make /nologo -L
  CMakeFiles\cmTC_064d4.dir\build

  Building C object CMakeFiles/cmTC_064d4.dir/testCCompiler.c.obj

C:\Kellekek\MICROS~1\VISUAL~1\14.0\VC\bin\amd64\cl.exe
  @C:\Users\Matty\AppData\Local\Temp\nmBF98.tmp

  testCCompiler.c

  Linking C executable cmTC_064d4.exe

C:\Users\Matty\Build\CMake\VS14\bin\Debug\cmake.exe -E vs_link_exe
  --intdir=CMakeFiles\cmTC_064d4.dir --manifests --
  C:\Kellekek\MICROS~1\VISUAL~1\14.0\VC\bin\amd64\link.exe /nologo
  @CMakeFiles\cmTC_064d4.dir\objects1.rsp
  @C:\Users\Matty\AppData\Local\Temp\nmC1FA.tmp

  RC Pass 1 failed to run.

  NMAKE : fatal error U1077:
  'C:\Users\Matty\Build\CMake\VS14\bin\Debug\cmake.exe' : return code
  '0x'

  Stop.

  NMAKE : fatal error U1077: '"C:\Kellekek\Microsoft\Visual
  Studio\14.0\VC\bin\amd64\nmake.exe"' : return code '0x2'

  Stop.





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:5 (project)


-- Configuring incomplete, errors occurred!
See also "C:/Users/Matty/Build/CMake_Example/NMake/CMakeFiles/CMakeOutput.log".
See also "C:/Users/Matty/Build/CMake_Example/NMake/CMakeFiles/CMakeError.log".
Press any key to continue . . .

-- 

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