[Cmake-commits] CMake branch, master, updated. v3.10.2-842-gab1be08

[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  ab1be0891333e1d623c7d561879b2ce26368de83 (commit)
  from  927c6035745bb732712463af8e3d6619c5b6b1f4 (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=ab1be0891333e1d623c7d561879b2ce26368de83
commit ab1be0891333e1d623c7d561879b2ce26368de83
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sat Jan 20 00:01:11 2018 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sat Jan 20 00:01:11 2018 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 353ee61..89f6eea 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 10)
-set(CMake_VERSION_PATCH 20180119)
+set(CMake_VERSION_PATCH 20180120)
 #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] Recommandation for macOS framework install rules

[Lucas Soltic]

Hello,
Should I conclude that there are no recommendations?

Best regards,
Lucas

> Le 17 janv. 2018 à 23:49, Lucas Soltic  a écrit :
> 
> Hello,
> 
> By default library install() command uses CMAKE_INSTALL_PREFIX (/usr/local by 
> default) as a base for relative install paths. But when you define install 
> rules for macOS frameworks, it doesn't make much sense to install them there. 
> I'd rather expect something like /Library/Frameworks.
> 
> On the other side, if you have more things to install like a "readme" or 
> documentation that should go into /usr/local/share, it doesn't make sense to 
> have them installed in /Library/Frameworks. So you can't just change 
> CMAKE_INSTALL_PREFIX to be /Library/Frameworks.
> 
> What do you recommend to keep installation rules simple (ie. remain relative) 
> and yet support installation of both frameworks and other things?
> 
> Best regards,
> Lucas
> -- 
> 
> 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] how to detect architecture ?

[Konstantin Tokarev]

19.01.2018, 21:22, "Chuck Atkins" :
> Hi Franck,
>
> I'd suggest going a little more robust by using both 
> CMAKE_SHARED_LIBRARY_PREFIX and CMAKE_SHARED_LIBRARY_SUFFIX to generate a 
> function at configure time to resolve the correct filename.
>
> For example, util.h.in:
>
> #ifndef _UTIL_H_
> #define _UTIL_H_
>
> #include 
>
> static inline
> void get_library_filename(char* filename, const char* libname)
> {
>   sprintf(filename, 
> "@CMAKE_SHARED_LIBRARY_PREFIX@%s@CMAKE_SHARED_LIBRARY_SUFFIX@", libname);
> }
>
> #endif /* _UTIL_H_ */
>
> Then your CMakeLists.txt:
>
> configure_file(
>   ${CMAKE_CURRENT_SOURCE_DIR}/util.h.in
>   ${CMAKE_CURRENT_BINARY_DIR}/util.h
>   @ONLY
> )
> add_executable(foo main.c ${CMAKE_CURRENT_BINARY_DIR}/util.h)
> target_include_directories(foo PRIVATE ${CMAKE_CURRENT_BINARY_DIR})
>
> And finally main.c:
>
> #include 
> #include 
>
> int main(int argc, char **argv)
> {
>   char filename[256];
>
>   get_library_filename(filename, "foo");
>
>   printf("Library foo uses file %s\n", filename);
>
>   return 0;
> }
>
> This will give you "libfoo.so" on Linux, "libfoo.dylib" on Apple, and 
> "foo.dll" on Windows.

Note that Windows DLLs may also happen to have to lib prefix (e.g. CMake adds 
them
by default when building projects with MinGW).

>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
> On Tue, Jan 9, 2018 at 10:04 AM, Franck Houssen  
> wrote:
>> Thanks !
>>
>> - Mail original -
>>> De: "Konstantin Tokarev" 
>>> À: "Franck Houssen" , "CMake Mail List" 
>>> 
>>> Envoyé: Mardi 9 Janvier 2018 16:00:55
>>> Objet: Re: [CMake] how to detect architecture ?
>>>
>>>
>>>
>>> 09.01.2018, 17:58, "Franck Houssen" :
>>> > Is there a way to detect architecture ?
>>> >
>>> > Seems there is nothing simple since these old threads :
>>> > https://stackoverflow.com/questions/11944060/how-to-detect-target-architecture-using-cmake/12024211#12024211
>>> > https://stackoverflow.com/questions/16796629/cmake-create-architecture-aware-makefile
>>> >
>>> > Is there a solution now ?
>>> >
>>> > My need is quite simple: I have an executable who needs dlopen. To test 
>>> > it,
>>> > I planned to write a bash script that would have done "./exe
>>> > /path/to/lib.so" on linux (debian, ...) OR "./exe /path/to/lib.dylib" on
>>> > osx. To replace correctly so/dylib in the bash script I need to know the
>>> > architecture. Any idea how to do this ?
>>>
>>> ${CMAKE_SHARED_LIBRARY_SUFFIX}
>>>
>>
>> Oh man ! Didn't know this one : exactly what I was looking for
>>
>>> > Franck
>>> > ,--
>>> >
>>> > 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
>>>
>>>
>>> --
>>> Regards,
>>> Konstantin
>>>
>> --
>>
>> 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


-- 
Regards,
Konstantin
-- 

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] Space after CMAKE_LINK_LIBRARY_FILE_FLAG

[Elexa Petr]

Hello,

I am trying to add support for Renesas CCRX compiler by creating a platform 
file.

I have come across a problem where I try to set the 
CMAKE_LINK_LIBRARY_FILE_FLAG to "-library=" a space is added after the flag by 
CMake. Which is not the case with CMAKE_INCLUDE_FLAG_ variable.

Example command produced to link executable (notice the space between equals 
sign and path to a library):
rlink -nologo -library= path_to_some_lib_a.lib -library= path_to_some_lib_b.lib 
-form=stype -output=myprogram.mot some_object_file.obj

but I need it to look like this:
rlink -nologo -library=path_to_some_lib_a.lib -library=path_to_some_lib_b.lib 
-form=stype -output=myprogram.mot some_object_file.obj

Is there a way to tell the cmake to not put the space there? Or any other way 
to do it?

Thank you.
-- 

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] how to detect architecture ?

[Chuck Atkins]

Hi Franck,

I'd suggest going a little more robust by using both
CMAKE_SHARED_LIBRARY_PREFIX and CMAKE_SHARED_LIBRARY_SUFFIX to generate a
function at configure time to resolve the correct filename.

For example, util.h.in:

#ifndef _UTIL_H_
#define _UTIL_H_

#include 

static inline
void get_library_filename(char* filename, const char* libname)
{
  sprintf(filename, "@CMAKE_SHARED_LIBRARY_PREFIX@
%s@CMAKE_SHARED_LIBRARY_SUFFIX@", libname);
}

#endif /* _UTIL_H_ */


Then your CMakeLists.txt:

configure_file(
  ${CMAKE_CURRENT_SOURCE_DIR}/util.h.in
  ${CMAKE_CURRENT_BINARY_DIR}/util.h
  @ONLY
)
add_executable(foo main.c ${CMAKE_CURRENT_BINARY_DIR}/util.h)
target_include_directories(foo PRIVATE ${CMAKE_CURRENT_BINARY_DIR})

And finally main.c:

#include 
#include 

int main(int argc, char **argv)
{
  char filename[256];

  get_library_filename(filename, "foo");

  printf("Library foo uses file %s\n", filename);

  return 0;
}

This will give you "libfoo.so" on Linux, "libfoo.dylib" on Apple, and "
foo.dll" on Windows.


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Tue, Jan 9, 2018 at 10:04 AM, Franck Houssen 
wrote:

> Thanks !
>
> - Mail original -
> > De: "Konstantin Tokarev" 
> > À: "Franck Houssen" , "CMake Mail List" <
> cmake@cmake.org>
> > Envoyé: Mardi 9 Janvier 2018 16:00:55
> > Objet: Re: [CMake] how to detect architecture ?
> >
> >
> >
> > 09.01.2018, 17:58, "Franck Houssen" :
> > > Is there a way to detect architecture ?
> > >
> > > Seems there is nothing simple since these old threads :
> > > https://stackoverflow.com/questions/11944060/how-to-
> detect-target-architecture-using-cmake/12024211#12024211
> > > https://stackoverflow.com/questions/16796629/cmake-
> create-architecture-aware-makefile
> > >
> > > Is there a solution now ?
> > >
> > > My need is quite simple: I have an executable who needs dlopen. To
> test it,
> > > I planned to write a bash script that would have done "./exe
> > > /path/to/lib.so" on linux (debian, ...) OR "./exe /path/to/lib.dylib"
> on
> > > osx. To replace correctly so/dylib in the bash script I need to know
> the
> > > architecture. Any idea how to do this ?
> >
> > ${CMAKE_SHARED_LIBRARY_SUFFIX}
> >
>
> Oh man ! Didn't know this one : exactly what I was looking for
>
> > > Franck
> > > ,--
> > >
> > > 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
> >
> >
> > --
> > Regards,
> > Konstantin
> >
> --
>
> 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] CDash calendar button no longer works?

[Thompson, KT]

Zack,

Thanks for responding.

I agree that the broken calendar behavior is strange.  My CDash calendar 
stopped working after some RHEL7 system patches were installed.  I'm not the 
admin of the machine, so I don't have the details.  However, everyone who uses 
my CDash server sees the same problem.

My Java console prints these messages when I refresh the page:

VM15408:1 XHR finished loading: GET 
"https://rtt.lanl.gov/cdash/build/views/partials/header_2.5.0.html;.
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:45.214 VM15408:1 XHR finished loading: GET 
"https://rtt.lanl.gov/cdash/build/views/partials/footer_2.5.0.html;.
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:45.288 angular.js:10770 [Violation] 'load' handler took 255ms
09:07:45.751 VM15408:1 XHR finished loading: GET 
"https://rtt.lanl.gov/cdash/api/v1/index.php?date=2018-01-19==Jayenne;.
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:45.829 VM15408:1 XHR finished loading: GET 
"https://rtt.lanl.gov/cdash/views/partials/header.html;.
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
done @ angular.js:12210
completeRequest @ angular.js:12436
xhr.onload @ angular.js:12364
XMLHttpRequest.send (async)
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:45.833 VM15408:1 XHR finished loading: GET 
"https://rtt.lanl.gov/cdash/views/partials/footer.html;.
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
done @ angular.js:12210
completeRequest @ angular.js:12436
xhr.onload @ angular.js:12364
XMLHttpRequest.send (async)
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
(anonymous) @ angular.js:1841
invoke @ angular.js:4842
doBootstrap @ angular.js:1839
bootstrap @ angular.js:1859
angularInit @ angular.js:1744
(anonymous) @ angular.js:32977
fire @ jquery-1.10.2.js:3048
fireWith @ jquery-1.10.2.js:3160
ready @ jquery-1.10.2.js:433
completed @ jquery-1.10.2.js:104
09:07:45.837 VM15408:1 XHR finished loading: GET 
"https://rtt.lanl.gov/cdash/build/views/partials/filterdataTemplate_2.5.0.html;.
(anonymous) @ VM15408:1
(anonymous) @ angular.js:12410
sendReq @ angular.js:12155
serverRequest @ angular.js:11908
processQueue @ angular.js:16648
(anonymous) @ angular.js:16692
$eval @ angular.js:17972
$digest @ angular.js:17786
$apply @ angular.js:18080
done @ angular.js:12210
completeRequest @ angular.js:12436
xhr.onload @ angular.js:12364

Re: [CMake] Building cmake: why is openssl linked?

[Paul Smith]

On Sun, 2018-01-14 at 01:08 +0100, Jean-Michaël Celerier wrote:
> https://cmake.org/cmake/help/latest/module/ExternalProject.html
> 
> since CMake can download stuff, it needs to support https, hence SSL,
> hence OpenSSL

OK, thanks.

Does anyone know if there is way to convince CMake to use a decent SSL
library, like libressl or something, rather than the really horribly
managed openssl?

In the meantime I'll omit support for this in my builds of cmake, since
I don't actually use that feature.

-- 

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.10.2-841-g927c603

[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  927c6035745bb732712463af8e3d6619c5b6b1f4 (commit)
   via  e68a269cd2d3f402271cb3ed930a4d11551c1e76 (commit)
   via  c2aec68333e2d75e41c1b2bd7897e0563dac3e11 (commit)
   via  c42b377c298af131ca4dbc120538aec1a56ff4be (commit)
   via  a9c483071eb8a5b5da38726f42be98a2392f7a7f (commit)
  from  be2f0509037880a94f487867bee088a231054f4b (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=927c6035745bb732712463af8e3d6619c5b6b1f4
commit 927c6035745bb732712463af8e3d6619c5b6b1f4
Merge: e68a269 c2aec68
Author: Brad King 
AuthorDate: Fri Jan 19 15:08:16 2018 +
Commit: Kitware Robot 
CommitDate: Fri Jan 19 10:08:42 2018 -0500

Merge topic 'FindOpenGL-fix-typo'

c2aec683 FindOpenGL: remove duplicate OpenGL::GL reference

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e68a269cd2d3f402271cb3ed930a4d11551c1e76
commit e68a269cd2d3f402271cb3ed930a4d11551c1e76
Merge: be2f050 c42b377
Author: Brad King 
AuthorDate: Fri Jan 19 15:08:00 2018 +
Commit: Kitware Robot 
CommitDate: Fri Jan 19 10:08:06 2018 -0500

Merge topic 'cache-truncate-newlines'

c42b377c cmCacheManager: Test and document newline truncation behavior
a9c48307 cmCacheManager: Truncate values containing newlines

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c2aec68333e2d75e41c1b2bd7897e0563dac3e11
commit c2aec68333e2d75e41c1b2bd7897e0563dac3e11
Author: Ben Boeckel 
AuthorDate: Wed Jan 17 13:47:58 2018 -0500
Commit: Ben Boeckel 
CommitDate: Thu Jan 18 11:10:13 2018 -0500

FindOpenGL: remove duplicate OpenGL::GL reference

diff --git a/Modules/FindOpenGL.cmake b/Modules/FindOpenGL.cmake
index 9ccd46b..4d0786c 100644
--- a/Modules/FindOpenGL.cmake
+++ b/Modules/FindOpenGL.cmake
@@ -22,7 +22,6 @@
 #  Defined to the platform-specific OpenGL libraries if the system has OpenGL.
 # ``OpenGL::OpenGL``
 #  Defined to libOpenGL if the system is GLVND-based.
-#  ``OpenGL::GL``
 # ``OpenGL::GLU``
 #  Defined if the system has GLU.
 # ``OpenGL::GLX``

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c42b377c298af131ca4dbc120538aec1a56ff4be
commit c42b377c298af131ca4dbc120538aec1a56ff4be
Author: Kyle Edwards 
AuthorDate: Wed Jan 10 10:43:42 2018 -0500
Commit: Kyle Edwards 
CommitDate: Mon Jan 15 09:28:32 2018 -0500

cmCacheManager: Test and document newline truncation behavior

diff --git a/Help/release/dev/cache-newline.rst 
b/Help/release/dev/cache-newline.rst
new file mode 100644
index 000..96900bb
--- /dev/null
+++ b/Help/release/dev/cache-newline.rst
@@ -0,0 +1,7 @@
+cache-newline
+-
+
+* Variables containing newlines in their values now get truncated before the
+  newline when they are written to the cache file. In addition, a warning
+  comment is written to the cache file, and a warning message is displayed to
+  the user on the console.
diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt
index 8eb8568..f0cf88e 100644
--- a/Tests/RunCMake/CMakeLists.txt
+++ b/Tests/RunCMake/CMakeLists.txt
@@ -339,6 +339,7 @@ add_RunCMake_test(CPackInstallProperties)
 add_RunCMake_test(ExternalProject)
 add_RunCMake_test(FetchContent)
 add_RunCMake_test(CTestCommandLine)
+add_RunCMake_test(CacheNewline)
 # Only run this test on unix platforms that support
 # symbolic links
 if(UNIX)
diff --git a/Tests/RunCMake/CacheNewline/CMakeLists.txt 
b/Tests/RunCMake/CacheNewline/CMakeLists.txt
new file mode 100644
index 000..93ee9df
--- /dev/null
+++ b/Tests/RunCMake/CacheNewline/CMakeLists.txt
@@ -0,0 +1,3 @@
+cmake_minimum_required(VERSION 3.5)
+project(${RunCMake_TEST} NONE)
+include(${RunCMake_TEST}.cmake)
diff --git a/Tests/RunCMake/CacheNewline/CacheNewline-check.cmake 
b/Tests/RunCMake/CacheNewline/CacheNewline-check.cmake
new file mode 100644
index 000..6534f63
--- /dev/null
+++ b/Tests/RunCMake/CacheNewline/CacheNewline-check.cmake
@@ -0,0 +1,16 @@
+set(CACHE_EXPECTED_FILE "${RunCMake_TEST_SOURCE_DIR}/cache-regex.txt")
+set(CACHE_ACTUAL_FILE 
"${RunCMake_BINARY_DIR}/CacheNewline-build/CMakeCache.txt")
+
+file(READ ${CACHE_EXPECTED_FILE} CACHE_EXPECTED)
+string(REGEX REPLACE "\r\n" "\n" CACHE_EXPECTED "${CACHE_EXPECTED}")
+string(REGEX REPLACE 

Re: [cmake-developers] CMAKE :: mingw make files with response file for includes

[Jayakumar, Lenindarbi]

Thanks for the reply.

It is not compiler and linker.
I have to use response file for both includes and objects.
Tasking compiler expects -f as Response file link flag for both. But cmake 
produces command line for objects using -f and includes using @.

I prefer to get it fixed in generator. Unfortunately I don't have enough time 
and experience.
Perhaps an cmake expert could confirm and fix it.

Possible cause:
The @ symbol is hardcoded in "cmMakefileTargetGenerator::AddIncludeFlags" 
function in file ../Source/cmMakefileTargetGenerator.cxx

  if (useResponseFile) {
std::string name = "includes_";
name += lang;
name += ".rsp";
std::string arg = "@" +
  this->CreateResponseFile(name.c_str(), includeFlags,
   this->FlagFileDepends[lang]);
this->LocalGenerator->AppendFlags(flags, arg);
  }

However, the implementation should be like in 
"cmMakefileTargetGenerator::CreateObjectLists" function.

// Lookup the response file reference flag.
std::string responseFlagVar = "CMAKE_";
responseFlagVar +=
  this->GeneratorTarget->GetLinkerLanguage(this->ConfigName);
responseFlagVar += "_RESPONSE_FILE_LINK_FLAG";
const char* responseFlag = this->Makefile->GetDefinition(responseFlagVar);
if (!responseFlag) {
  responseFlag = "@";
}

Thanks,
Lenin

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Freitag, 19. Januar 2018 15:01
To: Jayakumar, Lenindarbi ; 
cmake-developers@cmake.org
Subject: Re: [cmake-developers] CMAKE :: mingw make files with response file 
for includes

On 01/17/2018 03:52 AM, Jayakumar, Lenindarbi wrote:
> Response file link flag "CMAKE_C_RESPONSE_FILE_LINK_FLAG" is not 
> customizable for include paths.
> The @ symbol is hardcoded in "cmMakefileTargetGenerator::AddIncludeFlags"

In case the compiler and link driver want different response file flags, one 
could add a separate "CMAKE__RESPONSE_FILE_COMPILE_FLAG" variable to use 
for include flags.  See

  https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst

for contribution instructions if you'd like to work on it.

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [CMake] CDash calendar button no longer works?

[Zack Galbreath]

On Wed, Jan 17, 2018 at 4:02 PM, Thompson, KT  wrote:

> Hi,
>
>
>
> The 'calendar' button in our CDash installation (v. 2.5.0) stopped working
> recently (no changes to our CDash installation and only regular security
> patches to the web server).  Everything else works fine.  Does anyone have
> any ideas on how to diagnose why my calendar no longer works?
>

The fact that this happened without a CDash upgrade is quite mysterious.
Does your web browser throw any JavaScript errors when you click the
Calendar button? You can check by opening the JavaScript console. On
Chrome, this can be accessed as View -> Developer -> JavaScript Console.
-- 

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-developers] XXX_FLAGS_INIT applied inconsistently

[Brad King]

On 01/19/2018 07:30 AM, Craig Scott wrote:
> * In most cases, the various files are appending rather than prepending
> to the existing contents of the XXX_FLAGS_INIT variables.

It was once just setting them.  The `_INIT` variables were not originally
meant to be set by project code or toolchain files at all.  Only recently
did we switch to appending and document them for toolchain files.  The
intended purpose is to accumulate *independent* flags from various sources
of knowledge.

Users can set the `XXX_FLAGS` cache entries directly to override whatever
CMake would initialize them to.  Once they are set the `_INIT` variables
are ignored.

> * Some platforms and compilers (e.g. IRIX, Windows-df, Generic-SDCC-C,
> OSF1, CSharp flags) unilaterally set XXX_FLAGS_INIT variables.
> This would discard any values a developer might set in a toolchain file,
> for example.

These are leftovers that were never converted to the append approach.
IRIX, OSF1, and Windows-df haven't been used in years AFAIK and could
likely be removed.  Otherwise, see above.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Cannot control the name of dependfile set in Ninja generator

[Brad King]

On 01/17/2018 04:14 PM, Claus Klein wrote:
> 1.) Is ist possible to change the object or/and the dependency file
> name generated for ninja?

No one has needed to before because currently-supported compilers all
have options to specify the output file name.

> 2.) Why generates cmake the objectname as sourcefilename.{c,cpp}.obj?

We support adding `src.c` and `src.cxx` together.  The object file
names need to be distinct.

> WindRiver sets the dep file name to objectDir/SourceName.d, so the ".obj"
> in "DEP_FILE = path/BaseName.c.obj.d" must be removed
> Armcc just uses base name in the same directory as the command runs,
> "BaseName.d".

Possible approaches to deal with this include:

* Extend the Ninja generator with settings to tell it about the above
  names.

* Set `CMAKE__COMPILE_OBJECT` to contain a follow-up command
  after compiling to rename the compiler-produced depfile and move
  it to where Ninja wants to see it.

Either way there could be problems with source files with the same base
name compiling at the same time and overwriting each other's depfiles.
Ideally the compilers should be fixed instead.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMAKE :: mingw make files with response file for includes

[Brad King]

On 01/17/2018 03:52 AM, Jayakumar, Lenindarbi wrote:
> Response file link flag “CMAKE_C_RESPONSE_FILE_LINK_FLAG” is not customizable
> for include paths.
> The @ symbol is hardcoded in “cmMakefileTargetGenerator::AddIncludeFlags”

In case the compiler and link driver want different response file flags,
one could add a separate "CMAKE__RESPONSE_FILE_COMPILE_FLAG" variable
to use for include flags.  See

  https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst

for contribution instructions if you'd like to work on it.

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:
https://cmake.org/mailman/listinfo/cmake-developers

[cmake-developers] XXX_FLAGS_INIT applied inconsistently

[Craig Scott]

I'm looking at the way the various XXX_FLAGS_INIT variables are handled
across the different compilers and platforms. These are set in many files
in the Modules/Compilers, Modules/Platforms and Modules directories. There
seems to be a couple of problems with what I'm seeing:


   - In most cases, the various files are appending rather than prepending
   to the existing contents of the XXX_FLAGS_INIT variables. This means any
   values developers provide cannot override the default ones because later
   flags usually take precedence over earlier ones.
   - Some platforms and compilers (e.g. IRIX, Windows-df, Generic-SDCC-C,
   OSF1, CSharp flags) unilaterally set XXX_FLAGS_INIT variables. This would
   discard any values a developer might set in a toolchain file, for example.

Since I don't know much about the history of all these, I was wondering if
there was any technical reason why the logic works this way? As things
stand, it can be difficult for developers to provide their own
XXX_FLAGS_INIT variables to customise things if they are overridden by the
defaults CMake provides.

-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [CMake] Unexpected recompilation with ctest compiled MSVC project

[Simon Rit]

Hi,
If I do two consecutive builds with the same project, then it does not
recompile the second time, no. It behaves as if something is different (a
flag or something else) between the command line ctest build and the build
in the gui.
Simon

On Thu, Jan 18, 2018 at 9:01 PM, Kris Thielemans <
kris.f.thielem...@gmail.com> wrote:

> Hi Simon
>
>
>
> It definitely isn’t expected behaviour. MSVC should do exactly the same.
> It seems to point to a problem in your CMake files or elsewhere. Does the
> same thing happen if you just build immediately? Obviously, you shouldn’t
> do “rebuild” but just “build”.
>
>
>
> I haven’t checked RTK. Sorry.
>
>
>
> Kris
>
>
>
> *From:* CMake [mailto:cmake-boun...@cmake.org] *On Behalf Of *Simon Rit
> *Sent:* 18 January 2018 16:58
> *To:* cmake@cmake.org
> *Subject:* [CMake] Unexpected recompilation with ctest compiled MSVC
> project
>
>
>
> Hello,
>
> I'm happily using ctest to test my project:
> http://my.cdash.org/index.php?project=RTK
> One feature that I like is that if a problem appears with one config, I
> can easily try to modify the sources and then run make in the nightly built
> directory, only the object that failed to compile and object files impacted
> by the changes will be (re-)compiled. This works perfectly under linux with
> makefiles.
>
> However, the behavior is not the same under MSVC and since I am not used
> to this IDE, I'd like some explanation. When I have a problem with a
> compilation and I open the nightly configured MSVC project in the IDE, then
> everything is recompiled, including those files that compiled without any
> issue. Is this an expected behavior and, if yes, is there any way to
> recompile only what has failed, as I am used too under linux?
>
> I hope this is clear (enough). Thanks,
>
> Simon
>
-- 

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