[cmake-developers] [CMake 0016023]: OS X CMake.app (version 3.5) contains empty CFBundleIdentifier, which is malformed

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16023 
== 
Reported By:Sean McBride
Assigned To:
== 
Project:CMake
Issue ID:   16023
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-03-17 15:43 EDT
Last Modified:  2016-03-17 15:43 EDT
== 
Summary:OS X CMake.app (version 3.5) contains empty
CFBundleIdentifier, which is malformed
Description: 
CMake.app's Info.plist contains:

CFBundleIdentifier


That entry isn't allowed to be empty.

I suggest a value like "org.cmake.cmake" or something.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-17 15:43 Sean McBride   New Issue
==

-- 

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-commits] CMake branch, next, updated. v3.5.0-510-g7cd4496

[Brad King]

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, next has been updated
   via  7cd44969f80853ae4e26c428192bd7364e7ef94e (commit)
   via  7b990e82c523772e8e40911812e6f896c0529e84 (commit)
  from  a8e3ae223f438f45fcd2ef3d1c774905731f3fca (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=7cd44969f80853ae4e26c428192bd7364e7ef94e
commit 7cd44969f80853ae4e26c428192bd7364e7ef94e
Merge: a8e3ae2 7b990e8
Author: Brad King 
AuthorDate: Thu Mar 17 16:30:35 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Mar 17 16:30:35 2016 -0400

Merge topic 'cmake-gui-osx-identifier' into next

7b990e82 cmake-gui: Populate CFBundleIdentifier in our Info.plist file 
(#16023)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7b990e82c523772e8e40911812e6f896c0529e84
commit 7b990e82c523772e8e40911812e6f896c0529e84
Author: Brad King 
AuthorDate: Thu Mar 17 16:06:54 2016 -0400
Commit: Brad King 
CommitDate: Thu Mar 17 16:07:39 2016 -0400

cmake-gui: Populate CFBundleIdentifier in our Info.plist file (#16023)

diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
index f17de5d..a906f4a 100644
--- a/Source/QtDialog/CMakeLists.txt
+++ b/Source/QtDialog/CMakeLists.txt
@@ -173,6 +173,7 @@ if(APPLE)
 MACOSX_BUNDLE_SHORT_VERSION_STRING "${CMAKE_BUNDLE_VERSION}"
 # TBD: MACOSX_BUNDLE_BUNDLE_VERSION "${CMAKE_BUNDLE_VERSION}"
 MACOSX_BUNDLE_COPYRIGHT "${copyright_line}"
+MACOSX_BUNDLE_GUI_IDENTIFIER "org.cmake.cmake"
 )
 
   # Create a symlink in the build tree to provide a "cmake-gui" next

---

Summary of changes:
 Source/QtDialog/CMakeLists.txt |1 +
 1 file changed, 1 insertion(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.5.0-521-g7a56d86

[Brad King]

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, next has been updated
   via  7a56d861f71e5d929a48f477657b70c6cad16159 (commit)
   via  32d1dc83abc6e3ea0d2299373b2bd3d1499fcb38 (commit)
  from  be7c99fb365692e332f6524139e3ea4b2d16d280 (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=7a56d861f71e5d929a48f477657b70c6cad16159
commit 7a56d861f71e5d929a48f477657b70c6cad16159
Merge: be7c99f 32d1dc8
Author: Brad King 
AuthorDate: Fri Mar 18 09:51:03 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Mar 18 09:51:03 2016 -0400

Merge topic 'cpack-osx-optional-CoreServices' into next

32d1dc83 CPack: Avoid using OS X CoreServices if compiler fails on header 
(#16021)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=32d1dc83abc6e3ea0d2299373b2bd3d1499fcb38
commit 32d1dc83abc6e3ea0d2299373b2bd3d1499fcb38
Author: Brad King 
AuthorDate: Fri Mar 18 08:49:02 2016 -0400
Commit: Brad King 
CommitDate: Fri Mar 18 08:55:22 2016 -0400

CPack: Avoid using OS X CoreServices if compiler fails on header (#16021)

Some compilers on OS X report errors in the CoreServices framework headers.
Check for support of the header ahead of time and compile the relevant code
only when the header is available.

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 5b67a2d..eaad702 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -722,6 +722,10 @@ if(APPLE)
 CPack/cmCPackOSXX11Generator.cxx
 CPack/cmCPackPackageMakerGenerator.cxx
 )
+  check_include_file("CoreServices/CoreServices.h" HAVE_CoreServices)
+  if(HAVE_CoreServices)
+set_property(SOURCE CPack/cmCPackDragNDropGenerator.cxx PROPERTY 
COMPILE_DEFINITIONS HAVE_CoreServices)
+  endif()
 endif()
 
 # Build CPackLib
diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx 
b/Source/CPack/cmCPackDragNDropGenerator.cxx
index 521b395..8009204 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.cxx
+++ b/Source/CPack/cmCPackDragNDropGenerator.cxx
@@ -22,10 +22,12 @@
 
 #include 
 
+#ifdef HAVE_CoreServices
 // For the old LocaleStringToLangAndRegionCodes() function, to convert
 // to the old Script Manager RegionCode values needed for the 'LPic' data
 // structure used for generating multi-lingual SLAs.
 #include 
+#endif
 
 static const char* SLAHeader =
 "data 'LPic' (5000) {\n"
@@ -643,9 +645,11 @@ int cmCPackDragNDropGenerator::CreateDMG(const 
std::string& src_dir,
kCFStringEncodingMacRoman);
 LangCode lang = 0;
 RegionCode region = 0;
+#if HAVE_CoreServices
 OSStatus err = LocaleStringToLangAndRegionCodes(iso_language_cstr,
 , );
 if (err != noErr)
+#endif
   {
   cmCPackLogger(cmCPackLog::LOG_ERROR,
 "No language/region code available for " << iso_language_cstr
@@ -653,10 +657,12 @@ int cmCPackDragNDropGenerator::CreateDMG(const 
std::string& src_dir,
   free(iso_language_cstr);
   return 0;
   }
+#if HAVE_CoreServices
 free(iso_language_cstr);
 header_data.push_back(region);
 header_data.push_back(i);
 header_data.push_back(0);
+#endif
 }
   ofs << "data 'LPic' (5000) {\n";
   ofs << std::hex << std::uppercase << std::setfill('0');

---

Summary of changes:
 Source/CMakeLists.txt  |4 
 Source/CPack/cmCPackDragNDropGenerator.cxx |6 ++
 2 files changed, 10 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.5.0-267-g33594f2

[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  33594f20fa22c7aea62051f199004e3d4d89c971 (commit)
  from  a9cb00cd50b518656053a5da4147a7106a8bfa78 (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=33594f20fa22c7aea62051f199004e3d4d89c971
commit 33594f20fa22c7aea62051f199004e3d4d89c971
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sun Mar 20 00:01:07 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sun Mar 20 00:01:07 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 584f207..bab9222 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 5)
-set(CMake_VERSION_PATCH 20160319)
+set(CMake_VERSION_PATCH 20160320)
 #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
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Cmake fails to build libssh2 - wants VC 2010 told for VC 2015 build

[Elizabeth Fischer]

Just get the tarball from:

https://github.com/libssh2/libssh2/tarball/libssh2-1.7.0


On Tue, Mar 15, 2016 at 7:50 AM, Barry Scott  wrote:

> On Tue, 15 Mar 2016 10:37:04 +0300
> Sergei Nikulov  wrote:
>
> > Just checked with following steps
> >
> > 1. Opened command window (cmd.exe)
> > 2. Clone libssh2 from GitHub (git clone
> https://github.com/libssh2/libssh2.git)
>
> Out of curiosity why did you ignore my steps using the tar ball and use
> the git clone?
>
> > 3. Change dir to libssh2 (cd libssh2)
> > 4. Create folder build (mkdir build)
> > 5. Change dir to build (cd build)
> > 6. Generate build for MSVS 2015 (cmake .. -G"Visual Studio 14 Win64")
> > 7. Build it (cmake --build . --config Release)
> >
> > And see no any problems :(
>
> I also see no problem with the git clone.
>
> > Could you please be more specific?
> > For example provide generator log for your "bug".
>
> The conclusion I draw is that libssh2 has fixed a "bug" with its cmake
> config files.
>
> Thanks for looking at this.
>
> Barry
> --
>
> 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
>
-- 

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

[Cmake-commits] CMake branch, master, updated. v3.5.0-252-g9082590

[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  908259084f139187af202aaf5c39052804d8969e (commit)
  from  cd569b962dbeaa7ea718021c16582cddd158df3a (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=908259084f139187af202aaf5c39052804d8969e
commit 908259084f139187af202aaf5c39052804d8969e
Author: Kitware Robot 
AuthorDate: Fri Mar 18 00:01:06 2016 -0400
Commit: Kitware Robot 
CommitDate: Fri Mar 18 00:01:06 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index b021ffd..e667257 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 5)
-set(CMake_VERSION_PATCH 20160317)
+set(CMake_VERSION_PATCH 20160318)
 #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
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] more use of cmXMLWriter

[Konstantin Podsvirov]

Hi all! Hi Daniel!

Thank you for the work done.

I'm the developer CPack IFW generator.

I heard about cmXMLWriter and planned to use it,
but I couldn't find the time to do it.

I looked 0007-CPack-IFW-port-to-cmXMLWriter.patch and at first glance
everything should work as before, but I haven't conducted tests
on the real packs.

If I find the time to test, I will report about results here.

20.03.2016, 00:24, "Daniel Pfeifer" :
> Hi,
> I ported. some more generators to cmXMLWriter.
> cheers, Daniel

--
Regards,
Konstantin Podsvirov
-- 

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] Ninja and add_subdirectory EXCLUDE_FROM_ALL

[Brad King]

On 03/16/2016 12:13 PM, Charles Huet wrote:
>> On 03/16/2016 04:59 AM, Charles Huet wrote:
>>> If you have other ideas on how to improve this patch, I'll be happy to
>>> implement them.

All paths that are given to WritePhonyBuild in the outputs and depends
options should be sent through ConvertToNinjaPath.  This makes paths
relative and formats slashes for Windows.  This should avoid the need
to do string manipulation on the paths (e.g. substr) too.  Just be sure
to append the "/all" before calling the conversion method.

Also please keep source lines to 79 characters or less.

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, master, updated. v3.5.0-251-gcd569b9

[Brad King]

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  cd569b962dbeaa7ea718021c16582cddd158df3a (commit)
   via  e3fc2899c89fb075a695d6140eaadf11db85d96c (commit)
  from  f6d66b04a36c263d8cc6c01d9b628168dae42d85 (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=cd569b962dbeaa7ea718021c16582cddd158df3a
commit cd569b962dbeaa7ea718021c16582cddd158df3a
Merge: f6d66b0 e3fc289
Author: Brad King 
AuthorDate: Thu Mar 17 09:41:37 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Mar 17 09:41:37 2016 -0400

Merge topic 'ios-install-combined-one-arch'

e3fc2899 Fix iOS combined feature for single architecture targets


---

Summary of changes:
 Modules/CMakeIOSInstallCombined.cmake  |   12 +-
 Tests/RunCMake/XcodeProject/RunCMakeTest.cmake |   20 
 ...OSInstallCombinedSingleArch-install-check.cmake |   25 
 .../XcodeIOSInstallCombinedSingleArch.cmake|   19 +++
 4 files changed, 75 insertions(+), 1 deletion(-)
 create mode 100644 
Tests/RunCMake/XcodeProject/XcodeIOSInstallCombinedSingleArch-install-check.cmake
 create mode 100644 
Tests/RunCMake/XcodeProject/XcodeIOSInstallCombinedSingleArch.cmake


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Building with Cmake using Boost problem

[Hendrik Sattler]

Am 16. März 2016 22:13:14 MEZ, schrieb Karel Geiregat :

>According to the cmake documentation of FindBoost
> you have to
>name
>the required libraries as described;
>
>"date_time" for "libboost_date_time"

You do NOT have to rename any files! Doing so completely defeats the purpose of 
a find module.

Additionally, .lib files for Microsoft compilers do NOT start like libxxx.lib 
but only xxx.lib
Building boost with your compiler should give you the right files as-is.

Why are you reading documentation of cmake 3.0 when using cmake 3.5? I cannot 
find anything in the documentation of the boost find module about renaming.
However it documents steps to debug problems.

HS

-- 

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-541-g52badc5

[Brad King]

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, next has been updated
   via  52badc53fb23ba97db7a46b1bbb7d4cc3c47b858 (commit)
   via  5f6b4f690a3348c43f4f26bcc07c2418c3f2ab2f (commit)
  from  a27d069287eb0ed75c64ba0b7f9a8f393fecfa10 (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=52badc53fb23ba97db7a46b1bbb7d4cc3c47b858
commit 52badc53fb23ba97db7a46b1bbb7d4cc3c47b858
Merge: a27d069 5f6b4f6
Author: Brad King 
AuthorDate: Fri Mar 18 11:24:04 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Mar 18 11:24:04 2016 -0400

Merge topic 'find-blas-lapack-OpenBLAS' into next

5f6b4f69 Find{BLAS,LAPACK}: Add support for OpenBLAS (#16024)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5f6b4f690a3348c43f4f26bcc07c2418c3f2ab2f
commit 5f6b4f690a3348c43f4f26bcc07c2418c3f2ab2f
Author: J M Dieterich 
AuthorDate: Fri Mar 18 10:55:16 2016 -0400
Commit: Brad King 
CommitDate: Fri Mar 18 11:23:36 2016 -0400

Find{BLAS,LAPACK}: Add support for OpenBLAS (#16024)

OpenBLAS (www.openblas.net) is the successor to GotoBLAS.

diff --git a/Help/release/dev/find-blas-lapack-OpenBLAS.rst 
b/Help/release/dev/find-blas-lapack-OpenBLAS.rst
new file mode 100644
index 000..893422a
--- /dev/null
+++ b/Help/release/dev/find-blas-lapack-OpenBLAS.rst
@@ -0,0 +1,5 @@
+find-blas-lapack-OpenBLAS
+-
+
+* The :module:`FindBLAS` and :module:`FindLAPACK` modules learned to
+  support `OpenBLAS `__.
diff --git a/Modules/FindBLAS.cmake b/Modules/FindBLAS.cmake
index 416b666..546ada1 100644
--- a/Modules/FindBLAS.cmake
+++ b/Modules/FindBLAS.cmake
@@ -30,9 +30,9 @@
 #   BLA_F95 if set on tries to find the f95 interfaces for BLAS/LAPACK
 #
 # # ## List of vendors (BLA_VENDOR) valid in this module #
-# Goto,ATLAS PhiPACK,CXML,DXML,SunPerf,SCSL,SGIMATH,IBMESSL,Intel10_32
-# (intel mkl v10 32 bit),Intel10_64lp (intel mkl v10 64 bit,lp thread
-# model, lp64 model), # Intel10_64lp_seq (intel mkl v10 64
+# Goto,OpenBLAS,ATLAS PhiPACK,CXML,DXML,SunPerf,SCSL,SGIMATH,IBMESSL,
+# Intel10_32 (intel mkl v10 32 bit),Intel10_64lp (intel mkl v10 64 bit,
+# lp thread model, lp64 model), # Intel10_64lp_seq (intel mkl v10 64
 # bit,sequential code, lp64 model), # Intel( older versions of mkl 32
 # and 64 bit), ACML,ACML_MP,ACML_GPU,Apple, NAS, Generic C/CXX should be
 # enabled to use Intel mkl
@@ -172,6 +172,20 @@ if (BLA_VENDOR STREQUAL "Goto" OR BLA_VENDOR STREQUAL 
"All")
  endif()
 endif ()
 
+if (BLA_VENDOR STREQUAL "OpenBLAS" OR BLA_VENDOR STREQUAL "All")
+ if(NOT BLAS_LIBRARIES)
+  # OpenBLAS (http://www.openblas.net)
+  check_fortran_libraries(
+  BLAS_LIBRARIES
+  BLAS
+  sgemm
+  ""
+  "openblas"
+  ""
+  )
+ endif()
+endif ()
+
 if (BLA_VENDOR STREQUAL "ATLAS" OR BLA_VENDOR STREQUAL "All")
  if(NOT BLAS_LIBRARIES)
   # BLAS in ATLAS library? (http://math-atlas.sourceforge.net/)
diff --git a/Modules/FindLAPACK.cmake b/Modules/FindLAPACK.cmake
index b11edc3..2708de0 100644
--- a/Modules/FindLAPACK.cmake
+++ b/Modules/FindLAPACK.cmake
@@ -31,7 +31,7 @@
 #   BLA_F95 if set on tries to find the f95 interfaces for BLAS/LAPACK
 #
 # ## List of vendors (BLA_VENDOR) valid in this module # Intel(mkl),
-# ACML,Apple, NAS, Generic
+# OpenBLAS, ACML,Apple, NAS, Generic
 
 #=
 # Copyright 2007-2009 Kitware, Inc.
@@ -181,6 +181,19 @@ if (BLA_VENDOR STREQUAL "Goto" OR BLA_VENDOR STREQUAL 
"All")
  endif()
 endif ()
 
+if (BLA_VENDOR STREQUAL "OpenBLAS" OR BLA_VENDOR STREQUAL "All")
+ if(NOT LAPACK_LIBRARIES)
+  check_lapack_libraries(
+  LAPACK_LIBRARIES
+  LAPACK
+  cheev
+  ""
+  "openblas"
+  "${BLAS_LIBRARIES}"
+  ""
+  )
+ endif()
+endif ()
 
 #acml lapack
  if (BLA_VENDOR MATCHES "ACML" OR BLA_VENDOR STREQUAL "All")

---

Summary of changes:
 Help/release/dev/find-blas-lapack-OpenBLAS.rst |5 +
 Modules/FindBLAS.cmake |   20 +---
 Modules/FindLAPACK.cmake   |   15 ++-
 3 files changed, 36 insertions(+), 4 deletions(-)
 create mode 100644 Help/release/dev/find-blas-lapack-OpenBLAS.rst


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.5.0-508-ga8e3ae2

[Brad King]

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, next has been updated
   via  a8e3ae223f438f45fcd2ef3d1c774905731f3fca (commit)
   via  c718070c0887e1c429d6ae4b717c006236c32736 (commit)
  from  65e591cea4a7257f2891db15136e09ce2db5da22 (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=a8e3ae223f438f45fcd2ef3d1c774905731f3fca
commit a8e3ae223f438f45fcd2ef3d1c774905731f3fca
Merge: 65e591c c718070
Author: Brad King 
AuthorDate: Thu Mar 17 14:49:59 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Mar 17 14:49:59 2016 -0400

Merge topic 'cpack-osx-no-carbon' into next

c718070c CPack: Avoid requiring Carbon framework on OS X (#16021)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c718070c0887e1c429d6ae4b717c006236c32736
commit c718070c0887e1c429d6ae4b717c006236c32736
Author: Sean McBride 
AuthorDate: Thu Mar 17 10:47:44 2016 -0400
Commit: Brad King 
CommitDate: Thu Mar 17 13:53:51 2016 -0400

CPack: Avoid requiring Carbon framework on OS X (#16021)

In commit v3.5.0-rc1~232^2 (CPackDMG: Add support for multilingual SLAs,
2015-10-19) we added use of the Carbon framework in order to get access
to its APIs to convert Script Manager RegionCode values.  This is not
necessary.  Instead we can use CoreServices.

While at it, replace individual CoreFoundation includes with including
the entire framework, which is the correct way.

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index ab70568..5b67a2d 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -728,7 +728,7 @@ endif()
 add_library(CPackLib ${CPACK_SRCS})
 target_link_libraries(CPackLib CMakeLib)
 if(APPLE)
-  target_link_libraries(CPackLib "-framework Carbon")
+  target_link_libraries(CPackLib "-framework CoreServices")
 endif()
 
 if(APPLE)
diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx 
b/Source/CPack/cmCPackDragNDropGenerator.cxx
index 7b94ca3..521b395 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.cxx
+++ b/Source/CPack/cmCPackDragNDropGenerator.cxx
@@ -20,21 +20,12 @@
 
 #include 
 
-#include 
-#include 
-#include 
-
-// The carbon framework is deprecated, but the Region codes it supplies are
-// needed for the LPic data structure used for generating multi-lingual SLAs.
-// There does not seem to be a replacement API for these region codes.
-#if defined(__clang__)
-# pragma clang diagnostic push
-# pragma clang diagnostic ignored "-Wdeprecated-declarations"
-#endif
-#include 
-#if defined(__clang__)
-# pragma clang diagnostic pop
-#endif
+#include 
+
+// For the old LocaleStringToLangAndRegionCodes() function, to convert
+// to the old Script Manager RegionCode values needed for the 'LPic' data
+// structure used for generating multi-lingual SLAs.
+#include 
 
 static const char* SLAHeader =
 "data 'LPic' (5000) {\n"

---

Summary of changes:
 Source/CMakeLists.txt  |2 +-
 Source/CPack/cmCPackDragNDropGenerator.cxx |   21 ++---
 2 files changed, 7 insertions(+), 16 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.5.0-525-gcfcba93

[Brad King]

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, next has been updated
   via  cfcba931392b24886b41037042353b43f9d46615 (commit)
   via  5d4cbdac8402306dd2d47f0d0681f2e1fe0437f0 (commit)
  from  94bdf2355be80aca48c18376f4f7e8b79f8c5c70 (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=cfcba931392b24886b41037042353b43f9d46615
commit cfcba931392b24886b41037042353b43f9d46615
Merge: 94bdf23 5d4cbda
Author: Brad King 
AuthorDate: Fri Mar 18 09:56:04 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Mar 18 09:56:04 2016 -0400

Merge topic 'cpack-osx-optional-CoreServices' into next

5d4cbdac CPack: Avoid using OS X CoreServices if compiler fails on header 
(#16021)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d4cbdac8402306dd2d47f0d0681f2e1fe0437f0
commit 5d4cbdac8402306dd2d47f0d0681f2e1fe0437f0
Author: Brad King 
AuthorDate: Fri Mar 18 08:49:02 2016 -0400
Commit: Brad King 
CommitDate: Fri Mar 18 09:55:00 2016 -0400

CPack: Avoid using OS X CoreServices if compiler fails on header (#16021)

Some compilers on OS X report errors in the CoreServices framework headers.
Check for support of the header ahead of time and compile the relevant code
only when the header is available.

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 5b67a2d..75c179f 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -728,7 +728,11 @@ endif()
 add_library(CPackLib ${CPACK_SRCS})
 target_link_libraries(CPackLib CMakeLib)
 if(APPLE)
-  target_link_libraries(CPackLib "-framework CoreServices")
+  check_include_file("CoreServices/CoreServices.h" HAVE_CoreServices)
+  if(HAVE_CoreServices)
+set_property(SOURCE CPack/cmCPackDragNDropGenerator.cxx PROPERTY 
COMPILE_DEFINITIONS HAVE_CoreServices)
+target_link_libraries(CPackLib "-framework CoreServices")
+  endif()
 endif()
 
 if(APPLE)
diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx 
b/Source/CPack/cmCPackDragNDropGenerator.cxx
index 521b395..8009204 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.cxx
+++ b/Source/CPack/cmCPackDragNDropGenerator.cxx
@@ -22,10 +22,12 @@
 
 #include 
 
+#ifdef HAVE_CoreServices
 // For the old LocaleStringToLangAndRegionCodes() function, to convert
 // to the old Script Manager RegionCode values needed for the 'LPic' data
 // structure used for generating multi-lingual SLAs.
 #include 
+#endif
 
 static const char* SLAHeader =
 "data 'LPic' (5000) {\n"
@@ -643,9 +645,11 @@ int cmCPackDragNDropGenerator::CreateDMG(const 
std::string& src_dir,
kCFStringEncodingMacRoman);
 LangCode lang = 0;
 RegionCode region = 0;
+#if HAVE_CoreServices
 OSStatus err = LocaleStringToLangAndRegionCodes(iso_language_cstr,
 , );
 if (err != noErr)
+#endif
   {
   cmCPackLogger(cmCPackLog::LOG_ERROR,
 "No language/region code available for " << iso_language_cstr
@@ -653,10 +657,12 @@ int cmCPackDragNDropGenerator::CreateDMG(const 
std::string& src_dir,
   free(iso_language_cstr);
   return 0;
   }
+#if HAVE_CoreServices
 free(iso_language_cstr);
 header_data.push_back(region);
 header_data.push_back(i);
 header_data.push_back(0);
+#endif
 }
   ofs << "data 'LPic' (5000) {\n";
   ofs << std::hex << std::uppercase << std::setfill('0');

---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL

[Charles Huet]

Yes, sorry about that.

Le mer. 16 mars 2016 à 15:46, Brad King  a écrit :

> On 03/16/2016 04:59 AM, Charles Huet wrote:
> > Sure, done.
> >
> > If you have other ideas on how to improve this patch, I'll be happy to
> > implement them.
>
> Great.  Did you mean to attach a revised patch?
>
> Thanks,
> -Brad
>
>
From 25308102899bdcab9693da736184a4dc38001b4b Mon Sep 17 00:00:00 2001
From: Charles Huet 
Date: Fri, 11 Mar 2016 16:26:29 +0100
Subject: [PATCH] Added a target for each EXCLUDED_FROM_ALL folder that holds
 all the targets in said folder

---
 Source/cmGlobalNinjaGenerator.cxx | 69 +++
 Source/cmGlobalNinjaGenerator.h   |  1 +
 2 files changed, 70 insertions(+)

diff --git a/Source/cmGlobalNinjaGenerator.cxx b/Source/cmGlobalNinjaGenerator.cxx
index 0f06e43..0fa76a0 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -577,6 +577,7 @@ void cmGlobalNinjaGenerator::Generate()
 
   this->WriteAssumedSourceDependencies();
   this->WriteTargetAliases(*this->BuildFileStream);
+  this->WriteFolderTargets(*this->BuildFileStream);
   this->WriteUnknownExplicitDependencies(*this->BuildFileStream);
   this->WriteBuiltinTargets(*this->BuildFileStream);
 
@@ -1042,6 +1043,74 @@ void cmGlobalNinjaGenerator::WriteTargetAliases(std::ostream& os)
   }
 }
 
+void cmGlobalNinjaGenerator::WriteFolderTargets(std::ostream& os)
+{
+  cmGlobalNinjaGenerator::WriteDivider(os);
+  os << "# Folder targets.\n\n";
+
+  cmLocalGenerator* firstLocalGenerator = this->LocalGenerators[0];
+  const std::string rootSourceDir = firstLocalGenerator->GetSourceDirectory();
+
+  std::map targetsPerFolder;
+
+  for ( std::vector::const_iterator generatorIt = this->LocalGenerators.begin();
+generatorIt != this->LocalGenerators.end();
+++generatorIt)
+{
+const cmLocalGenerator* localGenerator = *generatorIt;
+const std::string currentSourceFolder(localGenerator->GetStateSnapshot().GetDirectory().GetCurrentSource());
+targetsPerFolder[currentSourceFolder] = cmNinjaDeps();
+for ( std::vector::const_iterator targetIt = localGenerator->GetGeneratorTargets().begin();
+  targetIt != localGenerator->GetGeneratorTargets().end();
+  ++targetIt)
+  {
+  const cmGeneratorTarget* generatorTarget = *targetIt;
+
+  const int type = generatorTarget->GetType();
+  if((type == cmState::EXECUTABLE) ||
+ (type == cmState::STATIC_LIBRARY) ||
+ (type == cmState::SHARED_LIBRARY) ||
+ (type == cmState::MODULE_LIBRARY) ||
+ (type == cmState::OBJECT_LIBRARY) ||
+ (type == cmState::UTILITY) &&
+ (!generatorTarget->GetPropertyAsBool("EXCLUDE_FROM_ALL"))
+ )
+{
+targetsPerFolder[currentSourceFolder].push_back(generatorTarget->GetName());
+}
+  }
+
+  // The directory-level rule should depend on the directory-level
+  // rules of the subdirectories.
+  std::vector children
+  = localGenerator->GetStateSnapshot().GetChildren();
+  for(std::vector::const_iterator
+stateIt = children.begin(); stateIt != children.end(); ++stateIt)
+{
+std::string currentSourceDir(stateIt->GetDirectory().GetCurrentSource());
+std::string subdir = currentSourceDir.substr(rootSourceDir.length() + 1, currentSourceDir.length()) + "/all";
+targetsPerFolder[currentSourceFolder].push_back(subdir);
+}
+}
+
+  for ( std::map::const_iterator it = targetsPerFolder.begin(); it != targetsPerFolder.end(); ++it )
+{
+cmGlobalNinjaGenerator::WriteDivider( os );
+std::string currentSourceDir(it->first);
+
+//do not generate a rule for the root source dir
+if(rootSourceDir.length() >= currentSourceDir.length())
+  continue;
+
+const std::string folderRule = currentSourceDir.substr(rootSourceDir.length() + 1, currentSourceDir.length()) + "/all";
+const std::string comment = "Folder: " + std::string(it->first);
+cmNinjaDeps output(1);
+output.push_back(folderRule);
+
+this->WritePhonyBuild(os, comment, output, it->second);
+}
+}
+
 void cmGlobalNinjaGenerator::WriteUnknownExplicitDependencies(std::ostream& os)
 {
   if (!this->ComputingUnknownDependencies)
diff --git a/Source/cmGlobalNinjaGenerator.h b/Source/cmGlobalNinjaGenerator.h
index 8656590..e95a295 100644
--- a/Source/cmGlobalNinjaGenerator.h
+++ b/Source/cmGlobalNinjaGenerator.h
@@ -342,6 +342,7 @@ private:
   void WriteAssumedSourceDependencies();
 
   void WriteTargetAliases(std::ostream& os);
+  void WriteFolderTargets(std::ostream& os);
   void WriteUnknownExplicitDependencies(std::ostream& os);
 
   void WriteBuiltinTargets(std::ostream& os);
-- 
1.8.3.1

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Re: [CMake] Cmake cannot locate header file that exists on my system

[Andreas Naumann]

You have to add the directory /usr/include/trilinos to the c++ include 
directories. The fastest workaround would be, to add the directory to 
the CMAKE_CXX_FLAGS using ccmake or cmake-gui.
The better solution is to look for any hint regarding trilinos in the 
CMakeLists.txt of dakota and check, why the corresponding include 
directory is not added.


Regards,

Andreas

Am 17.03.2016 um 14:32 schrieb Chris Coutinho:


I’m attempting to install Dakota 6.3.0 using cmake 3.5.0 on a 64-bit 
Linux box from source (to link python and MATLAB), and Dakota is 
having trouble finding some dependencies. I’ve been able to install 
and use Dakota successfully on my previous machine (64-bit, OpenSUSE 
13.2, cmake 3.3.0) without any problems. Now that I upgraded to the 
more recent version of OpenSUSE (Opensuse Leap 42.1) and cmake 
(3.5.0), I’m not able to get past this error.


I am using cmake to build the source and create a makefile. 
Configuring cmake is fine; however, when running ‘make’ I get an error 
at around 5% of compiling:


/[ 5%] Building CXX object 
packages/OPTPP/src/CMakeFiles/optpp.dir/globals.C.o/
/In file included from 
/opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/globals.C:4:0:/
//opt/dakota/dakota-6.3.0.src/packages/OPTPP/include/globals.h:22:41: 
fatal error: Teuchos_SerialDenseMatrix.hpp: No such file or directory/

/#include "Teuchos_SerialDenseMatrix.hpp"/
/^/
/compilation terminated./

I looked for the missing file ‘Teuchos_SerialDenseMatrix.hpp’, and see 
that I have two copies on my computer from installing trilinos 11.4.3 
through the package manager. One is located under 
‘/usr/include/trilinos’, and the other is located 
‘/usr/lib64/mpi/gcc/openmpi/include/trilinos’. I’m not sure why I have 
two copies…


I added both of those directories to LD_LIBRARY_PATH in ~/.bashrc, but 
the error keeps coming up that Dakota isn’t able to find the file. Can 
anyone help me with this installation issue?


Kind regards,

*Chris Coutinho,* EIT

R Engineer

REDstack, B.V.

Pieter Zeemanstraat 6

8606 JR Sneek, The Netherlands

work: +31 6  5785

mobile: +31 6 1689 0287

www.redstack.nl

De informatie verzonden middels deze e-mail is uitsluitend bestemd 
voor de geadresseerde. Gebruik door anderen is niet toegestaan. 
Openbaarmaking, verspreiding en/of verstrekking van deze informatie 
aan derden is niet toegestaan. A.Hak staat niet in voor een juiste en 
volledige overbrenging van de inhoud, alsmede de tijdige ontvangst 
daarvan.


The information contained in this communication, including files, is 
confidential and legally privileged. It is intended solely for the use 
of the individual or entity to whom it is addressed and others 
authorized to receive it. If you are not the intended recipient you 
are hereby notified that any disclosure, copying, distribution or 
taking any action in reliance to the contents of this information, is 
strictly prohibited and may be unlawful. A.Hak is not liable for the 
proper, complete and timely transmission of the information contained 
in this communication.





--

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-531-g3f41a53

[Brad King]

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, next has been updated
   via  3f41a53534a9df440745658161a8e083873df521 (commit)
   via  da808dc035e24ce01f0c3426e0a157cb100ac45e (commit)
  from  757daf9a9d882cb7b68fe6f2a11b7df5c2bccb99 (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=3f41a53534a9df440745658161a8e083873df521
commit 3f41a53534a9df440745658161a8e083873df521
Merge: 757daf9 da808dc
Author: Brad King 
AuthorDate: Fri Mar 18 09:58:54 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Mar 18 09:58:54 2016 -0400

Merge topic 'cpack-osx-optional-CoreServices' into next

da808dc0 CPack: Avoid using OS X CoreServices if compiler fails on header 
(#16021)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=da808dc035e24ce01f0c3426e0a157cb100ac45e
commit da808dc035e24ce01f0c3426e0a157cb100ac45e
Author: Brad King 
AuthorDate: Fri Mar 18 08:49:02 2016 -0400
Commit: Brad King 
CommitDate: Fri Mar 18 09:58:31 2016 -0400

CPack: Avoid using OS X CoreServices if compiler fails on header (#16021)

Some compilers on OS X report errors in the CoreServices framework headers.
Check for support of the header ahead of time and compile the relevant code
only when the header is available.

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 5b67a2d..75c179f 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -728,7 +728,11 @@ endif()
 add_library(CPackLib ${CPACK_SRCS})
 target_link_libraries(CPackLib CMakeLib)
 if(APPLE)
-  target_link_libraries(CPackLib "-framework CoreServices")
+  check_include_file("CoreServices/CoreServices.h" HAVE_CoreServices)
+  if(HAVE_CoreServices)
+set_property(SOURCE CPack/cmCPackDragNDropGenerator.cxx PROPERTY 
COMPILE_DEFINITIONS HAVE_CoreServices)
+target_link_libraries(CPackLib "-framework CoreServices")
+  endif()
 endif()
 
 if(APPLE)
diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx 
b/Source/CPack/cmCPackDragNDropGenerator.cxx
index 521b395..d6de77d 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.cxx
+++ b/Source/CPack/cmCPackDragNDropGenerator.cxx
@@ -22,10 +22,12 @@
 
 #include 
 
+#ifdef HAVE_CoreServices
 // For the old LocaleStringToLangAndRegionCodes() function, to convert
 // to the old Script Manager RegionCode values needed for the 'LPic' data
 // structure used for generating multi-lingual SLAs.
 #include 
+#endif
 
 static const char* SLAHeader =
 "data 'LPic' (5000) {\n"
@@ -643,9 +645,11 @@ int cmCPackDragNDropGenerator::CreateDMG(const 
std::string& src_dir,
kCFStringEncodingMacRoman);
 LangCode lang = 0;
 RegionCode region = 0;
+#ifdef HAVE_CoreServices
 OSStatus err = LocaleStringToLangAndRegionCodes(iso_language_cstr,
 , );
 if (err != noErr)
+#endif
   {
   cmCPackLogger(cmCPackLog::LOG_ERROR,
 "No language/region code available for " << iso_language_cstr
@@ -653,10 +657,12 @@ int cmCPackDragNDropGenerator::CreateDMG(const 
std::string& src_dir,
   free(iso_language_cstr);
   return 0;
   }
+#ifdef HAVE_CoreServices
 free(iso_language_cstr);
 header_data.push_back(region);
 header_data.push_back(i);
 header_data.push_back(0);
+#endif
 }
   ofs << "data 'LPic' (5000) {\n";
   ofs << std::hex << std::uppercase << std::setfill('0');

---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] CMake aliasing system

[Tamás Kenéz]

Ruslo, I think we all could argue both against and for implementing
cmake-ini files inside the cmake command. I mean I'm also aware of all the
pros and cons. It's just that we weigh differently.
I like loosely connected simpler building blocks and my own cmake-wrapping
extension script works fine, that's why I thought you would not lose
anything with that.

>> git commit --author="John Doe" --email="john@example.com"
 --branch="master"
>> git push --remote="git://awesome.example.com"
> This is a complete nonsense!

I agree and that's why I think cmake ini files is a good idea.

Tamas

On Tue, Mar 15, 2016 at 3:25 AM, Ruslan Baratov 
wrote:

> On 15-Mar-16 02:42, Tamás Kenéz wrote:
>
> I also doubt this belongs to upstream. But you could write a single,
> generic script which forwards its arguments to cmake and also accepts and
> processes the additional parameters along the way. I don't think we'd lose
> anything:
>
> cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS
>
> This is the approach I took as I needed features like you described. But
> if there would be a mature, versatile, community-tested script I'd be
> willing to use it and contribute to it.
>
> As you can see I'm already using script `build.py` and there is not enough
> power for now (even if it extends CMake basic functionality a lot) so I was
> thinking to introduce global/local ini-configuration file anyway. Then I
> realize that most of the `build.py` functions can be implemented in such
> ini-configuration. So why not use CMake? Why for example not extend CMake
> GUI with this feature support? Why do users need to install some extra
> tools instead of just one?
>
> Global/local configuration files in not something special. Git for example
> has same system, yes it increase complexity but literally every user store
> setting there.
> Just imagine you have to write something like this every commit + push:
>
> > git commit --author="John Doe" --email="john@example.com"
>  --branch="master"
> > git push --remote="git://awesome.example.com"
>
> This is a complete nonsense!
>
> So I'm planning to make a fork anyway and do some experiments even if it
> will not accepted to upstream.
>
> Ruslo
>
>
> Tamas
>
> On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via cmake-developers <
> cmake-developers@cmake.org> wrote:
>
>> On 14-Mar-16 21:59, Brad King wrote:
>>
>>> On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:
>>>
 I guess it is a well known fact that cmake command is almost never
 executed alone and for non-trivial examples usually hold some extra
 arguments (home directory, build directory, verbosity level, toolchains,
 options, ...). Also I guess that such commands doesn't change from
 day-to-day development process and an obvious way to reduce typing is to
 create wrapper build scripts (.bat or .sh, I personally use a Python
 one).

>>> Sorry, I don't think something like this belongs upstream.  It can easily
>>> be done with shell aliases or other custom scripts.
>>>
>> I've got quite opposite experience. It's hard to say that family of
>> custom scripts (+ a lot of environment variables in .bashrc)  is an "easy
>> shell scripting", example:
>> *
>> https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py
>>
>>We shouldn't increase the complexity of the CMake command line
>>> interface further.
>>>
>> To be clear this feature required only one new CMake option. The rest is
>> responsibility of some pre-build parsing module.
>>
>> In general I feel sad that CMake will not became more user-friendly in
>> this exact part. Though the only proves of my point that can be provided
>> here is a users experience. Since I don't see any feedback here I'm out of
>> arguments...
>>
>> Ruslo
>>
>> --
>>
>> 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
>>
>
>
>
-- 

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: 

[Cmake-commits] CMake branch, next, updated. v3.5.0-519-gbe7c99f

[Brad King]

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, next has been updated
   via  be7c99fb365692e332f6524139e3ea4b2d16d280 (commit)
   via  527773662c092233be5e99123561192eb8eb6fdc (commit)
  from  bd7993730e2f96e8899a1670ccfe71744e1f5c90 (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=be7c99fb365692e332f6524139e3ea4b2d16d280
commit be7c99fb365692e332f6524139e3ea4b2d16d280
Merge: bd79937 5277736
Author: Brad King 
AuthorDate: Fri Mar 18 09:48:18 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Mar 18 09:48:18 2016 -0400

Merge topic 'osx-no-carbon' into next

52777366 Drop unnecessary LSRequiresCarbon reference from Info.plist files


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=527773662c092233be5e99123561192eb8eb6fdc
commit 527773662c092233be5e99123561192eb8eb6fdc
Author: Sean McBride 
AuthorDate: Thu Mar 17 10:47:44 2016 -0400
Commit: Brad King 
CommitDate: Fri Mar 18 09:47:03 2016 -0400

Drop unnecessary LSRequiresCarbon reference from Info.plist files

LSRequiresCarbon is long since unnecessary.  It refers to requiring
Carbon as opposed to Classic (OS 9 emulation).

diff --git a/Modules/CPack.OSXX11.Info.plist.in 
b/Modules/CPack.OSXX11.Info.plist.in
index 851b67b..23a1483 100644
--- a/Modules/CPack.OSXX11.Info.plist.in
+++ b/Modules/CPack.OSXX11.Info.plist.in
@@ -41,8 +41,6 @@
@CPACK_APPLE_GUI_BUNDLE_VERSION@
CSResourcesFileMapped

-   LSRequiresCarbon
-   
NSHumanReadableCopyright
@CPACK_APPLE_GUI_COPYRIGHT@
 
diff --git a/Modules/MacOSXBundleInfo.plist.in 
b/Modules/MacOSXBundleInfo.plist.in
index a466dc7..a4009bc 100644
--- a/Modules/MacOSXBundleInfo.plist.in
+++ b/Modules/MacOSXBundleInfo.plist.in
@@ -28,8 +28,6 @@
${MACOSX_BUNDLE_BUNDLE_VERSION}
CSResourcesFileMapped

-   LSRequiresCarbon
-   
NSHumanReadableCopyright
${MACOSX_BUNDLE_COPYRIGHT}
 
diff --git a/Templates/AppleInfo.plist b/Templates/AppleInfo.plist
index 1f68ccf..3445e53 100644
--- a/Templates/AppleInfo.plist
+++ b/Templates/AppleInfo.plist
@@ -28,8 +28,6 @@
${APPLE_GUI_BUNDLE_VERSION}
CSResourcesFileMapped

-   LSRequiresCarbon
-   
NSHumanReadableCopyright
${APPLE_GUI_COPYRIGHT}
 

---

Summary of changes:
 Modules/CPack.OSXX11.Info.plist.in |2 --
 Modules/MacOSXBundleInfo.plist.in  |2 --
 Templates/AppleInfo.plist  |2 --
 3 files changed, 6 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Cmake fails to build libssh2 - wants VC 2010 told for VC 2015 build

[Sergei Nikulov]

2016-03-16 15:40 GMT+03:00 Elizabeth Fischer :
> Just get the tarball from:
>
> https://github.com/libssh2/libssh2/tarball/libssh2-1.7.0
>
>

We've already discussed/solved this

The problem was

--config RelWithDebugInfo

should be

--config RelWithDebInfo



-- 
Best Regards,
Sergei Nikulov
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.5.0-247-gd9fc4df

[Brad King]

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  d9fc4dfe3c0d2857018758649f9d5f780b22e333 (commit)
   via  3144857e1eed83e038699942568869bfce461d4d (commit)
  from  811e2974545579d166396ca1ed4f91b0ce7c7990 (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=d9fc4dfe3c0d2857018758649f9d5f780b22e333
commit d9fc4dfe3c0d2857018758649f9d5f780b22e333
Merge: 811e297 3144857
Author: Brad King 
AuthorDate: Thu Mar 17 09:41:32 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Mar 17 09:41:32 2016 -0400

Merge topic 'use-GetCMakeRoot'

3144857e Avoid depending on CMAKE_ROOT cache entry internally (#16015)


---

Summary of changes:
 Source/cmCreateTestSourceList.cxx|3 +--
 Source/cmExtraCodeBlocksGenerator.cxx|3 +--
 Source/cmGeneratorTarget.cxx |3 +--
 Source/cmGlobalGenerator.cxx |2 +-
 Source/cmGlobalVisualStudioGenerator.cxx |3 +--
 Source/cmMakefile.cxx|   20 
 Source/cmQtAutoGeneratorInitializer.cxx  |3 +--
 Source/cmake.cxx |3 +--
 8 files changed, 15 insertions(+), 25 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.5.0-2-g44bbd2a

[Brad King]

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, release has been updated
   via  44bbd2a65c0d2a405b70b96c3d643ce4b5eb82f4 (commit)
   via  e2f387fabbf6af8665b88b8933ef5ed5cb59 (commit)
  from  b369959eb55dbea601315530185cb480c922cc77 (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 -
---

Summary of changes:
 Modules/FindBoost.cmake |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.5.0-544-g020f72f

[Brad King]

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, next has been updated
   via  020f72fae1990c8da4e291e7cd07b6b220a85d05 (commit)
   via  cdfd837a09bd752ff1756feb18c4d9443020c54b (commit)
   via  5c1f4da83d1142e52b361e8f59dd68ea5728e843 (commit)
  from  52badc53fb23ba97db7a46b1bbb7d4cc3c47b858 (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=020f72fae1990c8da4e291e7cd07b6b220a85d05
commit 020f72fae1990c8da4e291e7cd07b6b220a85d05
Merge: 52badc5 cdfd837
Author: Brad King 
AuthorDate: Fri Mar 18 13:28:36 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Mar 18 13:28:36 2016 -0400

Merge topic 'vs-startup-project' into next

cdfd837a VS: Add option to choose the `.sln` startup project (#15578)
5c1f4da8 Tests: Rename RunCMake.{SolutionGlobalSections => VSSolution}


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdfd837a09bd752ff1756feb18c4d9443020c54b
commit cdfd837a09bd752ff1756feb18c4d9443020c54b
Author: Davy Durham 
AuthorDate: Thu Mar 17 16:12:02 2016 -0400
Commit: Brad King 
CommitDate: Fri Mar 18 13:27:24 2016 -0400

VS: Add option to choose the `.sln` startup project (#15578)

Add a `VS_STARTUP_PROJECT` directory property to specify the project
that should be placed first in the `.sln` file so that it will be
selected as the default startup project.

Co-Author: Taylor Braun-Jones 

diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index fbde4eb..dadbc6e 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -76,6 +76,7 @@ Properties on Directories
/prop_dir/VARIABLES
/prop_dir/VS_GLOBAL_SECTION_POST_section
/prop_dir/VS_GLOBAL_SECTION_PRE_section
+   /prop_dir/VS_STARTUP_PROJECT
 
 .. _`Target Properties`:
 
diff --git a/Help/prop_dir/VS_STARTUP_PROJECT.rst 
b/Help/prop_dir/VS_STARTUP_PROJECT.rst
new file mode 100644
index 000..edd4832
--- /dev/null
+++ b/Help/prop_dir/VS_STARTUP_PROJECT.rst
@@ -0,0 +1,12 @@
+VS_STARTUP_PROJECT
+--
+
+Specify the default startup project in a Visual Studio solution.
+
+The property must be set to the name of an existing target.  This
+will cause that project to be listed first in the generated solution
+file causing Visual Studio to make it the startup project if the
+solution has never been opened before.
+
+If this property is not specified, then the "ALL_BUILD" project
+will be the default.
diff --git a/Help/release/dev/vs-startup-project.rst 
b/Help/release/dev/vs-startup-project.rst
new file mode 100644
index 000..f467400
--- /dev/null
+++ b/Help/release/dev/vs-startup-project.rst
@@ -0,0 +1,6 @@
+vs-startup-project
+--
+
+* The :ref:`Visual Studio Generators` learned to honor a new
+  :prop_dir:`VS_STARTUP_PROJECT` directory property that specifies
+  the default startup project for generated solutions (``.sln`` files).
diff --git a/Source/cmGlobalVisualStudio71Generator.cxx 
b/Source/cmGlobalVisualStudio71Generator.cxx
index 8227b82..f6796a5 100644
--- a/Source/cmGlobalVisualStudio71Generator.cxx
+++ b/Source/cmGlobalVisualStudio71Generator.cxx
@@ -94,7 +94,8 @@ void cmGlobalVisualStudio71Generator
   TargetDependSet projectTargets;
   TargetDependSet originalTargets;
   this->GetTargetSets(projectTargets, originalTargets, root, generators);
-  OrderedTargetDependSet orderedProjectTargets(projectTargets, "ALL_BUILD");
+  OrderedTargetDependSet orderedProjectTargets(
+projectTargets, this->GetStartupProjectName(root));
 
   this->WriteTargetsToSolution(fout, root, orderedProjectTargets);
 
diff --git a/Source/cmGlobalVisualStudioGenerator.cxx 
b/Source/cmGlobalVisualStudioGenerator.cxx
index 00bb511..b11b49a 100644
--- a/Source/cmGlobalVisualStudioGenerator.cxx
+++ b/Source/cmGlobalVisualStudioGenerator.cxx
@@ -519,6 +519,32 @@ cmGlobalVisualStudioGenerator::GetUtilityDepend(
 }
 
 //
+std::string
+cmGlobalVisualStudioGenerator::GetStartupProjectName(
+  cmLocalGenerator const* root) const
+{
+  const char* n = root->GetMakefile()->GetProperty("VS_STARTUP_PROJECT");
+  if (n && *n)
+{
+std::string startup = n;
+if (this->FindTarget(startup))
+  {
+  return startup;
+  }
+else
+  {
+  root->GetMakefile()->IssueMessage(
+cmake::AUTHOR_WARNING,
+"Directory property VS_STARTUP_PROJECT specifies target "
+"'" + startup + "' that does not exist.  

Re: [CMake] File names with unbalanced square brackets

[CHEVRIER, Marc]

I think you can resolve your problem with the following syntax for foreach 
command:
Foreach (FILE IN LISTS FILES)

In this case the list is not expanded in your source so square brackets is no 
longer interpreted…


From: CMake > on behalf 
of Petr Kmoch >
Date: Friday 18 March 2016 at 08:17
To: Allen Barnett >
Cc: "cmake@cmake.org" 
>
Subject: Re: [CMake] File names with unbalanced square brackets

Hi Allen.

I'm not sure whether it's documented, but CMake interprets square brackets as 
escaping the semi-colon character (which means a semi-colon in square brackets 
will not work as a list item separator). You will probably have to translate 
the file names for CMake processing by replacing [ and ] with a different 
string, and replacing it back just before use outside of CMake.

Petr

On Thu, Mar 17, 2016 at 5:38 PM, Allen Barnett 
> wrote:
I inherited a set of files with somewhat unusual file names. In particular, 
there were a couple of files whose names included a single square bracket 
character. I processed these files with the file( GLOB ...) command and then 
iterated over the resulting list with foreach. However, the foreach command 
does not seem to break the resulting list apart correctly. To make this 
concrete, I have a directory with files named "a", "b[", and "c". file( GLOB 
FILES "*" ) returns the list:

/home/allen/test/b[;/home/allen/test/c;/home/allen/test/a

However,

foreach( FILE ${FILES} )
  message( ${FILE} )
endforeach()

just prints the same thing. That is, foreach does not split FILES into separate 
pieces. If I rename "b[" to "b]" I see the same behavior. If I rename "b[" to 
"b[]" (or even "b]["), then foreach successfully splits FILES into the 
individual file names.

I'm using CMake 3.3.2. I see the same thing on linux and windows.

Thanks,
Allen

--

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

-- 

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

[Cmake-commits] CMake branch, master, updated. v3.5.0-265-g9cdb37e

[Brad King]

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  9cdb37e9175b2e3c6367bc4863fda0404cb1c3a2 (commit)
   via  c089485d2131c7074c931b99044b8d00d498f414 (commit)
   via  e903a9fc55a1a8d1e6cc681f8d2e98bb74566ec8 (commit)
   via  dd630075448f6aa45c0e51444365feb73701ebbd (commit)
  from  1bcdc4db1bcfc75cf9813bc279840b975e74892d (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=9cdb37e9175b2e3c6367bc4863fda0404cb1c3a2
commit 9cdb37e9175b2e3c6367bc4863fda0404cb1c3a2
Merge: 1bcdc4d c089485
Author: Brad King 
AuthorDate: Fri Mar 18 09:43:23 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Mar 18 09:43:23 2016 -0400

Merge topic 'release-win64'

c089485d Utilities/Release: Skip spurious Qt5Autogen test for nightly binary
e903a9fc Utilities/Release: Create a Windows 64-bit binary
dd630075 Utilities/Release: Rename scripts to match target platform


---

Summary of changes:
 Tests/CMakeLists.txt|   11 +++
 Utilities/Release/create-cmake-release.cmake|9 +
 .../{dash2win64_cygwin.cmake => cygwin_release.cmake}   |1 -
 .../{magrathea_release.cmake => linux32_release.cmake}  |0
 .../Release/{bigmac_release.cmake => osx_release.cmake} |0
 .../{dash3win7_release.cmake => win32_release.cmake}|4 
 .../{dash3win7_release.cmake => win64_release.cmake}|   11 ++-
 7 files changed, 22 insertions(+), 14 deletions(-)
 rename Utilities/Release/{dash2win64_cygwin.cmake => cygwin_release.cmake} 
(97%)
 rename Utilities/Release/{magrathea_release.cmake => linux32_release.cmake} 
(100%)
 rename Utilities/Release/{bigmac_release.cmake => osx_release.cmake} (100%)
 copy Utilities/Release/{dash3win7_release.cmake => win32_release.cmake} (88%)
 rename Utilities/Release/{dash3win7_release.cmake => win64_release.cmake} (79%)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] File names with unbalanced square brackets

[Allen Barnett]

Hi David: Per your comment on the SO thread about escaping the ['s with a
backslash:You mean something like this:

file( GLOB FILES "*" )
string( REPLACE "[" "\\[" FILES_UPD "${FILES}" )

That doesn't appear to work. I still get everything past the first [ run
together in the foreach.

Thanks,
Allen

On Fri, Mar 18, 2016 at 9:09 AM, David Cole  wrote:

> "A single pair of square brackets with ; inside have also long been
> used to designate registry [key;value] pairs on Windows."
>
> http://stackoverflow.com/a/36085151/236192
>
>
> HTH,
> David C.
>
>
> On Fri, Mar 18, 2016 at 8:21 AM, Allen Barnett 
> wrote:
> > Hi Petr: You're right! If I rename "c" to "c]", it treats the whole
> > "/home/allen/test/b[;/home/allen/test/c]" as an element of the list. The
> > other file names are correctly split apart.
> > Thanks,
> > Allen
> >
> > On Fri, Mar 18, 2016 at 3:17 AM, Petr Kmoch 
> wrote:
> >>
> >> Hi Allen.
> >>
> >> I'm not sure whether it's documented, but CMake interprets square
> brackets
> >> as escaping the semi-colon character (which means a semi-colon in square
> >> brackets will not work as a list item separator). You will probably
> have to
> >> translate the file names for CMake processing by replacing [ and ] with
> a
> >> different string, and replacing it back just before use outside of
> CMake.
> >>
> >> Petr
> >>
> >> On Thu, Mar 17, 2016 at 5:38 PM, Allen Barnett  >
> >> wrote:
> >>>
> >>> I inherited a set of files with somewhat unusual file names. In
> >>> particular, there were a couple of files whose names included a single
> >>> square bracket character. I processed these files with the file( GLOB
> ...)
> >>> command and then iterated over the resulting list with foreach.
> However, the
> >>> foreach command does not seem to break the resulting list apart
> correctly.
> >>> To make this concrete, I have a directory with files named "a", "b[",
> and
> >>> "c". file( GLOB FILES "*" ) returns the list:
> >>>
> >>> /home/allen/test/b[;/home/allen/test/c;/home/allen/test/a
> >>>
> >>> However,
> >>>
> >>> foreach( FILE ${FILES} )
> >>>   message( ${FILE} )
> >>> endforeach()
> >>>
> >>> just prints the same thing. That is, foreach does not split FILES into
> >>> separate pieces. If I rename "b[" to "b]" I see the same behavior. If I
> >>> rename "b[" to "b[]" (or even "b]["), then foreach successfully splits
> FILES
> >>> into the individual file names.
> >>>
> >>> I'm using CMake 3.3.2. I see the same thing on linux and windows.
> >>>
> >>> Thanks,
> >>> Allen
> >>>
> >>> --
> >>>
> >>> 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
> >>
> >>
> >
> >
> > --
> >
> > 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
>
-- 

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

Re: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL

[Charles Huet]

ConvertToNinjaPath sadly makes the path relative to the binary dir, not the
source dir.

I added a utility function 'ConvertToNinjaFolderRule' that does the same
thing as ConvertToNinjaPath, but makes relative to the source dir, and adds
the '/all' suffix.

I also made the lines less than 79 chars.

Best


Le jeu. 17 mars 2016 à 15:53, Brad King  a écrit :

> On 03/16/2016 12:13 PM, Charles Huet wrote:
> >> On 03/16/2016 04:59 AM, Charles Huet wrote:
> >>> If you have other ideas on how to improve this patch, I'll be happy to
> >>> implement them.
>
> All paths that are given to WritePhonyBuild in the outputs and depends
> options should be sent through ConvertToNinjaPath.  This makes paths
> relative and formats slashes for Windows.  This should avoid the need
> to do string manipulation on the paths (e.g. substr) too.  Just be sure
> to append the "/all" before calling the conversion method.
>
> Also please keep source lines to 79 characters or less.
>
> Thanks,
> -Brad
>
>
From d204066149e098b9e33fc1004807a6d19d3f022b Mon Sep 17 00:00:00 2001
From: Charles Huet 
Date: Fri, 11 Mar 2016 16:26:29 +0100
Subject: [PATCH] Added a target for each EXCLUDED_FROM_ALL folder that holds
 all the targets in said folder

---
 Source/cmGlobalNinjaGenerator.cxx | 85 +++
 Source/cmGlobalNinjaGenerator.h   |  3 ++
 2 files changed, 88 insertions(+)

diff --git a/Source/cmGlobalNinjaGenerator.cxx b/Source/cmGlobalNinjaGenerator.cxx
index 0f06e43..49acfe3 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -577,6 +577,7 @@ void cmGlobalNinjaGenerator::Generate()
 
   this->WriteAssumedSourceDependencies();
   this->WriteTargetAliases(*this->BuildFileStream);
+  this->WriteFolderTargets(*this->BuildFileStream);
   this->WriteUnknownExplicitDependencies(*this->BuildFileStream);
   this->WriteBuiltinTargets(*this->BuildFileStream);
 
@@ -849,6 +850,18 @@ std::string cmGlobalNinjaGenerator::ConvertToNinjaPath(const std::string& path)
   return convPath;
 }
 
+std::string cmGlobalNinjaGenerator::ConvertToNinjaFolderRule(const std::string& path)
+{
+  cmLocalNinjaGenerator *ng =
+static_cast(this->LocalGenerators[0]);
+  std::string convPath = ng->Convert(path, cmOutputConverter::HOME);
+#ifdef _WIN32
+  cmSystemTools::ReplaceString(convPath, "/", "\\");
+#endif
+  return convPath + "/all";
+}
+
+
 void cmGlobalNinjaGenerator::AddCXXCompileCommand(
   const std::string ,
   const std::string )
@@ -1042,6 +1055,78 @@ void cmGlobalNinjaGenerator::WriteTargetAliases(std::ostream& os)
   }
 }
 
+void cmGlobalNinjaGenerator::WriteFolderTargets(std::ostream& os)
+{
+  cmGlobalNinjaGenerator::WriteDivider(os);
+  os << "# Folder targets.\n\n";
+
+  cmLocalGenerator* firstLocalGenerator = this->LocalGenerators[0];
+  const std::string rootSourceDir = firstLocalGenerator->GetSourceDirectory();
+
+  std::map targetsPerFolder;
+
+  for ( std::vector::const_iterator generatorIt =
+this->LocalGenerators.begin();
+generatorIt != this->LocalGenerators.end();
+++generatorIt)
+{
+const cmLocalGenerator* localGenerator = *generatorIt;
+const std::string currentSourceFolder(
+  localGenerator->GetStateSnapshot().GetDirectory().GetCurrentSource());
+targetsPerFolder[currentSourceFolder] = cmNinjaDeps();
+for ( std::vector::const_iterator targetIt =
+  localGenerator->GetGeneratorTargets().begin();
+  targetIt != localGenerator->GetGeneratorTargets().end();
+  ++targetIt)
+  {
+  const cmGeneratorTarget* generatorTarget = *targetIt;
+
+  const int type = generatorTarget->GetType();
+  if((type == cmState::EXECUTABLE) ||
+ (type == cmState::STATIC_LIBRARY) ||
+ (type == cmState::SHARED_LIBRARY) ||
+ (type == cmState::MODULE_LIBRARY) ||
+ (type == cmState::OBJECT_LIBRARY) ||
+ (type == cmState::UTILITY) &&
+ (!generatorTarget->GetPropertyAsBool("EXCLUDE_FROM_ALL"))
+ )
+{
+targetsPerFolder[currentSourceFolder].push_back(
+  generatorTarget->GetName());
+}
+  }
+
+  // The directory-level rule should depend on the directory-level
+  // rules of the subdirectories.
+  std::vector children
+  = localGenerator->GetStateSnapshot().GetChildren();
+  for(std::vector::const_iterator
+stateIt = children.begin(); stateIt != children.end(); ++stateIt)
+{
+targetsPerFolder[currentSourceFolder].push_back(
+  ConvertToNinjaFolderRule(stateIt->GetDirectory().
+   GetCurrentSource()));
+}
+}
+
+  for ( std::map::const_iterator it =
+targetsPerFolder.begin(); it != targetsPerFolder.end(); ++it )
+   

[Cmake-commits] CMake branch, next, updated. v3.5.0-537-g8628ae3

[Brad King]

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, next has been updated
   via  8628ae30966f971b86e10abb729224ee9ad2c307 (commit)
   via  46aa15d9146b387191d647814ada108d933203e7 (commit)
  from  36e31e35a08e2c63ee13d2919519aaf35def13ec (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=8628ae30966f971b86e10abb729224ee9ad2c307
commit 8628ae30966f971b86e10abb729224ee9ad2c307
Merge: 36e31e3 46aa15d
Author: Brad King 
AuthorDate: Fri Mar 18 11:13:10 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Mar 18 11:13:10 2016 -0400

Merge topic 'cpack-osx-optional-CoreServices' into next

46aa15d9 fixup! CPack: Avoid using OS X CoreServices if compiler fails on 
header


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=46aa15d9146b387191d647814ada108d933203e7
commit 46aa15d9146b387191d647814ada108d933203e7
Author: Brad King 
AuthorDate: Fri Mar 18 11:07:09 2016 -0400
Commit: Brad King 
CommitDate: Fri Mar 18 11:12:36 2016 -0400

fixup! CPack: Avoid using OS X CoreServices if compiler fails on header

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 75c179f..4ef0e80 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -728,10 +728,19 @@ endif()
 add_library(CPackLib ${CPACK_SRCS})
 target_link_libraries(CPackLib CMakeLib)
 if(APPLE)
+  # Some compilers produce errors in the CoreServices framework headers.
+  # Ideally such errors should be fixed by either the compiler vendor
+  # or the framework source, but we try to workaround it and build anyway.
+  # If it does not work, build with reduced functionality and warn.
   check_include_file("CoreServices/CoreServices.h" HAVE_CoreServices)
   if(HAVE_CoreServices)
 set_property(SOURCE CPack/cmCPackDragNDropGenerator.cxx PROPERTY 
COMPILE_DEFINITIONS HAVE_CoreServices)
 target_link_libraries(CPackLib "-framework CoreServices")
+  else()
+message(WARNING "This compiler does not appear to support\n"
+  "  #include \n"
+  "Some CPack functionality may be limited.\n"
+  "See CMakeFiles/CMakeError.log for details of the failure.")
   endif()
 endif()
 

---

Summary of changes:
 Source/CMakeLists.txt |9 +
 1 file changed, 9 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[CMake] Recompiling before when installing target

[gedemagt]

Is it possible recompile and link a single file before installing a target? I
have some string I want to hardcode into the source, so I use
configure_file() to add it to a .cpp file and compile it. However, these
values are different if the project is installed using 'make install'. Is it
possible to recompile that single file and relink it and then copy to the
install destination? 



--
View this message in context: 
http://cmake.3232098.n2.nabble.com/Recompiling-before-when-installing-target-tp7593070.html
Sent from the CMake mailing list archive at Nabble.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

Re: [CMake] why no cumulative variable operations via the commandline?

[René J . V . Bertin]

Nicholas Braden wrote:

> Ah, I understand now - I have a habit of forgetting that you can
> configure existing CMake builds by repeatedly invoking cmake. I don't
> know if such a feature exists but it definitely sounds useful.

Yes, that would be another use case!

R.


-- 

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

Re: [CMake] why no cumulative variable operations via the commandline?

[Nicholas Braden]

Ah, I understand now - I have a habit of forgetting that you can
configure existing CMake builds by repeatedly invoking cmake. I don't
know if such a feature exists but it definitely sounds useful.

On Sat, Mar 19, 2016 at 12:03 PM, René J. V.  wrote:
> Nicholas Braden wrote:
>
>
>> sense. Could you give an example of when you would find them useful? I
>> think maybe I am not understanding what you want.
>
> Yeah, I realise my explanation may not have been very clear.
>
>> If you just want to pass a list of values to a variable on the command
>> line, separate the values with semicolons:
>> cmake "-DMY_LIST=example value 1;example value 2"
>
>
> Now take an example where you are in fact assembling the commandline in
> subsequent steps. A good example would be a build system like MacPorts that 
> uses
> a kind of header files (so-called PortGroups) that can be included by the 
> build
> scripts for packages of dependent software (say, the Kate5 editor). There's a
> PortGroup for cmake itself, and there's a PortGroup for Qt5 and one for the 
> KF5
> frameworks. Each of those PortGroups can provide an element for MY_LIST (think
> of the module path, or preprocessor tokens), but evidently they cannot make
> assumptions about the contents of the variable.
>
> In other words, it would make sense for certain types of programmatically
> generated commandlines to do things like
>
> cmake -DMY_LIST+=val1 -DMY_LIST+=val3 -DMY_LIST+=val2
>
> At the moment we can do this reliably by using our own registers, one for each
> CMake variable that might be used this way, splicing them into the commandline
> just before invoking cmake. Not impossible, but somewhat of a hassle and a 
> pity
> for a feature that seems useful and probablye rather trivial to implement.
>
> CMake commandline can get quite long, so this might even make sense as a
> convenience for composing one manually.
>
> Of course it would be convenient to have a concatenation operator in the cmake
> language too ;)
>
> R
>
>
> --
>
> 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
-- 

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

Re: [CMake] why no cumulative variable operations via the commandline?

[René J . V . Bertin]

Nicholas Braden wrote:


> sense. Could you give an example of when you would find them useful? I
> think maybe I am not understanding what you want.

Yeah, I realise my explanation may not have been very clear.

> If you just want to pass a list of values to a variable on the command
> line, separate the values with semicolons:
> cmake "-DMY_LIST=example value 1;example value 2"


Now take an example where you are in fact assembling the commandline in 
subsequent steps. A good example would be a build system like MacPorts that 
uses 
a kind of header files (so-called PortGroups) that can be included by the build 
scripts for packages of dependent software (say, the Kate5 editor). There's a 
PortGroup for cmake itself, and there's a PortGroup for Qt5 and one for the KF5 
frameworks. Each of those PortGroups can provide an element for MY_LIST (think 
of the module path, or preprocessor tokens), but evidently they cannot make 
assumptions about the contents of the variable.

In other words, it would make sense for certain types of programmatically 
generated commandlines to do things like

cmake -DMY_LIST+=val1 -DMY_LIST+=val3 -DMY_LIST+=val2 

At the moment we can do this reliably by using our own registers, one for each 
CMake variable that might be used this way, splicing them into the commandline 
just before invoking cmake. Not impossible, but somewhat of a hassle and a pity 
for a feature that seems useful and probablye rather trivial to implement.

CMake commandline can get quite long, so this might even make sense as a 
convenience for composing one manually.

Of course it would be convenient to have a concatenation operator in the cmake 
language too ;)

R


-- 

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

Re: [CMake] Cmake cannot locate header file that exists on my system

[Chris Coutinho]

Thanks for the quickfix Andreas, that fixed the problem.

I've also found the bug that's the reason for the error, the compiler flags are 
mixing up relative and absolute pathnames. This is definitely a Dakota issue.

Setting verbose option on when executing make gives me a better idea of what's 
wrong:

--- OUTPUT ---

Scanning dependencies of target optpp
make[2]: Leaving directory '/opt/dakota/dakota-6.3.0.build'
make -f packages/OPTPP/src/CMakeFiles/optpp.dir/build.make 
packages/OPTPP/src/CMakeFiles/optpp.dir/build
make[2]: Entering directory '/opt/dakota/dakota-6.3.0.build'
[  5%] Building CXX object packages/OPTPP/src/CMakeFiles/optpp.dir/globals.C.o
cd /opt/dakota/dakota-6.3.0.build/packages/OPTPP/src && /usr/bin/c++   
-DBOOST_SIGNALS_NO_DEPRECATION_WARNING -DDAKOTA_OPTPP -DHAVE_STD 
-DHAVE_SYS_TIMES_H -DHAVE_SYS_TIME_H -DHAVE_TIMES -Doptpp_EXPORTS 
-I/opt/dakota/dakota-6.3.0.build/packages/OPTPP/include 
-I/opt/dakota/dakota-6.3.0.src/packages/OPTPP/include 
-I/usr/lib64/mpi/gcc/openmpi/lib64/cmake/Teuchos/../../../usr/lib64/mpi/gcc/openmpi/include/trilinos
 -I/opt/dakota/dakota-6.3.0.src/packages/ampl 
-I/opt/dakota/dakota-6.3.0.build/packages/ampl 
-I/opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/Base 
-I/opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/Constraints 
-I/opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/GSS 
-I/opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/Newton 
-I/opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/PDS 
-I/opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/Utils  -fPIC   -o 
CMakeFiles/optpp.dir/globals.C.o -c 
/opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/globals.C
In file included from 
/opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/globals.C:4:0:
/opt/dakota/dakota-6.3.0.src/packages/OPTPP/include/globals.h:22:41: fatal 
error: Teuchos_SerialDenseMatrix.hpp: No such file or directory
 #include "Teuchos_SerialDenseMatrix.hpp"
 ^
compilation terminated.

--- OUTPUT ---

The relevant line is when it tries to link to my machines trilinos package, 
when mixing up relative and absolute paths:

-I/usr/lib64/mpi/gcc/openmpi/lib64/cmake/Teuchos/../../../usr/lib64/mpi/gcc/openmpi/include/trilinos

Thanks for the workaround!

Cheers,
Chris


-Original Message-
From: Andreas Naumann [mailto:andreas-naum...@gmx.net]
Sent: donderdag 17 maart 2016 16:31
To: Chris Coutinho ; cmake@cmake.org
Subject: Re: [CMake] Cmake cannot locate header file that exists on my system

You have to add the directory /usr/include/trilinos to the c++ include 
directories. The fastest workaround would be, to add the directory to the 
CMAKE_CXX_FLAGS using ccmake or cmake-gui.
The better solution is to look for any hint regarding trilinos in the 
CMakeLists.txt of dakota and check, why the corresponding include directory is 
not added.

Regards,

Andreas

Am 17.03.2016 um 14:32 schrieb Chris Coutinho:
>
> I'm attempting to install Dakota 6.3.0 using cmake 3.5.0 on a 64-bit
> Linux box from source (to link python and MATLAB), and Dakota is
> having trouble finding some dependencies. I've been able to install
> and use Dakota successfully on my previous machine (64-bit, OpenSUSE
> 13.2, cmake 3.3.0) without any problems. Now that I upgraded to the
> more recent version of OpenSUSE (Opensuse Leap 42.1) and cmake
> (3.5.0), I'm not able to get past this error.
>
> I am using cmake to build the source and create a makefile.
> Configuring cmake is fine; however, when running 'make' I get an error
> at around 5% of compiling:
>
> /[ 5%] Building CXX object
> packages/OPTPP/src/CMakeFiles/optpp.dir/globals.C.o/
> /In file included from
> /opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/globals.C:4:0:/
> //opt/dakota/dakota-6.3.0.src/packages/OPTPP/include/globals.h:22:41:
> fatal error: Teuchos_SerialDenseMatrix.hpp: No such file or directory/
> /#include "Teuchos_SerialDenseMatrix.hpp"/ /^/ /compilation
> terminated./
>
> I looked for the missing file 'Teuchos_SerialDenseMatrix.hpp', and see
> that I have two copies on my computer from installing trilinos 11.4.3
> through the package manager. One is located under
> '/usr/include/trilinos', and the other is located
> '/usr/lib64/mpi/gcc/openmpi/include/trilinos'. I'm not sure why I have
> two copies...
>
> I added both of those directories to LD_LIBRARY_PATH in ~/.bashrc, but
> the error keeps coming up that Dakota isn't able to find the file. Can
> anyone help me with this installation issue?
>
> Kind regards,
>
> *Chris Coutinho,* EIT
>
> R Engineer
>
> REDstack, B.V.
>
> Pieter Zeemanstraat 6
>
> 8606 JR Sneek, The Netherlands
>
> work: +31 6  5785
>
> mobile: +31 6 1689 0287
>
> www.redstack.nl
>
> De informatie verzonden middels deze e-mail is uitsluitend bestemd
> voor de geadresseerde. Gebruik door anderen is niet toegestaan.
> Openbaarmaking, verspreiding en/of verstrekking van deze informatie
> aan derden is niet toegestaan. A.Hak staat niet in voor een 

Re: [CMake] File names with unbalanced square brackets

[Allen Barnett]

Hi Petr: You're right! If I rename "c" to "c]", it treats the whole
"/home/allen/test/b[;/home/allen/test/c]" as an element of the list. The
other file names are correctly split apart.
Thanks,
Allen

On Fri, Mar 18, 2016 at 3:17 AM, Petr Kmoch  wrote:

> Hi Allen.
>
> I'm not sure whether it's documented, but CMake interprets square brackets
> as escaping the semi-colon character (which means a semi-colon in square
> brackets will not work as a list item separator). You will probably have to
> translate the file names for CMake processing by replacing [ and ] with a
> different string, and replacing it back just before use outside of CMake.
>
> Petr
>
> On Thu, Mar 17, 2016 at 5:38 PM, Allen Barnett 
> wrote:
>
>> I inherited a set of files with somewhat unusual file names. In
>> particular, there were a couple of files whose names included a single
>> square bracket character. I processed these files with the file( GLOB ...)
>> command and then iterated over the resulting list with foreach. However,
>> the foreach command does not seem to break the resulting list apart
>> correctly. To make this concrete, I have a directory with files named "a",
>> "b[", and "c". file( GLOB FILES "*" ) returns the list:
>>
>> /home/allen/test/b[;/home/allen/test/c;/home/allen/test/a
>>
>> However,
>>
>> foreach( FILE ${FILES} )
>>   message( ${FILE} )
>> endforeach()
>>
>> just prints the same thing. That is, foreach does not split FILES into
>> separate pieces. If I rename "b[" to "b]" I see the same behavior. If I
>> rename "b[" to "b[]" (or even "b]["), then foreach successfully splits
>> FILES into the individual file names.
>>
>> I'm using CMake 3.3.2. I see the same thing on linux and windows.
>>
>> Thanks,
>> Allen
>>
>> --
>>
>> 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
>>
>
>
-- 

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-470-g0340538

[Brad King]

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, next has been updated
   via  03405388a88dd8a4c35c7bce8c7a3ff66978ea31 (commit)
   via  456ffca8a1c4b3596cc1ab68d1d5ef9f4ee3c03a (commit)
  from  0726f7a3f87a591af2d3f3e559b6ad2a16102062 (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=03405388a88dd8a4c35c7bce8c7a3ff66978ea31
commit 03405388a88dd8a4c35c7bce8c7a3ff66978ea31
Merge: 0726f7a 456ffca
Author: Brad King 
AuthorDate: Wed Mar 16 09:03:21 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Mar 16 09:03:21 2016 -0400

Merge topic 'use-GetCMakeRoot' into next

456ffca8 fixup! Avoid depending on CMAKE_ROOT cache entry internally 
(#16015)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=456ffca8a1c4b3596cc1ab68d1d5ef9f4ee3c03a
commit 456ffca8a1c4b3596cc1ab68d1d5ef9f4ee3c03a
Author: Brad King 
AuthorDate: Wed Mar 16 09:03:08 2016 -0400
Commit: Brad King 
CommitDate: Wed Mar 16 09:03:08 2016 -0400

fixup! Avoid depending on CMAKE_ROOT cache entry internally (#16015)

diff --git a/Source/cmGlobalVisualStudioGenerator.cxx 
b/Source/cmGlobalVisualStudioGenerator.cxx
index 14e9a88..00bb511 100644
--- a/Source/cmGlobalVisualStudioGenerator.cxx
+++ b/Source/cmGlobalVisualStudioGenerator.cxx
@@ -184,7 +184,6 @@ void RegisterVisualStudioMacros(const std::string& 
macrosFile,
 //
 void cmGlobalVisualStudioGenerator::ConfigureCMakeVisualStudioMacros()
 {
-  cmMakefile* mf = this->LocalGenerators[0]->GetMakefile();
   std::string dir = this->GetUserMacrosDirectory();
 
   if (dir != "")

---

Summary of changes:
 Source/cmGlobalVisualStudioGenerator.cxx |1 -
 1 file changed, 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.5.0-478-g310e701

[Brad King]

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, next has been updated
   via  310e701169c2e7704061935822a05c5d4c01b782 (commit)
   via  b06c21784ab38aa9c82998483999f2dd24a106da (commit)
   via  6e24546caea91493cd24c0ef60a6e54740f55f74 (commit)
   via  f5eda7069027790a73f2e7f72d81bd5c0db46eae (commit)
   via  7fff134735d774a27b3d2fb5ddb16f5b9f9bbeb6 (commit)
   via  98f3edcec96b3854126c37e9a44915e77fcd9867 (commit)
  from  50c0287ee22e19da6a6c4fb5c9e5ed752e717073 (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=310e701169c2e7704061935822a05c5d4c01b782
commit 310e701169c2e7704061935822a05c5d4c01b782
Merge: 50c0287 b06c217
Author: Brad King 
AuthorDate: Wed Mar 16 09:08:15 2016 -0400
Commit: Brad King 
CommitDate: Wed Mar 16 09:08:15 2016 -0400

Merge branch 'master' into next


---

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
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] File names with unbalanced square brackets

[Petr Kmoch]

Hi Allen.

I'm not sure whether it's documented, but CMake interprets square brackets
as escaping the semi-colon character (which means a semi-colon in square
brackets will not work as a list item separator). You will probably have to
translate the file names for CMake processing by replacing [ and ] with a
different string, and replacing it back just before use outside of CMake.

Petr

On Thu, Mar 17, 2016 at 5:38 PM, Allen Barnett 
wrote:

> I inherited a set of files with somewhat unusual file names. In
> particular, there were a couple of files whose names included a single
> square bracket character. I processed these files with the file( GLOB ...)
> command and then iterated over the resulting list with foreach. However,
> the foreach command does not seem to break the resulting list apart
> correctly. To make this concrete, I have a directory with files named "a",
> "b[", and "c". file( GLOB FILES "*" ) returns the list:
>
> /home/allen/test/b[;/home/allen/test/c;/home/allen/test/a
>
> However,
>
> foreach( FILE ${FILES} )
>   message( ${FILE} )
> endforeach()
>
> just prints the same thing. That is, foreach does not split FILES into
> separate pieces. If I rename "b[" to "b]" I see the same behavior. If I
> rename "b[" to "b[]" (or even "b]["), then foreach successfully splits
> FILES into the individual file names.
>
> I'm using CMake 3.3.2. I see the same thing on linux and windows.
>
> Thanks,
> Allen
>
> --
>
> 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
>
-- 

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

Re: [cmake-developers] Startup Project Configuration [mantis 15578]

[Taylor Braun-Jones]

Here's Davy's patch rebased against current master with a unit test
added. Tested on Visual Studio 2013 only. Let me know if I screwed up
the rebase. Some conflicts weren't totally obvious to me how to
handle.

Thanks,
Taylor

On Thu, Jun 18, 2015 at 9:10 AM, Brad King  wrote:
> On 06/16/2015 07:34 PM, Davy Durham wrote:
>> Would that involve different macro's anyhow?  I could try
>> and write a macro specifically to check that, or were you thinking I
>> should be able to use the macros that are already there?  And would you
>> be opposed to my writing a dedicated one?
>
> Please write your own if needed.  I was just pointing out that the
> test already does something similar to what you need.
>
> 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:
> http://public.kitware.com/mailman/listinfo/cmake-developers


0001-Add-VS_STARTUP_PROJECT-directory-property-15578.patch
Description: Binary data


0002-fixup-Add-VS_STARTUP_PROJECT-directory-property-1557.patch
Description: Binary data


0003-fixup-Add-VS_STARTUP_PROJECT-directory-property-1557.patch
Description: Binary data


0004-fixup-Add-VS_STARTUP_PROJECT-directory-property-1557.patch
Description: Binary data
-- 

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] Proper way to redefine build type compiler options

[Neil Carlson]

What is considered best practice for (re)defining build-type compiler
options for a project, especially one that may find itself as a subproject
of something larger?

To be concrete, say for Debug I want the project to use a set of warn/check
options.  Should I set (or add to) CMAKE_C_FLAGS_DEBUG, and if so
should I use the CACHE FORCE options to get it into the cache? (I don't
have a good feel for the implications.)  Or is it better to append to
CMAKE_C_FLAGS?  I observe that the value of the latter precedes the
value of the build-type variables on the compile line, and so it can't
override
those defaults.  Or is some other way best?

Also, say there was a compiler flag that was absolutely required.  Where
to add it so that it didn't get overridden by anything coming in through
either CMAKE_C_FLAGS or the build-type specific variables?

Thanks
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] why no cumulative variable operations via the commandline?

[Nicholas Braden]

The command line is the first point where variables can be defined
(all code runs after this), so I am not sure where you expect
pre-existing values to come from in order for a += or -= to make
sense. Could you give an example of when you would find them useful? I
think maybe I am not understanding what you want.

If you just want to pass a list of values to a variable on the command
line, separate the values with semicolons:
cmake "-DMY_LIST=example value 1;example value 2"

On Sat, Mar 19, 2016 at 4:52 AM, René J. V.  wrote:
> Hi,
>
> I've been wondering about something that is a real stumbling block in a
> build/distribution system like MacPorts where settings can be modified in any
> number of consecutive steps. For instance, depending on what dependencies a
> package ("port") requires and how those dependencies are installed, elements 
> may
> be added to the module search path repeatedly.
>
> In cmake language one does cumulative operations like that explicitly, but I'm
> not aware of any way to do that on the command line.
>
> Is there a reason why one cannot do something like
>
> cmake -DCMAKE_FOO+=bar
>
> or
>
> CMAKE -ACMAKE_FOO=bar (-A for add instead of define)
>
> (or -DCMAKE_FOO-=bar, for that matter...) ?
>
> Thanks,
> René
>
> --
>
> 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
-- 

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-506-g65e591c

[Zack Galbreath]

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, next has been updated
   via  65e591cea4a7257f2891db15136e09ce2db5da22 (commit)
   via  04b1ad0f0602cce02b637e966d09693ee99468f6 (commit)
  from  b94aee61c7bbc9b64d408f41811e16ef8274ec03 (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=65e591cea4a7257f2891db15136e09ce2db5da22
commit 65e591cea4a7257f2891db15136e09ce2db5da22
Merge: b94aee6 04b1ad0
Author: Zack Galbreath 
AuthorDate: Thu Mar 17 12:47:48 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Mar 17 12:47:48 2016 -0400

Merge topic 'timeout_after_match' into next

04b1ad0f New test property: TIMEOUT_AFTER_MATCH


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=04b1ad0f0602cce02b637e966d09693ee99468f6
commit 04b1ad0f0602cce02b637e966d09693ee99468f6
Author: Zack Galbreath 
AuthorDate: Thu Feb 18 13:59:18 2016 -0500
Commit: Zack Galbreath 
CommitDate: Thu Mar 10 11:07:16 2016 -0500

New test property: TIMEOUT_AFTER_MATCH

Allow a test N seconds to complete after we detect a matching line
in its output.

diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index d6618fe..9051ca0 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -303,6 +303,7 @@ Properties on Tests
/prop_test/RUN_SERIAL
/prop_test/SKIP_RETURN_CODE
/prop_test/TIMEOUT
+   /prop_test/TIMEOUT_AFTER_MATCH
/prop_test/WILL_FAIL
/prop_test/WORKING_DIRECTORY
 
diff --git a/Help/prop_test/TIMEOUT_AFTER_MATCH.rst 
b/Help/prop_test/TIMEOUT_AFTER_MATCH.rst
new file mode 100644
index 000..a191a9c
--- /dev/null
+++ b/Help/prop_test/TIMEOUT_AFTER_MATCH.rst
@@ -0,0 +1,37 @@
+TIMEOUT_AFTER_MATCH
+---
+
+Change a test's timeout duration after a matching line is encountered
+in its output.
+
+Usage
+^
+
+.. code-block:: cmake
+
+ add_test(mytest ...)
+ set_property(TEST mytest PROPERTY TIMEOUT_AFTER_MATCH "${seconds}" "${regex}")
+
+Description
+^^^
+
+Allow a test ``seconds`` to complete after ``regex`` is encountered in
+its output.
+
+When the test outputs a line that matches ``regex`` its start time is
+reset to the current time and its timeout duration is changed to
+``seconds``.  Prior to this, the timeout duration is determined by the
+:prop_test:`TIMEOUT` property or the :variable:`CTEST_TEST_TIMEOUT`
+variable if either of these are set.
+
+:prop_test:`TIMEOUT_AFTER_MATCH` is useful for avoiding spurious
+timeouts when your test must wait for some system resource to become
+available before it can execute.  Set :prop_test:`TIMEOUT` to a longer
+duration that accounts for resource acquisition and use
+:prop_test:`TIMEOUT_AFTER_MATCH` to control how long the actual test
+is allowed to run.
+
+If the required resource can be controlled by CTest you should use
+:prop_test:`RESOURCE_LOCK` instead of :prop_test:`TIMEOUT_AFTER_MATCH`.
+This property should be used when only the test itself can determine
+when its required resources are available.
diff --git a/Source/CTest/cmCTestRunTest.cxx b/Source/CTest/cmCTestRunTest.cxx
index d108592..7f3a077 100644
--- a/Source/CTest/cmCTestRunTest.cxx
+++ b/Source/CTest/cmCTestRunTest.cxx
@@ -64,6 +64,28 @@ bool cmCTestRunTest::CheckOutput()
  this->GetIndex() << ": " << line << std::endl);
   this->ProcessOutput += line;
   this->ProcessOutput += "\n";
+
+  // Check for TIMEOUT_AFTER_MATCH property.
+  if (!this->TestProperties->TimeoutRegularExpressions.empty())
+{
+std::vector >::iterator regIt;
+for ( regIt = this->TestProperties->TimeoutRegularExpressions.begin();
+  regIt != this->TestProperties->TimeoutRegularExpressions.end();
+  ++ regIt )
+  {
+  if ( regIt->first.find(this->ProcessOutput.c_str()) )
+{
+cmCTestLog(this->CTest, HANDLER_VERBOSE_OUTPUT,
+   "Test timeout changed to " <<
+   this->TestProperties->AlternateTimeout << std::endl);
+this->TestProcess->ResetStartTime();
+this->TestProcess->ChangeTimeout(
+  this->TestProperties->AlternateTimeout);
+break;
+}
+  }
+}
   }
 else // if(p == cmsysProcess_Pipe_Timeout)
   {
diff --git a/Source/CTest/cmCTestTestHandler.cxx 
b/Source/CTest/cmCTestTestHandler.cxx
index b6a4819..59ed98e 100644
--- 

Re: [cmake-developers] CMake aliasing system

[Ruslan Baratov via cmake-developers]

I've openned new issue for further discussion:
* https://github.com/ruslo/CMake/issues/3

On 18-Mar-16 06:24, Tamás Kenéz wrote:
Ruslo, I think we all could argue both against and for implementing 
cmake-ini files inside the cmake command. I mean I'm also aware of all 
the pros and cons. It's just that we weigh differently.
I like loosely connected simpler building blocks and my own 
cmake-wrapping extension script works fine, that's why I thought you 
would not lose anything with that.


>> git commit --author="John Doe" --email="john@example.com" 
 --branch="master"

>> git push --remote="git://awesome.example.com "
> This is a complete nonsense!

I agree and that's why I think cmake ini files is a good idea.

Tamas

On Tue, Mar 15, 2016 at 3:25 AM, Ruslan Baratov 
> wrote:


On 15-Mar-16 02:42, Tamás Kenéz wrote:

I also doubt this belongs to upstream. But you could write a
single, generic script which forwards its arguments to cmake and
also accepts and processes the additional parameters along the
way. I don't think we'd lose anything:

cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS

This is the approach I took as I needed features like you
described. But if there would be a mature, versatile,
community-tested script I'd be willing to use it and contribute
to it.

As you can see I'm already using script `build.py` and there is
not enough power for now (even if it extends CMake basic
functionality a lot) so I was thinking to introduce global/local
ini-configuration file anyway. Then I realize that most of the
`build.py` functions can be implemented in such ini-configuration.
So why not use CMake? Why for example not extend CMake GUI with
this feature support? Why do users need to install some extra
tools instead of just one?

Global/local configuration files in not something special. Git for
example has same system, yes it increase complexity but literally
every user store setting there.
Just imagine you have to write something like this every commit +
push:

> git commit --author="John Doe" --email="john@example.com"
 --branch="master"
> git push --remote="git://awesome.example.com
"

This is a complete nonsense!

So I'm planning to make a fork anyway and do some experiments even
if it will not accepted to upstream.

Ruslo



Tamas

On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via
cmake-developers > wrote:

On 14-Mar-16 21:59, Brad King wrote:

On 03/12/2016 08:04 AM, Ruslan Baratov via
cmake-developers wrote:

I guess it is a well known fact that cmake command is
almost never
executed alone and for non-trivial examples usually
hold some extra
arguments (home directory, build directory, verbosity
level, toolchains,
options, ...). Also I guess that such commands
doesn't change from
day-to-day development process and an obvious way to
reduce typing is to
create wrapper build scripts (.bat or .sh, I
personally use a Python one).

Sorry, I don't think something like this belongs
upstream.  It can easily
be done with shell aliases or other custom scripts.

I've got quite opposite experience. It's hard to say that
family of custom scripts (+ a lot of environment variables in
.bashrc)  is an "easy shell scripting", example:
*

https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py

 We shouldn't increase the complexity of the CMake
command line interface further.

To be clear this feature required only one new CMake option.
The rest is responsibility of some pre-build parsing module.

In general I feel sad that CMake will not became more
user-friendly in this exact part. Though the only proves of
my point that can be provided here is a users experience.
Since I don't see any feedback here I'm out of arguments...

Ruslo

-- 


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: 

[Cmake-commits] CMake branch, next, updated. v3.5.0-504-gb94aee6

[Brad King]

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, next has been updated
   via  b94aee61c7bbc9b64d408f41811e16ef8274ec03 (commit)
   via  6a6e5d89b5665508276d65de4c82f0b4daa2dcfd (commit)
   via  be5a8973c39e13d8978c242936dca63a9a746a57 (commit)
  from  866631102f865c7828bca0426c78b97c8836195d (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=b94aee61c7bbc9b64d408f41811e16ef8274ec03
commit b94aee61c7bbc9b64d408f41811e16ef8274ec03
Merge: 8666311 6a6e5d8
Author: Brad King 
AuthorDate: Thu Mar 17 10:41:53 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Mar 17 10:41:53 2016 -0400

Merge topic 'GenerateExportHeader-fix-name-leak' into next

6a6e5d89 GenerateExportHeader: Allow common NO_DEPRECATED_MACRO_NAME for 
multiple libs
be5a8973 GenerateExportHeader: Do not define DEFINE_NO_DEPRECATED (#16022)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6a6e5d89b5665508276d65de4c82f0b4daa2dcfd
commit 6a6e5d89b5665508276d65de4c82f0b4daa2dcfd
Author: Andreas Schuh 
AuthorDate: Thu Mar 17 11:09:53 2016 +
Commit: Brad King 
CommitDate: Thu Mar 17 10:40:58 2016 -0400

GenerateExportHeader: Allow common NO_DEPRECATED_MACRO_NAME for multiple 
libs

diff --git a/Modules/exportheader.cmake.in b/Modules/exportheader.cmake.in
index 7058f54..7cfbcbd 100644
--- a/Modules/exportheader.cmake.in
+++ b/Modules/exportheader.cmake.in
@@ -34,7 +34,9 @@
 #endif
 
 #if @DEFINE_NO_DEPRECATED@ /* DEFINE_NO_DEPRECATED */
-# define @NO_DEPRECATED_MACRO_NAME@
+#  ifndef @NO_DEPRECATED_MACRO_NAME@
+#define @NO_DEPRECATED_MACRO_NAME@
+#  endif
 #endif
 
 #endif

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=be5a8973c39e13d8978c242936dca63a9a746a57
commit be5a8973c39e13d8978c242936dca63a9a746a57
Author: Andreas Schuh 
AuthorDate: Thu Mar 17 11:02:26 2016 +
Commit: Brad King 
CommitDate: Thu Mar 17 10:40:24 2016 -0400

GenerateExportHeader: Do not define DEFINE_NO_DEPRECATED (#16022)

Previously we allowed this definition to persist outside our header.
This would cause conflicts across multiple such headers because the name
was always the same.  Fix this by avoiding the definition altogether.

diff --git a/Modules/GenerateExportHeader.cmake 
b/Modules/GenerateExportHeader.cmake
index 4f4efbc..6389d30 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -341,7 +341,9 @@ macro(_DO_GENERATE_EXPORT_HEADER TARGET_LIBRARY)
   string(MAKE_C_IDENTIFIER ${STATIC_DEFINE} STATIC_DEFINE)
 
   if(_GEH_DEFINE_NO_DEPRECATED)
-set(DEFINE_NO_DEPRECATED TRUE)
+set(DEFINE_NO_DEPRECATED 1)
+  else()
+set(DEFINE_NO_DEPRECATED 0)
   endif()
 
   if(_GEH_NO_DEPRECATED_MACRO_NAME)
diff --git a/Modules/exportheader.cmake.in b/Modules/exportheader.cmake.in
index 118de16..7058f54 100644
--- a/Modules/exportheader.cmake.in
+++ b/Modules/exportheader.cmake.in
@@ -33,8 +33,7 @@
 #  define @DEPRECATED_MACRO_NAME@_NO_EXPORT @NO_EXPORT_MACRO_NAME@ 
@DEPRECATED_MACRO_NAME@
 #endif
 
-#cmakedefine01 DEFINE_NO_DEPRECATED
-#if DEFINE_NO_DEPRECATED
+#if @DEFINE_NO_DEPRECATED@ /* DEFINE_NO_DEPRECATED */
 # define @NO_DEPRECATED_MACRO_NAME@
 #endif
 
diff --git 
a/Tests/Module/GenerateExportHeader/reference/Empty/libshared_export.h 
b/Tests/Module/GenerateExportHeader/reference/Empty/libshared_export.h
index b6749b2..e8af0a5 100644
--- a/Tests/Module/GenerateExportHeader/reference/Empty/libshared_export.h
+++ b/Tests/Module/GenerateExportHeader/reference/Empty/libshared_export.h
@@ -33,9 +33,10 @@
 #  define LIBSHARED_DEPRECATED_NO_EXPORT LIBSHARED_NO_EXPORT 
LIBSHARED_DEPRECATED
 #endif
 
-#define DEFINE_NO_DEPRECATED 0
-#if DEFINE_NO_DEPRECATED
-# define LIBSHARED_NO_DEPRECATED
+#if 0 /* DEFINE_NO_DEPRECATED */
+#  ifndef LIBSHARED_NO_DEPRECATED
+#define LIBSHARED_NO_DEPRECATED
+#  endif
 #endif
 
 #endif
diff --git 
a/Tests/Module/GenerateExportHeader/reference/Empty/libstatic_export.h 
b/Tests/Module/GenerateExportHeader/reference/Empty/libstatic_export.h
index e8000e2..598bd71 100644
--- a/Tests/Module/GenerateExportHeader/reference/Empty/libstatic_export.h
+++ b/Tests/Module/GenerateExportHeader/reference/Empty/libstatic_export.h
@@ -33,9 +33,10 @@
 #  define LIBSTATIC_DEPRECATED_NO_EXPORT LIBSTATIC_NO_EXPORT 
LIBSTATIC_DEPRECATED
 #endif
 
-#define DEFINE_NO_DEPRECATED 0
-#if DEFINE_NO_DEPRECATED
-# define LIBSTATIC_NO_DEPRECATED
+#if 0 /* DEFINE_NO_DEPRECATED */
+#  ifndef LIBSTATIC_NO_DEPRECATED
+#define 

[CMake] Cmake cannot locate header file that exists on my system

[Chris Coutinho]

I'm attempting to install Dakota 6.3.0 using cmake 3.5.0 on a 64-bit Linux box 
from source (to link python and MATLAB), and Dakota is having trouble finding 
some dependencies. I've been able to install and use Dakota successfully on my 
previous machine (64-bit, OpenSUSE 13.2, cmake 3.3.0) without any problems. Now 
that I upgraded to the more recent version of OpenSUSE (Opensuse Leap 42.1) and 
cmake (3.5.0), I'm not able to get past this error.

I am using cmake to build the source and create a makefile. Configuring cmake 
is fine; however, when running 'make' I get an error at around 5% of compiling:

[ 5%] Building CXX object packages/OPTPP/src/CMakeFiles/optpp.dir/globals.C.o
In file included from 
/opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/globals.C:4:0:
/opt/dakota/dakota-6.3.0.src/packages/OPTPP/include/globals.h:22:41: fatal 
error: Teuchos_SerialDenseMatrix.hpp: No such file or directory
#include "Teuchos_SerialDenseMatrix.hpp"
^
compilation terminated.

I looked for the missing file 'Teuchos_SerialDenseMatrix.hpp', and see that I 
have two copies on my computer from installing trilinos 11.4.3 through the 
package manager. One is located under '/usr/include/trilinos', and the other is 
located '/usr/lib64/mpi/gcc/openmpi/include/trilinos'. I'm not sure why I have 
two copies...

I added both of those directories to LD_LIBRARY_PATH in ~/.bashrc, but the 
error keeps coming up that Dakota isn't able to find the file. Can anyone help 
me with this installation issue?


Kind regards,

Chris Coutinho, EIT
R Engineer

REDstack, B.V.
Pieter Zeemanstraat 6
8606 JR Sneek, The Netherlands
work: +31 6  5785
mobile: +31 6 1689 0287
www.redstack.nl

De informatie verzonden middels deze e-mail is uitsluitend bestemd voor de 
geadresseerde. Gebruik door anderen is niet toegestaan. Openbaarmaking, 
verspreiding en/of verstrekking van deze informatie aan derden is niet 
toegestaan. A.Hak staat niet in voor een juiste en volledige overbrenging van 
de inhoud, alsmede de tijdige ontvangst daarvan.

The information contained in this communication, including files, is 
confidential and legally privileged. It is intended solely for the use of the 
individual or entity to whom it is addressed and others authorized to receive 
it. If you are not the intended recipient you are hereby notified that any 
disclosure, copying, distribution or taking any action in reliance to the 
contents of this information, is strictly prohibited and may be unlawful. A.Hak 
is not liable for the proper, complete and timely transmission of the 
information contained in this communication.
-- 

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

[cmake-developers] [CMake 0016021]: Cannot build on OS X with GCC

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16021 
== 
Reported By:Erik Schnetter
Assigned To:
== 
Project:CMake
Issue ID:   16021
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2016-03-16 14:14 EDT
Last Modified:  2016-03-16 14:14 EDT
== 
Summary:Cannot build on OS X with GCC
Description: 
I cannot build cmake 3.5.0 on OS X "El Capitan" with GCC 5.3. After configuring
normally, the build aborts with an error message. It seems that cmake uses some
system header files with Apple-specific extensions that GCC cannot handle.

These extensions seem to have to do with the user interface; if so, there should
be an option to not build the parts that cannot be built, and still build the
"regular" cmake.

cmake 3.4.3 builds fine with the same setup.


Steps to Reproduce: 
Install GCC 5.3 via MacPorts; make GCC the default compiler

tar xzf cmake-3.5.0.tar.gz 
cd cmake-3.5.0
# Building without the OpenSSL flag aborts with an error
./configure -- -DCMAKE_USE_OPENSSL=ON
gmake


Additional Information: 
The build aborts with

[ 85%] Building CXX object
Source/CMakeFiles/CPackLib.dir/CPack/cmCPackDragNDropGenerator.cxx.o
In file included from /usr/include/Availability.h:168:0,
 from /usr/include/inttypes.h:224,
 from /tmp/cmake-3.5.0/Utilities/KWIML/include/kwiml/int.h:194,
 from /tmp/cmake-3.5.0/Utilities/cm_kwiml.h:22,
 from /tmp/cmake-3.5.0/Source/cmStandardIncludes.h:34,
 from /tmp/cmake-3.5.0/Source/cmObject.h:15,
 from /tmp/cmake-3.5.0/Source/CPack/cmCPackGenerator.h:16,
 from
/tmp/cmake-3.5.0/Source/CPack/cmCPackDragNDropGenerator.h:16,
 from
/tmp/cmake-3.5.0/Source/CPack/cmCPackDragNDropGenerator.cxx:13:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfoDeprecated.h:1242:34:
error: expected '}' before '__attribute__'
   kLSHandlerOptionsDefault   __OSX_AVAILABLE_BUT_DEPRECATED_MSG(__MAC_10_4,
__MAC_10_11, __IPHONE_4_0, __IPHONE_9_0, "Creator codes are deprecated on OS
X.") = 0,
  ^
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfo.h:529:0,
 from
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LaunchServices.h:27,
 from
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:39,
 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,
 from
/tmp/cmake-3.5.0/Source/CPack/cmCPackDragNDropGenerator.cxx:34:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfoDeprecated.h:1242:163:
error: expected unqualified-id before '=' token
   kLSHandlerOptionsDefault   __OSX_AVAILABLE_BUT_DEPRECATED_MSG(__MAC_10_4,
__MAC_10_11, __IPHONE_4_0, __IPHONE_9_0, "Creator codes are deprecated on OS
X.") = 0,


 ^
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfoDeprecated.h:1294:1:
error: expected declaration before '}' token
 }
 ^
Source/CMakeFiles/CPackLib.dir/build.make:518: recipe for target
'Source/CMakeFiles/CPackLib.dir/CPack/cmCPackDragNDropGenerator.cxx.o' failed
gmake[2]: ***
[Source/CMakeFiles/CPackLib.dir/CPack/cmCPackDragNDropGenerator.cxx.o] Error 1
CMakeFiles/Makefile2:2018: recipe for target
'Source/CMakeFiles/CPackLib.dir/all' failed
gmake[1]: *** [Source/CMakeFiles/CPackLib.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
gmake: *** [all] Error 2

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-16 14:14 Erik Schnetter New Issue
==

-- 

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-commits] CMake branch, next, updated. v3.5.0-523-g94bdf23

[Brad King]

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, next has been updated
   via  94bdf2355be80aca48c18376f4f7e8b79f8c5c70 (commit)
   via  030b8e8b0570e312ceee40c1ac12367ea8c0835d (commit)
  from  7a56d861f71e5d929a48f477657b70c6cad16159 (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=94bdf2355be80aca48c18376f4f7e8b79f8c5c70
commit 94bdf2355be80aca48c18376f4f7e8b79f8c5c70
Merge: 7a56d86 030b8e8
Author: Brad King 
AuthorDate: Fri Mar 18 09:55:51 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Mar 18 09:55:51 2016 -0400

Merge topic 'cpack-osx-optional-CoreServices' into next

030b8e8b fixup! CPack: Avoid using OS X CoreServices if compiler fails on 
header


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=030b8e8b0570e312ceee40c1ac12367ea8c0835d
commit 030b8e8b0570e312ceee40c1ac12367ea8c0835d
Author: Brad King 
AuthorDate: Fri Mar 18 09:54:36 2016 -0400
Commit: Brad King 
CommitDate: Fri Mar 18 09:54:36 2016 -0400

fixup! CPack: Avoid using OS X CoreServices if compiler fails on header

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index eaad702..75c179f 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -722,17 +722,17 @@ if(APPLE)
 CPack/cmCPackOSXX11Generator.cxx
 CPack/cmCPackPackageMakerGenerator.cxx
 )
-  check_include_file("CoreServices/CoreServices.h" HAVE_CoreServices)
-  if(HAVE_CoreServices)
-set_property(SOURCE CPack/cmCPackDragNDropGenerator.cxx PROPERTY 
COMPILE_DEFINITIONS HAVE_CoreServices)
-  endif()
 endif()
 
 # Build CPackLib
 add_library(CPackLib ${CPACK_SRCS})
 target_link_libraries(CPackLib CMakeLib)
 if(APPLE)
-  target_link_libraries(CPackLib "-framework CoreServices")
+  check_include_file("CoreServices/CoreServices.h" HAVE_CoreServices)
+  if(HAVE_CoreServices)
+set_property(SOURCE CPack/cmCPackDragNDropGenerator.cxx PROPERTY 
COMPILE_DEFINITIONS HAVE_CoreServices)
+target_link_libraries(CPackLib "-framework CoreServices")
+  endif()
 endif()
 
 if(APPLE)

---

Summary of changes:
 Source/CMakeLists.txt |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[CMake] Building with Cmake using Boost problem

[Karel Geiregat]

Dear people at cmake


Today, I have a problem with using cmake and Boost to build up Apache Avro
, which is a data-serializer.I have to use that
"avro" which can be built with cmake and boost. However, there is a problem
when building up the component by using the CMakeLists.txt file.

I have put an SO question

on this matter, but there, I didn't have gotten an useful answer/comment so
far. After placing the question, i have done further searches in the
meanwhile to find a solution. I have now the latest, stable builds, but
still no success.

First, the versions of Cmake and Boost and my OS:

   - cmake: v3.5.0
   - Boost: v1.60.0
   - OS: Windows 10 64 bit

cmake is a part of the system path:

PS C:\Users\geire> cmake -version
> cmake version 3.5.0
>
> CMake suite maintained and supported by Kitware (kitware.com/cmake).
>


Now, I want to build up avro, you have to use cmake. My target platform is
C++, so i used the C++ version there. The CMakeLists.txt content is here
below;

#
> # Licensed to the Apache Software Foundation (ASF) under one
> # or more contributor license agreements.  See the NOTICE file
> # distributed with this work for additional information
> # regarding copyright ownership.  The ASF licenses this file
> # to you under the Apache License, Version 2.0 (the
> # "License"); you may not use this file except in compliance
> # with the License.  You may obtain a copy of the License at
> #
> #   http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing,
> # software distributed under the License is distributed on an
> # "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> # KIND, either express or implied.  See the License for the
> # specific language governing permissions and limitations
> # under the License.
> #
> cmake_minimum_required (VERSION 2.6)
>
> set (CMAKE_LEGACY_CYGWIN_WIN32 0)
>
> if (NOT DEFINED CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_NO_WARNINGS)
> set (CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_NO_WARNINGS ON)
> endif()
>
> if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/VERSION.txt)
> file(READ "${CMAKE_CURRENT_SOURCE_DIR}/VERSION.txt" AVRO_VERSION)
> else (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/VERSION.txt)
> file(READ "${CMAKE_CURRENT_SOURCE_DIR}/../../share/VERSION.txt"
> AVRO_VERSION)
> endif (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/VERSION.txt)
>
> set (AVRO_VERSION_MAJOR ${AVRO_VERSION})
> set (AVRO_VERSION_MINOR "0")
>
> project (Avro-cpp)
>
> if (WIN32 AND NOT CYGWIN AND NOT MSYS)
> add_definitions (/EHa)
> add_definitions (
> -DBOOST_REGEX_DYN_LINK
> -DBOOST_FILESYSTEM_DYN_LINK
> -DBOOST_SYSTEM_DYN_LINK
> -DBOOST_IOSTREAMS_DYN_LINK
> -DBOOST_PROGRAM_OPTIONS_DYN_LINK
> -DBOOST_ALL_NO_LIB)
> endif()
>
> if (CMAKE_COMPILER_IS_GNUCXX)
> set(CMAKE_CXX_FLAGS "-Wall")
> endif ()
>
>
>
> #  edit, these 2 lines here below are original
> # find_package (Boost 1.38 REQUIRED
> #COMPONENTS filesystem system program_options iostreams)
> # === commented these 2 lines here above and added the following here
> below till "end edit"


>
set(BOOST_ROOT D:/software/boost_1_60_0)
> set(BOOST_INCLUDEDIR D:/software/boost_1_60_0/boost)
> set(BOOST_LIBRARYDIR D:/software/boost_1_60_0/stage/lib)
>
> find_package(Boost 1.54.0
>COMPONENTS filesystem system program_options iostreams REQUIRED
> )
>
> # end edit
>
> add_definitions (${Boost_LIB_DIAGNOSTIC_DEFINITIONS})
>
> include_directories (api ${CMAKE_CURRENT_BINARY_DIR} ${Boost_INCLUDE_DIRS})
>
> set (AVRO_SOURCE_FILES
> impl/Compiler.cc impl/Node.cc
> impl/NodeImpl.cc impl/ResolverSchema.cc impl/Schema.cc
> impl/Types.cc impl/ValidSchema.cc impl/Zigzag.cc
> impl/BinaryEncoder.cc impl/BinaryDecoder.cc
> impl/Stream.cc impl/FileStream.cc
> impl/Generic.cc impl/GenericDatum.cc
> impl/DataFile.cc
> impl/parsing/Symbol.cc
> impl/parsing/ValidatingCodec.cc
> impl/parsing/JsonCodec.cc
> impl/parsing/ResolvingDecoder.cc
> impl/json/JsonIO.cc
> impl/json/JsonDom.cc
> impl/Resolver.cc impl/Validator.cc
> )
>
> add_library (avrocpp SHARED ${AVRO_SOURCE_FILES})
>
> set_property (TARGET avrocpp
> APPEND PROPERTY COMPILE_DEFINITIONS AVRO_DYN_LINK)
>
> add_library (avrocpp_s STATIC ${AVRO_SOURCE_FILES})
>
> set_property (TARGET avrocpp avrocpp_s
> APPEND PROPERTY COMPILE_DEFINITIONS AVRO_SOURCE)
>
> set_target_properties (avrocpp PROPERTIES
> VERSION ${AVRO_VERSION_MAJOR}.${AVRO_VERSION_MINOR})
>
> set_target_properties (avrocpp_s PROPERTIES
> VERSION ${AVRO_VERSION_MAJOR}.${AVRO_VERSION_MINOR})
>
> target_link_libraries (avrocpp ${Boost_LIBRARIES})
>
> add_executable (precompile test/precompile.cc)
>
> target_link_libraries (precompile avrocpp_s ${Boost_LIBRARIES})
>
> macro (gen file ns)
> add_custom_command (OUTPUT 

Re: [CMake] Building with Cmake using Boost problem (Karel Geiregat)

[Karel Geiregat]

OH GOD !

Just saying, i have spent 3 days finding a solution to this problem since
the files got provided from a 3th party provider. The team that got
assigned to this project asked me (i'm senior QA and responsible for
further development). In the meanwhile, this project has to be set in
standby phase because of the building problems.

We, all, and especially I certainly have overlooked on that part. I didn't
understood it well. When i have generated the dll's using the build process
described in Boost manuals ... cmake found the libraries !
Now, an other issue arises. But at least cmake is now able to find the
boost libraries ^^

Thanks !

2016-03-16 22:35 GMT+01:00 Knox, Kent :

> It looks like you built static libraries with b2:
> PS D:\software\boost_1_60_0\stage\lib> Get-ChildItem libboost_filesystem*
> > -name
> > libboost_filesystem-vc140-mt-1_60.lib
> > libboost_filesystem-vc140-mt-gd-1_60.lib
>
> But I believe you are telling cmake (or boost preprocessor?) to search for
> dynamic libraries:
> > add_definitions (
> > -DBOOST_REGEX_DYN_LINK
> > -DBOOST_FILESYSTEM_DYN_LINK
> > -DBOOST_SYSTEM_DYN_LINK
>
> Try building dynamic (.dll w/ import libs) boost libraries and see if
> cmake finds them.
>
> Kent
> 
> --
>
> 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
>
-- 

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

[CMake] Difficulty making MPI and OpenMP Fortran shared library with CMake

[Rand Huso]

I would like to use CMake for a personal project instead of make (which
does work), but I can't seem to get CMake to work the way I think it
should. The command "cmake ." runs fine, but the make produces this:

Scanning dependencies of target MIFF
Linking Fortran shared library libMIFF.so
gfortran: fatal error: no input files; unwilling to write output files
compilation terminated.
make[2]: *** [src/libMIFF.so] Error 4
make[1]: *** [src/CMakeFiles/MIFF.dir/all] Error 2
make: *** [all] Error 2

This surprises me because I don't think I should see "gfortran" - I
expected to see "mpif90". And that particular message seems to happen when
there are insufficient arguments to "gfortran". (the wrapper "mpif90" is
configured to use "gfortran", but all compilation should use the "mpif90" -
which doesn't appear to be the case when looking through the generated
makefiles.)

Here's what my project looks like:

Directory structure:
MIFF
 - src/
 - - CMakeLists.txt
 - - MIFFTest.f08
 - - MIFFTestMessage.f08
 - - MpiIocBaseMessage.f08
 - - MpiIocControlMessage.f08
 - - MpiIocFramework.f08
 - - MpiIocLinkedListItem.f08
 - CMakeLists.txt

My system is:
Ubuntu 14.04.4 LTS
The mpif90 compiler is:
GNU Fortran (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
CMake reports:
cmake version 2.8.12.2

Hopefully this is already fixed in newer versions of cmake - but this is
the version currently installed - but that's difficult for me to test, as
I'm working on a system that shouldn't deviate too far from our standard
development platform.

The CMakeLists.txt file in the MIFF directory is:
cmake_minimum_required (VERSION 2.8.6)
project( MIFF_Project )
add_subdirectory( src )

the CMakeLists.txt file in the MIFF/src directory is:
cmake_minimum_required( VERSION 2.8.8 )
project( MIFF_Project )
enable_language( Fortran )
set( CMAKE_FORTRAN_COMPILER mpif90 )
file( GLOB MIFF_Code *.f* )
message( STATUS "MIFF_Code: ${MIFF_Code}" )
add_library( MIFF SHARED ${MIFF_Code} )
set_target_properties( MIFF PROPERTIES LINKER_LANGUAGE Fortran ) #
OUTPUT_NAME MIFF )

I think I've exhausted Google looking for a solution, and I have a standard
Makefile that seems to work fine:

.PHONY : all clean run

COMPILER = mpif90
FFLAGS   = -shared -fPIC -g -I/usr/include
LIBRARY  = MIFF.so
EXECUTABLE   = MIFFTest
EXESOURCES   = src/MIFFTest.f08 \
   src/MIFFTestMessage.f08
LIBSOURCES   = src/MpiIocBaseMessage.f08 \
   src/MpiIocControlMessage.f08 \
   src/MpiIocLinkedListItem.f08 \
   src/MpiIocFramework.f08

src/MIFFTest.o : src/MIFFTest.f08 src/MIFFTestMessage.f08

all : $(LIBRARY) $(EXECUTABLE)

clean :
- rm -f *.o *.so *.mod $(EXECUTABLE)

run :
export LD_LIBRARY_PATH=~/workspace/MIFF
mpiexec -n 2 $(EXECUTABLE)


$(LIBRARY) : $(LIBSOURCES)
$(COMPILER) $(FFLAGS) $(LIBSOURCES) -o $(LIBRARY)

$(EXECUTABLE) : $(EXESOURCES) $(LIBRARY)
export LD_LIBRARY_PATH=~/workspace/MIFF
$(COMPILER) -o $(EXECUTABLE) $(EXESOURCES) $(LIBRARY)


Except for the problem of having to issue the "make all" twice because of a
dependency problem I haven't worked out, this hand-crafted Makefile works.
It's bad enough that I'm pushing the boundaries of polymorphism in
MPI+OpenMP+Fortran.

I'd appreciate any assistance getting cmake to work for my project.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[cmake-developers] Contribution for Issue #0015146

[Sebastian Windisch]

Hi,

I like to contribute code for issue #0015146. I had issues to get the 
/MANIFESTUAC flag (Microsoft C/C++ Compiler) working in CMake. I saw that it is 
a known bug which is not resolved yet since 2014. So I tried my best to solve 
the issue.

What I did: I introduced a new flag in cmIDEFlagTable.h called 
RegularExpression, and made some changes in cmIDEOptions::CheckFlagTable and 
the cmVS*LinkFlagTable.h files. These changes now allow matching regular 
expressions to complex flags and extracting the relevant values out of it to 
finally map them to the according IDE XML variables.

Example:

{"UACUIAccess", "MANIFESTUAC:level=([a-zA-Z]+) uiAccess=([a-zA-Z]+)$", "", 
"\\2", cmVS7FlagTable::RegularExpression},

If the flag matches with the second argument, the subexpressions get extracted 
from which the second one will be mapped to variable UACUIAccess.

Since this is my first contribution I attached it as a patch (master @ 
9cdb37e9175b2e3c6367bc4863fda0404cb1c3a2).

Regards,
Sebastian





patch.diff
Description: Binary data
-- 

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] Patch to only consider build dependencies between files in the source directory

[Brad King]

On 03/17/2016 09:54 AM, Attila Krasznahorkay wrote:
> Attached is a new attempt. It seems to work correctly in my tests
> with the Makefile generator.

Thanks.

> +  // If it's an absolute path, check if it starts with the source
> +  // direcotory:
> +  return ( ( path.find( SourceDir ) != 0 ) &&
> +   ( path.find( BinaryDir ) != 0 ) );

Please look at using strncmp and a check that the following character
is a nul terminator or '/'.  Otherwise an external location with
a common prefix may be mistaken for part of the project.

Also please add documentation in a

  Help/variable/CMAKE_DEPENDS_IN_PROJECT_ONLY.rst

file and update Help/manual/cmake-variables.7.rst to reference 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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL

[Charles Huet]

Awesome, thanks!

I'll check monday and report, but this looks like it'll work the same as
the patch I sent last, which I've been using the past few days.
Looking forward to have this feature in CMake !

Le ven. 18 mars 2016 à 16:03, Brad King  a écrit :

> On 03/17/2016 11:23 AM, Charles Huet wrote:
> > I added a utility function 'ConvertToNinjaFolderRule' that
> > does the same thing as ConvertToNinjaPath, but makes relative
> > to the source dir, and adds the '/all' suffix.
>
> Great.  I've applied the patch with a few style changes and
> logic fixes.  I also added documentation and a test:
>
>  Ninja: Add `$subdir/all` targets
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ca575fe9
>
>  Ninja: Add test for `$subdir/all` targets
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=86c851e6
>
>  Help: Add notes for topic 'ninja-directory-targets'
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=133aed8f
>
> Please try out that version to make sure it still works for you.
>
> 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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[CMake] why no cumulative variable operations via the commandline?

[René J . V . Bertin]

Hi,

I've been wondering about something that is a real stumbling block in a 
build/distribution system like MacPorts where settings can be modified in any 
number of consecutive steps. For instance, depending on what dependencies a 
package ("port") requires and how those dependencies are installed, elements 
may 
be added to the module search path repeatedly.

In cmake language one does cumulative operations like that explicitly, but I'm 
not aware of any way to do that on the command line.

Is there a reason why one cannot do something like 

cmake -DCMAKE_FOO+=bar

or

CMAKE -ACMAKE_FOO=bar (-A for add instead of define)

(or -DCMAKE_FOO-=bar, for that matter...) ?

Thanks,
René

-- 

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-539-ga27d069

[Brad King]

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, next has been updated
   via  a27d069287eb0ed75c64ba0b7f9a8f393fecfa10 (commit)
   via  d84ba668d7dd77ac38b3795f92e4ef0f894c696e (commit)
  from  8628ae30966f971b86e10abb729224ee9ad2c307 (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=a27d069287eb0ed75c64ba0b7f9a8f393fecfa10
commit a27d069287eb0ed75c64ba0b7f9a8f393fecfa10
Merge: 8628ae3 d84ba66
Author: Brad King 
AuthorDate: Fri Mar 18 11:13:17 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Mar 18 11:13:17 2016 -0400

Merge topic 'cpack-osx-optional-CoreServices' into next

d84ba668 CPack: Avoid using OS X CoreServices if compiler fails on header 
(#16021)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d84ba668d7dd77ac38b3795f92e4ef0f894c696e
commit d84ba668d7dd77ac38b3795f92e4ef0f894c696e
Author: Brad King 
AuthorDate: Fri Mar 18 08:49:02 2016 -0400
Commit: Brad King 
CommitDate: Fri Mar 18 11:12:51 2016 -0400

CPack: Avoid using OS X CoreServices if compiler fails on header (#16021)

Some compilers on OS X report errors in the CoreServices framework headers.
Check for support of the header ahead of time and compile the relevant code
only when the header is available.

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 5b67a2d..4ef0e80 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -728,7 +728,20 @@ endif()
 add_library(CPackLib ${CPACK_SRCS})
 target_link_libraries(CPackLib CMakeLib)
 if(APPLE)
-  target_link_libraries(CPackLib "-framework CoreServices")
+  # Some compilers produce errors in the CoreServices framework headers.
+  # Ideally such errors should be fixed by either the compiler vendor
+  # or the framework source, but we try to workaround it and build anyway.
+  # If it does not work, build with reduced functionality and warn.
+  check_include_file("CoreServices/CoreServices.h" HAVE_CoreServices)
+  if(HAVE_CoreServices)
+set_property(SOURCE CPack/cmCPackDragNDropGenerator.cxx PROPERTY 
COMPILE_DEFINITIONS HAVE_CoreServices)
+target_link_libraries(CPackLib "-framework CoreServices")
+  else()
+message(WARNING "This compiler does not appear to support\n"
+  "  #include \n"
+  "Some CPack functionality may be limited.\n"
+  "See CMakeFiles/CMakeError.log for details of the failure.")
+  endif()
 endif()
 
 if(APPLE)
diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx 
b/Source/CPack/cmCPackDragNDropGenerator.cxx
index 521b395..d6de77d 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.cxx
+++ b/Source/CPack/cmCPackDragNDropGenerator.cxx
@@ -22,10 +22,12 @@
 
 #include 
 
+#ifdef HAVE_CoreServices
 // For the old LocaleStringToLangAndRegionCodes() function, to convert
 // to the old Script Manager RegionCode values needed for the 'LPic' data
 // structure used for generating multi-lingual SLAs.
 #include 
+#endif
 
 static const char* SLAHeader =
 "data 'LPic' (5000) {\n"
@@ -643,9 +645,11 @@ int cmCPackDragNDropGenerator::CreateDMG(const 
std::string& src_dir,
kCFStringEncodingMacRoman);
 LangCode lang = 0;
 RegionCode region = 0;
+#ifdef HAVE_CoreServices
 OSStatus err = LocaleStringToLangAndRegionCodes(iso_language_cstr,
 , );
 if (err != noErr)
+#endif
   {
   cmCPackLogger(cmCPackLog::LOG_ERROR,
 "No language/region code available for " << iso_language_cstr
@@ -653,10 +657,12 @@ int cmCPackDragNDropGenerator::CreateDMG(const 
std::string& src_dir,
   free(iso_language_cstr);
   return 0;
   }
+#ifdef HAVE_CoreServices
 free(iso_language_cstr);
 header_data.push_back(region);
 header_data.push_back(i);
 header_data.push_back(0);
+#endif
 }
   ofs << "data 'LPic' (5000) {\n";
   ofs << std::hex << std::uppercase << std::setfill('0');

---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[cmake-developers] [CMake 0016025]: Add support WINDOWS_EXPORT_ALL_SYMBOLS for executable exports lib

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16025 
== 
Reported By:Yury Zhuravlev
Assigned To:
== 
Project:CMake
Issue ID:   16025
Category:   CMake
Reproducibility:always
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2016-03-18 10:04 EDT
Last Modified:  2016-03-18 10:04 EDT
== 
Summary:Add support WINDOWS_EXPORT_ALL_SYMBOLS for
executable exports lib
Description: 
For access from DLL to mother programm we need create .lib by EXPORTS flag but
without /DEF we can't export symbols.

This code must work:
add_executable(prog1 blalba)
set_target_properties(prog1 PROPERTIES ENABLE_EXPORTS 1)
set_target_properties(prog1 PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS 1)

Now I use ugly perl script for gen .def file.

Thanks. 
PS for .dll's WINDOWS_EXPORT_ALL_SYMBOLS worked correct. 
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-18 10:04 Yury Zhuravlev New Issue
==

-- 

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] Patch to only consider build dependencies between files in the source directory

[Attila Krasznahorkay]

Hi Brad,

Attached is a new attempt. It seems to work correctly in my tests with the 
Makefile generator. (Which, to be fair, is the only generator that we use in 
production mode at the moment...)

Cheers,
Attila


0001-CMAKE_DEPENDS_IN_PROJECT_ONLY-feature-addition.patch
Description: Binary data


> On 15 Mar 2016, at 19:13, Brad King  wrote:
> 
> On 03/15/2016 10:48 AM, Attila Krasznahorkay wrote:
>> https://cmake.org/pipermail/cmake-developers/2015-December/027197.html
>> 
>> With the following patch, when setting the CMAKE_ONLY_IN_SOURCE_DEPENDENCIES
>> variable to 1/ON/TRUE, this file size goes down to just a few kilobytes.
>> Speeding up our build noticeably.
> 
> Thanks.  As Ben pointed out in the original thread the build tree should
> be included as well.  Perhaps a name like
> 
>  CMAKE_DEPENDS_IN_PROJECT_ONLY
> 
> could be used to indicate that it includes only dependencies in the project
> directories (source or build tree).
> 
>> As far as I can see, the "cmake -E cmake_depends" call is only used by
>> the Makefile generator at the moment. So I only taught that generator
>> about this new variable.
> 
> The Makefile generator is the only one for which CMake takes responsibility
> for implicit dependency scanning.
> 
>> I just didn't see what I should do in the Ninja generator for instance
>> to apply this setting. Even though I would be very interested in implementing
>> the feature in that generator as well.
> 
> The Ninja generator uses the compiler's information about dependencies
> as generated by options like `gcc -MD`.  Since that occurs along with
> the compilation there is little cost to including all dependencies
> except for stat during rebuilds.  See discussion here:
> 
>  https://cmake.org/Bug/view.php?id=14914
> 
> about the opposite use case (including system dependencies instead of
> excluding them).
> 
>> +  infoFileStream
>> +<< "set(CMAKE_ONLY_IN_SOURCE_DEPENDENCIES "
>> +<< ( this->Makefile->IsOn( "CMAKE_ONLY_IN_SOURCE_DEPENDENCIES" ) ?
>> + "1" : "0" )
>> +<< ")\n";
> 
> Rather than communicating this to the dependency scanning step and
> doing the filtering there, please look at applying the filter during
> generation of CMAKE__TARGET_INCLUDE_PATH.
> 
> 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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, next, updated. v3.5.0-527-g7d01f32

[Zack Galbreath]

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, next has been updated
   via  7d01f3219105fe43ce0059709e4a266847a270bd (commit)
   via  6622b2c63e4b034b064b99893f0721440110a2af (commit)
  from  cfcba931392b24886b41037042353b43f9d46615 (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=7d01f3219105fe43ce0059709e4a266847a270bd
commit 7d01f3219105fe43ce0059709e4a266847a270bd
Merge: cfcba93 6622b2c
Author: Zack Galbreath 
AuthorDate: Fri Mar 18 09:56:24 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Mar 18 09:56:24 2016 -0400

Merge topic 'timeout_after_match' into next

6622b2c6 Increase default timeout for test


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6622b2c63e4b034b064b99893f0721440110a2af
commit 6622b2c63e4b034b064b99893f0721440110a2af
Author: Zack Galbreath 
AuthorDate: Fri Mar 18 09:55:46 2016 -0400
Commit: Zack Galbreath 
CommitDate: Fri Mar 18 09:55:46 2016 -0400

Increase default timeout for test

This change should help this test pass more reliably on
systems that take > 1 second to configure a NONE project.

diff --git a/Tests/RunCMake/CTestTimeoutAfterMatch/CMakeLists.txt.in 
b/Tests/RunCMake/CTestTimeoutAfterMatch/CMakeLists.txt.in
index 24d1673..e9592f6 100644
--- a/Tests/RunCMake/CTestTimeoutAfterMatch/CMakeLists.txt.in
+++ b/Tests/RunCMake/CTestTimeoutAfterMatch/CMakeLists.txt.in
@@ -2,5 +2,5 @@ cmake_minimum_required(VERSION 3.4)
 project(TimeoutAfterMatch NONE)
 include(CTest)
 add_test(NAME SleepFor1Second COMMAND "${CMAKE_COMMAND}" -P 
${CMAKE_SOURCE_DIR}/SleepFor1Second.cmake)
-set_property(TEST SleepFor1Second PROPERTY TIMEOUT 4)
+set_property(TEST SleepFor1Second PROPERTY TIMEOUT 30)
 set_property(TEST SleepFor1Second PROPERTY TIMEOUT_AFTER_MATCH "${arg1}" 
"${arg2}")

---

Summary of changes:
 Tests/RunCMake/CTestTimeoutAfterMatch/CMakeLists.txt.in |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL

[Brad King]

On 03/16/2016 04:59 AM, Charles Huet wrote:
> Sure, done.
> 
> If you have other ideas on how to improve this patch, I'll be happy to
> implement them.

Great.  Did you mean to attach a revised patch?

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, master, updated. v3.5.0-244-gbf07128

[Brad King]

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  bf0712866f3245034f5ee7d5835f5e4ed5f47626 (commit)
   via  44bbd2a65c0d2a405b70b96c3d643ce4b5eb82f4 (commit)
  from  b06c21784ab38aa9c82998483999f2dd24a106da (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 -
---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[cmake-developers] Fwd: [CMake 0016022]: GenerateExportHeader DEFINE_NO_DEPRECATED define conflicts

[Andreas Schuh]

Hi,

regarding this issue report, I’ve just attached a patch 
 for the current 
HEAD of the master branch that fixes the issue. Please have a look and it would 
be great if somebody could apply it. It currently causes problems in particular 
for projects using VTK, which may need this patch to be applied as well, given 
that it ships its own copy of the GenerateExportHeader module.

Cheers,
Andreas

> Begin forwarded message:
> 
> From: Mantis Bug Tracker 
> Subject: [cmake-developers] [CMake 0016022]: GenerateExportHeader 
> DEFINE_NO_DEPRECATED define conflicts
> Date: 16 March 2016 at 21:28:00 GMT
> To: cmake-developers@cmake.org
> 
> 
> The following issue has been SUBMITTED. 
> == 
> https://cmake.org/Bug/view.php?id=16022 
> == 
> Reported By:Andreas Schuh
> Assigned To:
> == 
> Project:CMake
> Issue ID:   16022
> Category:   Modules
> Reproducibility:always
> Severity:   minor
> Priority:   normal
> Status: new
> == 
> Date Submitted: 2016-03-16 17:27 EDT
> Last Modified:  2016-03-16 17:28 EDT
> == 
> Summary:GenerateExportHeader DEFINE_NO_DEPRECATED define
> conflicts
> Description: 
> The header file generated by generate_export_header adds a
> 
>#define DEFINE_NO_DEPRECATED 0|1
> 
> macro which is used to decide whether or not to define the respective macro 
> with
> the desired library prefix and base name. But this macro has the same name for
> all libraries and is not undefined when it is no longer needed. In my project,
> this for example created a conflict with the VTK library which uses such
> generated header file which must of course be included in the public header
> files.
> 
> To solve this conflict, I am using now (temporarily) a custom
> exportheader.cmake.in template file by changing the
> _GENERATE_EXPORT_HEADER_MODULE_DIR path to a directory in my project after
> including the GenerateExportHeader module. Find the modified template file
> attached.
> 
> There is certainly a better fix for this bug.
> == 
> 
> Issue History 
> Date ModifiedUsername   FieldChange   
> == 
> 2016-03-16 17:27 Andreas Schuh  New Issue
> 2016-03-16 17:28 Andreas Schuh  File Added: exportheader.cmake.in 
>   
> 
> ==
> 
> -- 
> 
> 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

-- 

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] fixup_bundle on Windows : issue with multiple exe applications

[David Cole via CMake]

A multiple folder approach will be very difficult.

The basic assumptions are:

- On Windows, the "one executable path" is the destination path to
which to copy all of the DLLs that need to be copied, so they all end
up in the same directory. (You'd have to have multiple copies in
multiple locations, at which point, it probably makes sense to have
each of your exes set up to use a common shared DLL folder instead.)

- On Mac, the "one executable path" is used to fixup libraries to use
"@executable_path" relative references, so it's different for each
different exe path. If two executables depend on the same library, but
are in different places, but the library is only in one place, then
you cannot use an "@executable_path" relative reference to find the
library.

If all your executables are not in the same directory with each other,
then BundleUtilities will probably not make you a happy camper.


HTH,
David C.



On Fri, Mar 4, 2016 at 9:30 AM, Benjamin Ballet  wrote:
> FYI verifying_app failed with main.exe failed (3.4.3) because toptool
> depends on topdool.dll located only in toptoolfolder. The workaround is to
> include toptoolfolder in libs folder for fixup_bundle(main.exe...)
>
> David your answer was helpful to me. I know it's an expected behavior.
>
> Would a patch handling such multiple folder application been accepted ? I
> may try to work on it, since I either have to work on the workarounds or a
> nice improvment.
>
>
> 2016-03-04 14:15 GMT+01:00 Benjamin Ballet :
>>
>> Indeed I was lucky : It worked with 3.3.1 but not anymore with 3.4.3..
>> I've got a strang bug with one .NET dll generated near a tool :
>>
>> CMake Error at C:/Program Files
>> (x86)/CMake/share/cmake-3.4/Modules/GetPrerequisites.cmake:798 (message):
>> 106>C:/Program Files (x86)/Microsoft Visual Studio
>> 12.0/VC/bin/dumpbin.exe
>> 106>failed: 1181
>>
>> I'm digging
>>
>>
>>
>> 2016-03-03 21:02 GMT+01:00 David Cole :
>>>
>>> It was designed originally with the assumption that all the
>>> executables in a bundle are in the same directory. If you violate that
>>> assumption, I don't think you can count on it to do the right thing
>>> 100% of the time.
>>>
>>> If it works for you calling it multiple times with deepest first, then
>>> maybe you can get lucky...
>>>
>>> I would definitely dig into it and understand exactly what it's doing,
>>> though, if you want to make sure it's going to continue working for
>>> your scenario.
>>>
>>>
>>> HTH,
>>> David C.
>>>
>>>
>>> On Thu, Mar 3, 2016 at 1:43 PM, Benjamin Ballet 
>>> wrote:
>>> > Hello
>>> >
>>> > I'd like to discuss a problem I encountered today with the very useful
>>> > module BundleUtilities
>>> >
>>> > We have an application on Windows with one main exe file in the top
>>> > folder
>>> > and a few other exe in subdirectories, like that :
>>> >
>>> > applicationfolder  \
>>> >   | main.exe
>>> >   | toolsfolder \
>>> > | supertoolfolder \
>>> > |
>>> > supertool.exe
>>> > | toptoolfolder \
>>> >  |
>>> > toptool.exe
>>> >
>>> > But if I simply call
>>> > fixup_bundle("applicationfolder/main.exe" plugins libs)
>>> >
>>> > the verify_app will fails.
>>> >
>>> > Just a reminder that there is no rpath on Windows : dll must be either
>>> > in
>>> > PATH or in the same folder or in the working directory.
>>> >
>>> > We expected fixup_bundle to copy the required dll for main.exe in
>>> > applicationfolder, the required dll for supertool.exe in
>>> > supertoolfolder and
>>> > the required dll for toptool.exe in toptoolfolder, but it acually
>>> > didn't
>>> > copied anything in supertoolfolder and toptoolfolder.
>>> >
>>> > I worked around this issue by calling fixup_bundle multiple time with
>>> > the
>>> > following order : (the deepest exes first)
>>> >
>>> >
>>> > fixup_bundle("applicationfolder/toolsfolder/supertoolfolder/supertool.exe"
>>> > plugins libs)
>>> > fixup_bundle("applicationfolder/toolsfolder/toptoolfolder/toptool.exe"
>>> > plugins libs)
>>> > fixup_bundle("applicationfolder/main.exe" plugins libs)
>>> >
>>> >
>>> > --
>>> > Benjamin BALLET
>>> > Ingénieur R
>>> >
>>> > ACTIVISU
>>> > 19, rue Klock - 92110 Clichy
>>> >> Standard Tél :  01 44 69 37 37
>>> >> www.activisu.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-commits] CMake branch, next, updated. v3.5.0-481-g9e7ee35

[Brad King]

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, next has been updated
   via  9e7ee356efb36298a07889e8c918278342cba5e5 (commit)
   via  bf0712866f3245034f5ee7d5835f5e4ed5f47626 (commit)
   via  44bbd2a65c0d2a405b70b96c3d643ce4b5eb82f4 (commit)
  from  310e701169c2e7704061935822a05c5d4c01b782 (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=9e7ee356efb36298a07889e8c918278342cba5e5
commit 9e7ee356efb36298a07889e8c918278342cba5e5
Merge: 310e701 bf07128
Author: Brad King 
AuthorDate: Wed Mar 16 13:15:10 2016 -0400
Commit: Brad King 
CommitDate: Wed Mar 16 13:15:10 2016 -0400

Merge branch 'master' into next


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Clarifying Cmake behavior

[James Benze]

I did a bit more searching around, and, for me at least, setting
Boost_REALPATH on also seems to be a valid solution to the problem, as the
linker will no longer get confused between the system installed libraries
and my custom ones.  I dunno if that works in all situations, but it seems
to be the cleanest solution to what I'm doing.

On Tue, Mar 15, 2016 at 5:16 PM, Elizabeth Fischer 
wrote:

> Something is wrong here.  In 99% of the cases I've seen, it is not
> necessary to set LD_LIBRARY_PATH.  That env var is evil, and should be used
> only as a last resort, and temporarily at that.  There must be a better
> way...
>
>
> On Tue, Mar 15, 2016 at 2:38 PM, James Benze  wrote:
>
>> So I combed through the source code, and solved the problem, mostly.  It
>> did turn out to be a cmake issue, sort of, so I figured I'd post here for
>> posterity in case future problem solvers come across a similar issue.
>>
>> So I'm using both a custom compiler and a custom set of boost libraries.
>> For simplicity, I installed them to the same prefix
>> (/path/to/custom/stuff).  Now cmake has a list of libraries that it thinks
>> are always looked in for link directories.  If you use a custom compiler
>> (/path/to/custom/stuff/bin/g++ for example), it adds that compiler's
>> libraries to it's "implicit link directories", ones that it assumes are
>> found automatically (in this case /path/to/custom/stuff/lib and
>> /path/to/custom/stuff/lib64).  Because my custom boost version was in this
>> library path (/path/to/custom/stuff/lib) cmake assumed that the compiler
>> could find them and just used the "-l" syntax with no RPATH set.  When I
>> used my control set of libraries, they were installed in a different prefix
>> (/path/to/test/boost/) so cmake says "oh you can't find these" and did the
>> full path linkage plus RPATH.
>>
>> So my two solutions are as follows:
>>
>> 1) set LD_LIBRARY_PATH when building. In this case, everything links
>> correctly, although ld harmlessly complains about conflicts with the
>> distribution-installed libraries in /usr/lib/
>> 2) Install boost in a different directory than my custom compiler.
>>
>> Cheers, all.
>>
>> On Tue, Mar 15, 2016 at 10:38 AM, James Benze  wrote:
>>
>>> Hey all:
>>>
>>> I'm trying to compile boost with some weird options, and I can't get
>>> projects linked with it to compile correctly.  As using regularly compiled
>>> boost seems to work just fine, this indicates my issue is not with
>>> cmake...however I was hoping I could get some clarification on how cmake
>>> searches for things in order to diagnose my issue.
>>>
>>> I made a toy project here:
>>>
>>> cmake_minimum_required(VERSION 2.8.4)
>>> project(testproject)
>>>
>>> find_package(Boost 1.58.0 REQUIRED COMPONENTS thread)
>>> add_executable(a.out main.cpp)
>>> target_link_libraries(a.out ${Boost_LIBRARIES})
>>>
>>> When I build this project with the "good" normally compiled boost
>>> libraries, I get this CMakeFiles/a.out.dir/link.txt:
>>>
>>> /full/path/to/compiler/g++ CMakeFiles/a.out.dir/main.cpp.o -o a.out
>>> -rdynamic /full/path/to/good/boost/libboost_thread.so
>>> -Wl,-rpath,/full/path/to/good/boost
>>>
>>> When I build the project with the exact same options, except
>>> substituting the "bad" boost for the BOOST_ROOT variable, I get:
>>>
>>> /full/path/to/compiler/g++ CMakeFiles/a.out.dir/main.cpp.o -o a.out
>>> -rdynamic -lboost_thread
>>>
>>> The obvious differences here are that with the good boost libraries, we
>>> get a full path to the boost library and not a shortened path.
>>> Additionally, with the good library, I get a the rpath to the library set
>>> as well.  The ${Boost_LIBRARIES} variable is the full path to
>>> libboost_thread.so in both cases.
>>>
>>> This is obviously a problem with my boost compilation, but this is my
>>> only clue to diagnosing the problem.  I was hoping for some insight as to
>>> why cmake would choose one way of linking over another so I could attempt
>>> to fix my actual problem.
>>>
>>> Thanks!
>>>
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/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