[Cmake-commits] CMake branch, master, updated. v3.11.2-826-ga9bab14

[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  a9bab1443eed2763cd972ac2c50942667c13cd8d (commit)
  from  2f8230b05251aa498b47a883d471b1ebfd357e64 (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=a9bab1443eed2763cd972ac2c50942667c13cd8d
commit a9bab1443eed2763cd972ac2c50942667c13cd8d
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri May 25 00:01:04 2018 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri May 25 00:01:04 2018 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 70ff631..36f8c7e 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 20180524)
+set(CMake_VERSION_PATCH 20180525)
 #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] Contribute Find-module to CMake vs Config-file to upstream

[Paul Fultz II via CMake]

> On May 24, 2018, at 8:07 AM, Brad King  wrote:
> 
> On 05/22/2018 10:06 PM, Paul Fultz II wrote:
>> Or pkg-config could be extended to fix the issues.
> 
> The `.pc` file format is too flat to lend itself well to representing
> all the information we need.  

What do you mean? What information can’t be represented?


-- 

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] (no subject)

[Darrell Langford via CMake]

http://excellent.trackthatboat.com

Darrell Langford

-- 

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] Unresolved symbol VerifyFortran with clang C compiler and xlf_r Fortran compiler

[David Wootton]

I'm trying to build the lapack library I obtained from
http://www.netlib.org/lapack/lapack-3.8.0.tar.gz.  using the clang C
compiler and the xlf Fortran compiler with cmake 3.11. I'm using a Power 9
Linux system running Red Hat 7

The default behavior for the xlf compiler is to mangle Fortran so the
external symbol name is folded to all lower case with no trailing '_', In
this case, VerifyFortran should be mangled tp verifyfortran.

When I attempt to build it, my build system issues these error messages
 99 CMakeFiles/VerifyFortranC.dir/main.c.o: In function `main':
  >>
100/nfshome/drw/spack/spack/opt/spack/linux-rhel7-ppc64le/gcc-4.8.5/cm

ake-3.11.1-rcn6qgw6pldsuuk2gkijnn4dalajl4wr/share/cmake-3.11/Module
s/FortranCInterface/Verify/main.c:(.text+0x24): undefined
reference
 to `VerifyFortran'
  >> 101clang-3.8: error: linker command failed with exit code 1
(use -
v to see invocation)
  >> 102gmake[3]: *** [VerifyFortranC] Error 1
 103gmake[3]: Leaving directory
`/tmp/drw/spack-staging/spack-stage

/spack-stage-h3S7X1/lapack-3.8.0/spack-build-static/CMakeFiles/Fort
ranCInterface/VerifyC'

where cmake is attempting to verify Fortran/C compatibility for this pair
of compilers.

I tried to track this down by extracting this tar file in a scratch
directory. The build process requires cmake to be invoked in a separate
drectory from the source code so I created a 'build' directory in the
parent directory where my lapack-3.8.0 source resided, cd to that directory
and ran the command 'cmake ../lapack-3.8.0 -DCBLAS=ON' I get these messages
cd /nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC
&& /nfshome/drw/cmake/bin/cmake -E cmake_depends "Unix
Makefiles" /nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify 
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify 
/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC 
/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC 
/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles/VerifyFortranC.dir/DependInfo.cmake
Scanning dependencies of target VerifyFortranC
gmake[3]: Leaving directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
/bin/gmake -f CMakeFiles/VerifyFortranC.dir/build.make
CMakeFiles/VerifyFortranC.dir/build
gmake[3]: Entering directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
[ 60%] Building C object CMakeFiles/VerifyFortranC.dir/main.c.o
/opt/clang-coral/bin/clang
-I/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC  -O3
-DNDEBUG   -o CMakeFiles/VerifyFortranC.dir/main.c.o
-c /nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify/main.c
[ 80%] Building C object CMakeFiles/VerifyFortranC.dir/VerifyC.c.o
/opt/clang-coral/bin/clang
-I/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC  -O3
-DNDEBUG   -o CMakeFiles/VerifyFortranC.dir/VerifyC.c.o
-c 
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify/VerifyC.c
[100%] Linking C executable VerifyFortranC
/nfshome/drw/cmake/bin/cmake -E cmake_link_script
CMakeFiles/VerifyFortranC.dir/link.txt --verbose=1
/opt/clang-coral/bin/clang -O3 -DNDEBUG
CMakeFiles/VerifyFortranC.dir/main.c.o
CMakeFiles/VerifyFortranC.dir/VerifyC.c.o  -o VerifyFortranC
-L/opt/ibm/xlsmp/5.1.0/lib  -L/opt/ibm/xlmass/9.1.0/lib
-L/opt/ibm/xlf/16.1.0/lib libVerifyFortran.a -lxlf90_r -lxlopt -lxlomp_ser
-lxl -lxlfmath -ldl -lrt -lpthread -lm
CMakeFiles/VerifyFortranC.dir/main.c.o: In function `main':

/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify/main.c:(.text
+0x24): undefined reference to `VerifyFortran'
clang-3.8: error: linker command failed with exit code 1 (use -v to see
invocation)
gmake[3]: *** [VerifyFortranC] Error 1
gmake[3]: Leaving directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
gmake[2]: *** [CMakeFiles/VerifyFortranC.dir/all] Error 2
gmake[2]: Leaving directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
gmake[1]: *** [CMakeFiles/VerifyFortranC.dir/rule] Error 2
gmake[1]: Leaving directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
gmake: *** [VerifyFortranC] Error 2

I tried to figure out what's happening by running cmake with the
--trace-expand flag.

When I backtrack thru the log, I see these error messages related to
VerifyFortranC.

/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(24):  unset(FortranCInterface_VERIFIED_C CACHE )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(25):  unset(FortranCInterface_VERIFIED_CXX CACHE )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(27):  set(_result )

Re: [CMake] problem with CMake not including library's path (with pkg-config)

[Andreas Naumann]

Dear Francesco,

I use the pkg-config module with IPopt and had the same problem. 
According to the documentation, the library paths are in 
_LIBRARY_DIRS. In your case, you should find the paths in the 
variable AGG_LIBRARY_DIRS or all flags in the variable  AGG_LDFLAGS .


Regards,
Andreas
Am 24.05.2018 um 18:48 schrieb Francesco Abbate:

Hi all,

I stumbled in a problem with CMake. Everything is working fine except
that, for two libraries that I locate with pkg-config, cmake does not
include during linking the library's path (-L) which is given by
pkg-config.


Here an extract of the CMakeLists.txt:


[...]

include(FindPkgConfig)
pkg_search_module(AGG REQUIRED libagg)

[...]

target_link_libraries(libcanvas ${AGG_LIBRARIES})
target_include_directories(libcanvas PUBLIC
${PROJECT_SOURCE_DIR}/include ${AGG_INCLUDE_DIRS})
[...]

When I run pkg-config everything is correct:


pkg-config --libs libagg

-Lc:/fra/local_msys64/lib -lagg -lm

One can notice that pkg-config provides a non-standard path for the library.

By inspecting CMakeCache.txt I found a trace of the library's path.
See below an extract:

AGG_CFLAGS:INTERNAL=-Ic:/fra/local_msys64/include/agg2
AGG_CFLAGS_I:INTERNAL=
AGG_CFLAGS_OTHER:INTERNAL=
AGG_FOUND:INTERNAL=1
AGG_INCLUDEDIR:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_INCLUDE_DIRS:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_LDFLAGS:INTERNAL=-Lc:/fra/local_msys64/lib;-lagg;-lm
AGG_LDFLAGS_OTHER:INTERNAL=
AGG_LIBDIR:INTERNAL=c:/fra/local_msys64/lib
AGG_LIBRARIES:INTERNAL=agg;m
AGG_LIBRARY_DIRS:INTERNAL=c:/fra/local_msys64/lib
AGG_LIBS:INTERNAL=
AGG_LIBS_L:INTERNAL=
AGG_LIBS_OTHER:INTERNAL=
AGG_LIBS_PATHS:INTERNAL=
AGG_PREFIX:INTERNAL=c:/fra/local_msys64
AGG_STATIC_CFLAGS:INTERNAL=-Ic:/fra/local_msys64/include/agg2
AGG_STATIC_CFLAGS_I:INTERNAL=
AGG_STATIC_CFLAGS_OTHER:INTERNAL=
AGG_STATIC_INCLUDE_DIRS:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_STATIC_LDFLAGS:INTERNAL=-Lc:/fra/local_msys64/lib;-lagg;-lm
AGG_STATIC_LDFLAGS_OTHER:INTERNAL=
AGG_STATIC_LIBDIR:INTERNAL=
AGG_STATIC_LIBRARIES:INTERNAL=agg;m
AGG_STATIC_LIBRARY_DIRS:INTERNAL=c:/fra/local_msys64/lib
AGG_STATIC_LIBS:INTERNAL=
AGG_STATIC_LIBS_L:INTERNAL=
AGG_STATIC_LIBS_OTHER:INTERNAL=
AGG_STATIC_LIBS_PATHS:INTERNAL=
AGG_VERSION:INTERNAL=2.5.0
AGG_libagg_INCLUDEDIR:INTERNAL=
AGG_libagg_LIBDIR:INTERNAL=
AGG_libagg_PREFIX:INTERNAL=
AGG_libagg_VERSION:INTERNAL=

but in the Ninja build file the library's path is not given (below an extract):

--
#
# Link the executable tests\test-window.exe

build tests/test-window.exe: CXX_EXECUTABLE_LINKER__test-window tests/CMakeFiles
/test-window.dir/test-window.cpp.obj | win32/liblibcanvaswin32.a src/liblibcanva
s.a || src/liblibcanvas.a win32/liblibcanvaswin32.a
   LINK_LIBRARIES = win32/liblibcanvaswin32.a src/liblibcanvas.a -lagg
-lm -lfreetype -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32


So the behavior of CMake looks wrong to me. Pkg-config is giving
explicitly a non-standard library path but CMake just decided to not
include it in the linker options.

To finish let me report that I'am using CMake 3.11.1 on a Windows
system using MSYS2.

I can also mention that a similar Meson build just works fine but this
is only to make you, CMake guys, jealous.

Ok, just kidding :-)

Thank you in advance for any help.

Kind regards
Francesco







--

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] problem with CMake not including library's path (with pkg-config)

[Francesco Abbate]

Hi all,

I stumbled in a problem with CMake. Everything is working fine except
that, for two libraries that I locate with pkg-config, cmake does not
include during linking the library's path (-L) which is given by
pkg-config.


Here an extract of the CMakeLists.txt:


[...]

include(FindPkgConfig)
pkg_search_module(AGG REQUIRED libagg)

[...]

target_link_libraries(libcanvas ${AGG_LIBRARIES})
target_include_directories(libcanvas PUBLIC
${PROJECT_SOURCE_DIR}/include ${AGG_INCLUDE_DIRS})
[...]

When I run pkg-config everything is correct:

> pkg-config --libs libagg
-Lc:/fra/local_msys64/lib -lagg -lm

One can notice that pkg-config provides a non-standard path for the library.

By inspecting CMakeCache.txt I found a trace of the library's path.
See below an extract:

AGG_CFLAGS:INTERNAL=-Ic:/fra/local_msys64/include/agg2
AGG_CFLAGS_I:INTERNAL=
AGG_CFLAGS_OTHER:INTERNAL=
AGG_FOUND:INTERNAL=1
AGG_INCLUDEDIR:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_INCLUDE_DIRS:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_LDFLAGS:INTERNAL=-Lc:/fra/local_msys64/lib;-lagg;-lm
AGG_LDFLAGS_OTHER:INTERNAL=
AGG_LIBDIR:INTERNAL=c:/fra/local_msys64/lib
AGG_LIBRARIES:INTERNAL=agg;m
AGG_LIBRARY_DIRS:INTERNAL=c:/fra/local_msys64/lib
AGG_LIBS:INTERNAL=
AGG_LIBS_L:INTERNAL=
AGG_LIBS_OTHER:INTERNAL=
AGG_LIBS_PATHS:INTERNAL=
AGG_PREFIX:INTERNAL=c:/fra/local_msys64
AGG_STATIC_CFLAGS:INTERNAL=-Ic:/fra/local_msys64/include/agg2
AGG_STATIC_CFLAGS_I:INTERNAL=
AGG_STATIC_CFLAGS_OTHER:INTERNAL=
AGG_STATIC_INCLUDE_DIRS:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_STATIC_LDFLAGS:INTERNAL=-Lc:/fra/local_msys64/lib;-lagg;-lm
AGG_STATIC_LDFLAGS_OTHER:INTERNAL=
AGG_STATIC_LIBDIR:INTERNAL=
AGG_STATIC_LIBRARIES:INTERNAL=agg;m
AGG_STATIC_LIBRARY_DIRS:INTERNAL=c:/fra/local_msys64/lib
AGG_STATIC_LIBS:INTERNAL=
AGG_STATIC_LIBS_L:INTERNAL=
AGG_STATIC_LIBS_OTHER:INTERNAL=
AGG_STATIC_LIBS_PATHS:INTERNAL=
AGG_VERSION:INTERNAL=2.5.0
AGG_libagg_INCLUDEDIR:INTERNAL=
AGG_libagg_LIBDIR:INTERNAL=
AGG_libagg_PREFIX:INTERNAL=
AGG_libagg_VERSION:INTERNAL=

but in the Ninja build file the library's path is not given (below an extract):

--
#
# Link the executable tests\test-window.exe

build tests/test-window.exe: CXX_EXECUTABLE_LINKER__test-window tests/CMakeFiles
/test-window.dir/test-window.cpp.obj | win32/liblibcanvaswin32.a src/liblibcanva
s.a || src/liblibcanvas.a win32/liblibcanvaswin32.a
  LINK_LIBRARIES = win32/liblibcanvaswin32.a src/liblibcanvas.a -lagg
-lm -lfreetype -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32


So the behavior of CMake looks wrong to me. Pkg-config is giving
explicitly a non-standard library path but CMake just decided to not
include it in the linker options.

To finish let me report that I'am using CMake 3.11.1 on a Windows
system using MSYS2.

I can also mention that a similar Meson build just works fine but this
is only to make you, CMake guys, jealous.

Ok, just kidding :-)

Thank you in advance for any help.

Kind regards
Francesco





-- 
Francesco
-- 

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.2-825-g2f8230b

[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  2f8230b05251aa498b47a883d471b1ebfd357e64 (commit)
   via  2eb9852d7b74c45aa30c8a5db7e8469bad1eecd4 (commit)
   via  b1a05d6c762ceb6dbf47126a7ddcedadb45e02f5 (commit)
   via  0887c993aaadba6315dedca5399fae8cb7b9c965 (commit)
   via  a8bf1ea5b7aa51235b16c202bbd485bfa5480e19 (commit)
  from  2d480a1c149da5c314be8f6f01b8f90d239c2db5 (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=2f8230b05251aa498b47a883d471b1ebfd357e64
commit 2f8230b05251aa498b47a883d471b1ebfd357e64
Merge: 2eb9852 b1a05d6
Author: Brad King 
AuthorDate: Thu May 24 13:56:16 2018 +
Commit: Kitware Robot 
CommitDate: Thu May 24 09:56:23 2018 -0400

Merge topic 'revise-case-insensitive-command'

b1a05d6c76 Revise implementation of case-insensitive command names

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2eb9852d7b74c45aa30c8a5db7e8469bad1eecd4
commit 2eb9852d7b74c45aa30c8a5db7e8469bad1eecd4
Merge: 2d480a1 0887c99
Author: Brad King 
AuthorDate: Thu May 24 13:55:30 2018 +
Commit: Kitware Robot 
CommitDate: Thu May 24 09:55:46 2018 -0400

Merge topic 'FindBZip2-imported-include-dirs'

0887c993aa FindBZip2: Populate BZIP2_INCLUDE_DIRS result variable
a8bf1ea5b7 FindBZip2: Format result variable docs as definition list

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b1a05d6c762ceb6dbf47126a7ddcedadb45e02f5
commit b1a05d6c762ceb6dbf47126a7ddcedadb45e02f5
Author: Florian Jacomme 
AuthorDate: Tue May 1 16:17:31 2018 +0200
Commit: Brad King 
CommitDate: Tue May 22 10:56:24 2018 -0400

Revise implementation of case-insensitive command names

Store both the as-written and lower-case command names and use
the latter to avoid case-insensitive string comparisons.

With this I obtain 2-6% speed increase (on Windows) for the configure
step with no significant changes in memory usage.  A case-insensitive
comparison is a lot slower than just calling `==` because the operator
will use things like memcmp, so prefer the latter.

The `cmSystemTools::LowerCase` function allocates a new string each time
it is called, so before this change we were allocating in:

* cmMakefile::Configure two times for each function
  (to look for `cmake_minimum_required` and `project`)
* cmMakefile::ExecuteCommand twice by function by calling
  cmState::GetCommand and copying the name

Now we are only allocating once by function instead of four.

diff --git a/Source/cmForEachCommand.cxx b/Source/cmForEachCommand.cxx
index df288bd..9ff967c 100644
--- a/Source/cmForEachCommand.cxx
+++ b/Source/cmForEachCommand.cxx
@@ -29,10 +29,10 @@ bool cmForEachFunctionBlocker::IsFunctionBlocked(const 
cmListFileFunction& lff,
  cmMakefile& mf,
  cmExecutionStatus& inStatus)
 {
-  if (!cmSystemTools::Strucmp(lff.Name.c_str(), "foreach")) {
+  if (lff.Name.Lower == "foreach") {
 // record the number of nested foreach commands
 this->Depth++;
-  } else if (!cmSystemTools::Strucmp(lff.Name.c_str(), "endforeach")) {
+  } else if (lff.Name.Lower == "endforeach") {
 // if this is the endofreach for this statement
 if (!this->Depth) {
   // Remove the function blocker for this scope or bail.
@@ -97,7 +97,7 @@ bool cmForEachFunctionBlocker::IsFunctionBlocked(const 
cmListFileFunction& lff,
 bool cmForEachFunctionBlocker::ShouldRemove(const cmListFileFunction& lff,
 cmMakefile& mf)
 {
-  if (!cmSystemTools::Strucmp(lff.Name.c_str(), "endforeach")) {
+  if (lff.Name.Lower == "endforeach") {
 std::vector expandedArguments;
 mf.ExpandArguments(lff.Arguments, expandedArguments);
 // if the endforeach has arguments then make sure
diff --git a/Source/cmFunctionCommand.cxx b/Source/cmFunctionCommand.cxx
index 774df84..67c9e9a 100644
--- a/Source/cmFunctionCommand.cxx
+++ b/Source/cmFunctionCommand.cxx
@@ -9,7 +9,6 @@
 #include "cmMakefile.h"
 #include "cmPolicies.h"
 #include "cmState.h"
-#include "cmSystemTools.h"
 
 // define the class for function commands
 class cmFunctionHelperCommand : public cmCommand
@@ -128,9 +127,9 @@ bool 

Re: [CMake] Contribute Find-module to CMake vs Config-file to upstream

[Brad King]

On 05/22/2018 10:06 PM, Paul Fultz II wrote:
> Or pkg-config could be extended to fix the issues.

The `.pc` file format is too flat to lend itself well to representing
all the information we need.  A goal of `.cps` files is to teach
pkg-config to parse them and respond to its standard queries with the
same output format as now.

> In the Boost Cmake Modules, we support generating both pkg-config and
> cmake config files automatically from the cmake targets:

That's fantastic but until there is no such thing as a Boost installation
that doesn't support both tools the problems will persist.  They mangle
their library names in such a way that it's impossible to use boost without
a build system that memorizes dozens of mangling conventions that vary
with the version of boost, version of the compiler, architecture, etc.

-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

Re: [CMake] Contribute Find-module to CMake vs Config-file to upstream

[Mateusz Loskot]

On 24 May 2018 at 08:45, Elvis Stansvik  wrote:
> Den ons 23 maj 2018 17:18Mateusz Loskot  skrev:
>> On 23 May 2018 at 16:37, David Demelier  wrote:
>> > On Mon, 2018-05-21 at 19:39 +0200, Mateusz Loskot wrote:
>> >>
>> >>
>> >> IMHO, CMake should encourage contributions of new Find-modules.
>> >
>> > No.
>>
>> Yes.
>
>
> As for my part, I'll just have to agree to disagree with this.
> [...]
> But I think CMake has grown so much by
> now, and has such leverage (people generally are not opposed to being "CMake
> compatible"), that efforts are better spent making it easy to write config
> files, and supporting initiatives like that cps thing.

Those will take years to get into production state for CMake.
Find-modules can solve issues now, without "want to drive? build your
own car first"
appraoch, but  basic CMake scripting knowledge.
I'm very supportive to the cps, but I can not help it move forward.
I, however, can help updating/adding Find-modules.

> I also don't agree that it doesn't hurt CMake to have a growing number of
> outdated find modules. It leads to a lot of bug reports.

In the times of GitHub-like pace of development, we should really learn to use
https://github.com/apps/stale or equivalents.

> If it's there, people will expect it to work, and when it doesn't they become 
> disappointed.
> If it wasn't there from the beginning there's no expectation.

There is nothing wrong with it, as long as status of Find-modules is clearly
stated in the documentation and users learn correctly what Find-modules are
- guessers about future without promises, not configurators about present state.

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

Re: [CMake] Contribute Find-module to CMake vs Config-file to upstream

[Elvis Stansvik]

Den ons 23 maj 2018 17:18Mateusz Loskot  skrev:

> On 23 May 2018 at 16:37, David Demelier  wrote:
> > On Mon, 2018-05-21 at 19:39 +0200, Mateusz Loskot wrote:
> >>
> >> I've been recently trying to update/add Find-modules to CMake:
> >> updated FindJPEG, proposed FindODBC and most recently FindLZ4.
> >>
> >> Discussion during review of the FindLZ4 [1] ended with some
> >> surprising
> >> conclusions which I, as someone who relies on CMake and occacionally
> >> contributes to CMake, don't necessarily agree with.
> >> I'd like to share some of my thoughts.
> >>
> >> [1] https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_4
> >> 12640
> >>
> >> A bit of a extract from the brief discussion [1]:
> >>
> >> The FindLZ4 discussion basically ended with suggestion from Brad
> >> that,
> >> instead of adding Find-module to CMake, I should approach LZ4 project
> >> and add Config-file to the library itself.
> >
> > Yes, that's the way to go.
>
> I hoped it will draw clear from my earlier thoughts that I consider
> discussion
> *if* CMake should encourage Find-modules as pointless, or at least
> off-topic here.
> We should be discussing not *if*, but *how* to keep Find-modules,
> enourage new ones, fix existing ones and make both Find-modules and
> Config-files coexist.
>
> Hence, I'm not going to address any of your points trying to convince me
> to give up my position. If I do, we will be making circles forever.
>
> >> Packages of libraries which provide CMake and alternative build
> >> configurations
> >> may not deploy Config-files or Find-modules.
> >>
> >> IMHO, CMake should encourage contributions of new Find-modules.
> >
> > No.
>
> Yes.
>

As for my part, I'll just have to agree to disagree with this. When I first
learned about CMake many years ago, I always thought it strange that it
came bundled with a bunch of Find modules (compared to say the pkg-config
approach), because it seemed to me such an obviously futile effort to get
coverage/keep them up to date.

Maybe the bundled modules served (and continues to serve) a purpose in that
they encourage the uptake of CMake. But I think CMake has grown so much by
now, and has such leverage (people generally are not opposed to being
"CMake compatible"), that efforts are better spent making it easy to write
config files, and supporting initiatives like that cps thing.

I also don't agree that it doesn't hurt CMake to have a growing number of
outdated find modules. It leads to a lot of bug reports. If it's there,
people will expect it to work, and when it doesn't they become
disappointed. If it wasn't there from the beginning there's no expectation.

My 2 cents


> > What if CMake 3.12 has a FindFooBar module shipped in your package
> > manager. But upstream decided to break everything? Change component
> > name, change library name? We won't have time to inspect all find
> > modules and update them *because* upstream decided to change.
>
> Nothing. That is already the case and nobody expects Find-modules are
> 100% solid across CMake X versions of libraries it can recognise.
>
> Find-modules are "guessers" and as such CMake does not give hard promises.
> That is already the case. I will repeat the premise points from earlier:
>
> - Find-modules are very useful "guessers"
> - CMake installs Find-modules of good and bad or broken quality (that
> is happening today!)
> - CMake does not suffer directly from hosting bad quality Find-modules
> - CMake should not care if a Find-module becomes outdated as it would
> not suffer directly (as per previous points)
>
> >> I want to contribute Find-module into a **central place** where I can
> >> easily
> >> access it as well as monitor its state and submit fixes if necessary.
> >> From a contributor POV, that is much more effective than jumping
> >> between
> >> variety of issue trackers, creating new accounts for one time use or
> >> even
> >> sending patches via e-mails to maitnainers - not everything lives in
> >> GitHub yet.
> >>
> >> Since CMake is still de-facto a standard for building C++ software,
> >> from end-user POV the current situation feels almost like vendor
> >> lock-in.
> >>
> >> I call CMake to accept *any* Find-module, filtering only based on
> >> quality of CMake
> >> idiomatic scripting.
> >>
> >> If CMake does not want Find-* modules within the source tree, then
> >> - set up https://gitlab.kitware.com/cmake/find-modules
> >> - move all existing Find-modules in there
> >> - relax maintenance rules to accept *any* Find-module, provided
> >> --- CMake scripting is decent quality (e.g no community downvotes or
> >> rejecting
> >>  reviews for period of quarantine)
> >> --- CI passing tests
> >> - finally, include the complete find-modules archive in the installer
> >> so it is deployed
> >>aside of CMake itself
> >
> > This sounds like more of a reasonable proposal. CMake should by itself
> > not propose any Find* package anymore. A user-managed