[Cmake-commits] CMake branch, master, updated. v3.11.1-707-g7489d9c

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  7489d9cb241f199471499e0952a13ea48fec1f9e (commit)
  from  dfc692342831186053bd385605c8a21239e2e77d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7489d9cb241f199471499e0952a13ea48fec1f9e
commit 7489d9cb241f199471499e0952a13ea48fec1f9e
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Mon May 7 00:01:08 2018 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Mon May 7 00:01:08 2018 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index c439e9e..cacaaa0 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 11)
-set(CMake_VERSION_PATCH 20180506)
+set(CMake_VERSION_PATCH 20180507)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] Experiments in CMake support for Clang (header & standard) modules

[David Blaikie]

On Mon, Apr 30, 2018 at 3:30 PM Stephen Kelly  wrote:

> On 04/20/2018 01:39 AM, David Blaikie wrote:
>
> Hi there,
>
> I'm experimenting with creating examples (& potential changes to CMake
> itself, if needed/useful) of building clang modules (currently using the
> semi-backwards compatible "header modules", with the intent of also/moving
> towards supporting pre-standard C++ modules in development in Clang).
>
>
> Great! Thanks for reaching out. Sorry it has taken me a while to respond.
>

No worries - thanks for getting back to me!


> Have you had other response off-list?
>

Nah - chatted a little with coworkers (fellow Clang/LLVM developers -
mostly Richard Smith & Chandler Carruth) off-list, but nothing much more.

> The basic commands required are:
>
>   clang++ -fmodules -xc++ -Xclang -emit-module -Xclang -fmodules-codegen
> -fmodule-name=foo foo.modulemap -o foo.pcm
>   clang++ -fmodules -c -fmodule-file=foo.pcm use.cpp
>   clang++ -c foo.pcm
>   clang++ foo.o use.o -o a.out
>
>
> Ok. Fundamentally, I am suspicious of having to have a
> -fmodule-file=foo.pcm for every 'import foo' in each cpp file. I shouldn't
> have to manually add that each time I add a new import to my cpp file. Even
> if it can be automated (eg by CMake), I shouldn't have to have my
> buildsystem be regenerated each time I add an import to my cpp file either.
>
> That's something I mentioned in the google groups post I made which you
> linked to. How will that work when using Qt or any other library?
>

- My understanding/feeling is that this would be similar to how a user has
to change their link command when they pick up a new dependency.

Nope, scratch that ^ I had thought that was the case, but talking more with
Richard Smith it seems there's an expectation that modules will be
somewhere between header and library granularity (obviously some small
libraries today have one or only a few headers, some (like Qt) have many -
maybe those on the Qt end might have slightly fewer modules than the have
headers - but still several modules to one library most likely, by the
sounds of it)


Now, admittedly, external dependencies are a little more complicated than
internal (within a single project consisting of multiple libraries) - which
is why I'd like to focus a bit on the simpler internal case first.


> Today, a beginner can find a random C++ book, type in a code example from
> chapter one and put `g++ -I/opt/book_examples prog1.cpp` into a terminal
> and get something compiling and running. With modules, they'll potentially
> have to pass a whole list of module files too.
>

Yeah, there's some talk of supporting a mode that doesn't explicitly
build/use modules in the filesystem, but only in memory for the purpose of
preserving the isolation semantics of modules. This would be used in simple
direct-compilation cases like this. Such a library might need a
configuration file or similar the compiler can parse to discover the
parameters (warning flags, define flags, whatever else) needed to build the
BMI.


> Lots of people manually maintain Makefile-based buildsystems today, and
> most other companies I've been inside of have their own custom tool or
> bunch of python scripts, or both. Manually changing such buildsystems to
> add -fmodule-file or -fmodule-map-file each time an import is added is a
> significant barrier.
>
> Will my project have to compile the modules files for all of my
> dependencies?
>

Yes - and that's where the external dependencies get complicated.


> Even more complication for my buildsystem. Do I have to wait for my
> dependencies to modularize bottom-up before I can benefit from modules?
>

There are some ideas about how to handle that ('legacy headers'/modules in
Richard's work/proposed amendment to the TS), but I'm trying to focus on a
few of the simpler cases first.


> If my dependency does add 'module foo' to their header files, or whatever
> the current syntax is, can I continue to #include  or is that a source
> incompatible change?
>

I believe it'd be a source incompatible change. You could continue to
provide a header for your module separately. They'd likely have different
extensions anyway.


> I raised some of these issues a few years ago regarding the clang
> implementation with files named exactly module.modulemap:
>
>
> http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946.html
>
>
> http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946i20.html
>
> Interestingly, GCC is taking a directory-centric approach in the driver
> (-fmodule-path=) as opposed to the 'add a file to your compile line
> for each import' that Clang and MSVC are taking:
>
>  http://gcc.gnu.org/wiki/cxx-modules
>
> Why is Clang not doing a directory-centric driver-interface? It seems to
> obviously solve problems. I wonder if modules can be a success without
> coordination between major compiler and buildsystem developers. That's 

Re: [CMake] -std=c++17 vs -std=c++1y

[Andrew Brownsword]

Well, I am specifying:

set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_EXTENSIONS ON)

and the compiler line contains “-std=gnu++1y”.  I’m using a very recent source 
build of CLang and libc++.  Any idea why cmake would fall back to 1y in this 
case?





> On May 6, 2018, at 9:05 AM, Jean-Michaël Celerier 
>  wrote:
> 
> Note that c++17 is c++1z. c++1y was C++14.
> 
> 
> 
> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name 
> On Sun, May 6, 2018 at 5:00 PM, Andrew Brownsword 
> > wrote:
> Hi,
> 
> Is there a way to get cmake 3.11 to emit 17 vs 1y when setting 
> CMAKE_CXX_STANDARD?  I’m finding that it seems to be a common practice to use 
> the value of the preprocessor define __cplusplus (which is a date), and the 
> value differs depending on whether 17 or 1y is used (at least with CLang).  I 
> haven’t figured out how to get cmake to emit -std=c++17, it always seems to 
> use 1y, which is causing problems with code that assumes the __cplusplus date 
> reflects the c++17 standardization date.
> 
> Thanks,
>Andrew
> 
> -- 
> 
> 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] -std=c++17 vs -std=c++1y

[Jean-Michaël Celerier]

Note that c++17 is c++1z. c++1y was C++14.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sun, May 6, 2018 at 5:00 PM, Andrew Brownsword <
andrew.e.brownsw...@gmail.com> wrote:

> Hi,
>
> Is there a way to get cmake 3.11 to emit 17 vs 1y when setting
> CMAKE_CXX_STANDARD?  I’m finding that it seems to be a common practice to
> use the value of the preprocessor define __cplusplus (which is a date), and
> the value differs depending on whether 17 or 1y is used (at least with
> CLang).  I haven’t figured out how to get cmake to emit -std=c++17, it
> always seems to use 1y, which is causing problems with code that assumes
> the __cplusplus date reflects the c++17 standardization date.
>
> Thanks,
>Andrew
>
> --
>
> 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] -std=c++17 vs -std=c++1y

[Rolf Eike Beer]

Am Sonntag, 6. Mai 2018, 08:00:14 schrieb Andrew Brownsword:
> Hi,
> 
> Is there a way to get cmake 3.11 to emit 17 vs 1y when setting
> CMAKE_CXX_STANDARD?  I’m finding that it seems to be a common practice to
> use the value of the preprocessor define __cplusplus (which is a date), and
> the value differs depending on whether 17 or 1y is used (at least with
> CLang).  I haven’t figured out how to get cmake to emit -std=c++17, it
> always seems to use 1y, which is causing problems with code that assumes
> the __cplusplus date reflects the c++17 standardization date.

My bet is: that code is wrong. For every compiler I have seen the rules have 
been:

-std=c++AA is used as long as the standard is not fixed

-afterwards std=c++YY is introduced, and -std=c++AA is an alias for that

So it does not matter which flag you use when the compiler supports both, but 
you can't of course properly test on the value of __cplusplus in older 
compilers because you don't know in which year/month the standard will be 
released.

Eike

signature.asc
Description: This is a digitally signed message part.
-- 

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] -std=c++17 vs -std=c++1y

[Andrew Brownsword]

Hi,

Is there a way to get cmake 3.11 to emit 17 vs 1y when setting 
CMAKE_CXX_STANDARD?  I’m finding that it seems to be a common practice to use 
the value of the preprocessor define __cplusplus (which is a date), and the 
value differs depending on whether 17 or 1y is used (at least with CLang).  I 
haven’t figured out how to get cmake to emit -std=c++17, it always seems to use 
1y, which is causing problems with code that assumes the __cplusplus date 
reflects the c++17 standardization date.

Thanks,
   Andrew

-- 

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-commits] CMake branch, master, updated. v3.11.1-706-gdfc6923

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  dfc692342831186053bd385605c8a21239e2e77d (commit)
   via  a01c6e99218540f6e924afd3e855e6db9af76708 (commit)
  from  c97189f9d1f98f357be179d7260e3f91431d72e1 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dfc692342831186053bd385605c8a21239e2e77d
commit dfc692342831186053bd385605c8a21239e2e77d
Merge: c97189f a01c6e9
Author: Craig Scott 
AuthorDate: Sun May 6 11:14:29 2018 +
Commit: Kitware Robot 
CommitDate: Sun May 6 07:14:54 2018 -0400

Merge topic 'cpack_module_indentation_fix'

a01c6e9921 CPack: Fix indentation

Acked-by: Kitware Robot 
Merge-request: !2041


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a01c6e99218540f6e924afd3e855e6db9af76708
commit a01c6e99218540f6e924afd3e855e6db9af76708
Author: Craig Scott 
AuthorDate: Sat May 5 09:48:25 2018 +1000
Commit: Craig Scott 
CommitDate: Sat May 5 09:48:25 2018 +1000

CPack: Fix indentation

Addresses indentation not matching guidelines, missed in !2020.
No functional changes and no changes to docs.

diff --git a/Modules/CPack.cmake b/Modules/CPack.cmake
index 720b972..f6d74c5 100644
--- a/Modules/CPack.cmake
+++ b/Modules/CPack.cmake
@@ -388,26 +388,26 @@ endfunction()
 # Set the package name
 _cpack_set_default(CPACK_PACKAGE_NAME "${CMAKE_PROJECT_NAME}")
 if(CMAKE_PROJECT_VERSION_MAJOR)
-_cpack_set_default(CPACK_PACKAGE_VERSION_MAJOR 
"${CMAKE_PROJECT_VERSION_MAJOR}")
-if(CMAKE_PROJECT_VERSION_MINOR)
-_cpack_set_default(CPACK_PACKAGE_VERSION_MINOR 
"${CMAKE_PROJECT_VERSION_MINOR}")
-if(CMAKE_PROJECT_VERSION_PATCH)
-_cpack_set_default(CPACK_PACKAGE_VERSION_PATCH 
"${CMAKE_PROJECT_VERSION_PATCH}")
-_cpack_set_default(CPACK_PACKAGE_VERSION
-
"${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
-else()
-_cpack_set_default(CPACK_PACKAGE_VERSION
-"${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}")
-endif()
+  _cpack_set_default(CPACK_PACKAGE_VERSION_MAJOR 
"${CMAKE_PROJECT_VERSION_MAJOR}")
+  if(CMAKE_PROJECT_VERSION_MINOR)
+_cpack_set_default(CPACK_PACKAGE_VERSION_MINOR 
"${CMAKE_PROJECT_VERSION_MINOR}")
+if(CMAKE_PROJECT_VERSION_PATCH)
+  _cpack_set_default(CPACK_PACKAGE_VERSION_PATCH 
"${CMAKE_PROJECT_VERSION_PATCH}")
+  _cpack_set_default(CPACK_PACKAGE_VERSION
+
"${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
 else()
-_cpack_set_default(CPACK_PACKAGE_VERSION 
"${CPACK_PACKAGE_VERSION_MAJOR}")
+  _cpack_set_default(CPACK_PACKAGE_VERSION
+  "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}")
 endif()
+  else()
+_cpack_set_default(CPACK_PACKAGE_VERSION "${CPACK_PACKAGE_VERSION_MAJOR}")
+  endif()
 else()
-_cpack_set_default(CPACK_PACKAGE_VERSION_MAJOR "0")
-_cpack_set_default(CPACK_PACKAGE_VERSION_MINOR "1")
-_cpack_set_default(CPACK_PACKAGE_VERSION_PATCH "1")
-_cpack_set_default(CPACK_PACKAGE_VERSION
-
"${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
+  _cpack_set_default(CPACK_PACKAGE_VERSION_MAJOR "0")
+  _cpack_set_default(CPACK_PACKAGE_VERSION_MINOR "1")
+  _cpack_set_default(CPACK_PACKAGE_VERSION_PATCH "1")
+  _cpack_set_default(CPACK_PACKAGE_VERSION
+
"${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
 endif()
 _cpack_set_default(CPACK_PACKAGE_VENDOR "Humanity")
 if(CMAKE_PROJECT_DESCRIPTION)

---

Summary of changes:
 Modules/CPack.cmake |   34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits