[Cmake-commits] CMake branch, master, updated. v3.6.0-rc3-235-gf05657d

[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  f05657de9d1ae7247a527186830d37702ec30de4 (commit)
  from  c2c2a2f4c7e23192d3d8cd8d53a427d651ef3137 (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=f05657de9d1ae7247a527186830d37702ec30de4
commit f05657de9d1ae7247a527186830d37702ec30de4
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Jun 24 00:01:08 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Jun 24 00:01:08 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 6e32ab0..40f8e11 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 6)
-set(CMake_VERSION_PATCH 20160623)
+set(CMake_VERSION_PATCH 20160624)
 #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] daemon-mode meeting last Tuesday

[Tobias Hunger]

Hi Rolf,

Am 23.06.2016 23:00 schrieb "Rolf Eike Beer" :
> What about just passing --server-fd= into it? That way the client
can set
> up whatever if wants to pass there and CMake has nothing to do with any
setup.
> And if one really wants to get messy one could pass a tty there.

Not sure whether that is even possible on all platforms we need.

Libuv (which the server is using) apparently has a cross-platform solution
for setting up a communication channel like the one we need, so I want to
give that a try.

Best Regards,
Tobias
-- 

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] daemon-mode meeting last Tuesday

[Tobias Hunger]

Hi Ben,

Am 23.06.2016 22:48 schrieb "Ben Boeckel" :
> cmake-oracle sounds reasonable for what it's doing to me.

I hope this thing will provide information more reliable than e.g. the
Oracle of Delphi in ancient Greece:-)

Best Regards,
Tobias
-- 

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] daemon-mode meeting last Tuesday

[Tobias Hunger]

Am 23.06.2016 22:46 schrieb "Brad King" :
>
> On 06/23/2016 08:27 AM, Tobias Hunger wrote:
> Great!  Thanks for the detailed summary of the meeting and status of the
design.

You are welcome.



> >   * Some names could be improved. Suggestions welcome.
>
> We'll cover these in more detail during review.  The most important name
is
> the name of the feature, and IMO "daemon" is not an accurate description
of
> it (it is never re-parented to 'init' and has a lifetime tied to the
client).
> I think "server" would be better but am open to other suggestions.  Even
if
> it later really becomes a daemon the name "server" will still be
appropriate.

I'll create a task to rename it to "server" then.



> >   * Currently a reply (and error and all other messages in response to a
> > request) contain a "inReplyTo" with the type string from the request
> > triggering the reply.
> >
> > Stephen thinks that is not necessary and argues anything that is not
> > strictly necessary should not be in the first version of the
protocol.
> >
> > I like having this as it makes it helps to identify what a
reply/error is
> > related to. I often paste a whole string of requests into the
daemon and
> > if there is an error it is really easy to see how for things got.
>
> Would each type of query have a known type of response?  Shouldn't the
response
> objects have a type too?

It has a type: "reply" (or "error"). I so far use the inReplyTo field to
specify what the request a reply refers to. Stephen thinks that is not
necessary as there is always one request in flight and the client can just
figure things out without additional information.

> Also, doesn't the cookie allow the query/response
> pairs to be matched?

In theory yes. But a protocol should work without having to reply on
cookies.

A cookie is user data attached to an request. The idea is that e.g. an IDE
can run a request for some more details on some node in the project tree
view and pass some form of ID of the node the information is for along with
the query. That can simplify client code a lot.

> >   * Should we have a split between header (cookie/type/inReplyTo) and
data?
> >
> > Stephen suggested passing all data that is from/for the client in a
> > "body" attribute to make messages more uniform.
> >
> > I think that is just adding one more level into the JSON file for no
> > real benefit.
>
> I agree with Tobias that there is no reason to put the body fields in
> a sub-object.  However, I think the header fields should go in a
sub-object
> named by a "header" field.  That will isolate the header field names from
> the body fields (good for sorted views, future addition of headers, etc.).

The header currently is the type, inReplyTo and the cookie. I did not see
the need to separate those.

> >   * This is currently used to set sourcedirectory, builddirectory and
> > generator.
> >
> > These three should be passed in via the command line instead, again
> > to avoid trouble with users switching to different build
directories/etc.
> > while the daemon is running, which might trigger problems with state
> > cleanup, etc.
>
> Currently cmake-gui supports switching generators, build trees, etc., so
> there is some precedent for such switching within a single process.  If
> we have (re-)initialization bugs they should simply be fixed.

So you think we should keep that? I do not have an opinion here and need to
follow the advise of people more knowledgeable about CMake code than I am.

> >   * Figure out whether a PDB file is actually going to be build.
Currently
> > the PDB file is added to the list of artifacts whenever there is a
.lib
> > file, which is probably wrong. Brad: Do you have an idea how to
> > get this information?
>
> I'm not sure we have that information.  IIRC CMake only adds settings to
the
> generated build system to tell the tools where to put the .pdb and what to
> call it if it happens to be created.  We don't have install rules for them
> so there has never been a need to know whether they will actually be
created.
> Perhaps our format for the list of artifacts needs a way to indicate
whether
> an artifact is optionally present.

I think CMake should know what is generated and should not leave decisions
like that up to generators.

> >   2.8 buildsystem (return cmake files)
> >
> >   * Return a list of cmake files (CMakeLists.txt, etc.) in different
categories
> > (in source directory/in build directory/in the system).
> >
> >   * Stephen suggested to rename this to "cmake_rerun_depends". I am not
sure
> > that name is much better than what is currently used.
>
> "cmake_rerun_depends" describes the current use case for these.  I don't
think
> the name "buildsystem" is clear though.  Other ideas:
>
> * cmake_files
> * cmake_inputs
> * input_files

I like "cmakeInputs":-) I'll make a task to change it if nobody opposes
this suggestion.

Best 

Re: [cmake-developers] daemon-mode: Infrastructure

[Ben Boeckel]

On Tue, Jun 14, 2016 at 02:00:14 +0200, Tobias Hunger wrote:
> Implementing new Protocol Versions:
> ==



> Deprecating old Protocol Versions:
> 



One idea that came up on a previous project was the following:

namespace protocol {
namespace aspect1 {
namespace v1 {
}

namespace v2 {
}
}

namespace aspect2 {
namespace v1 {
}
}

namespace v1 {
namespace aspect1 = aspect1::v1;
namespace aspect2 = aspect1::v1;

Version version(1, 0);
bool deprecated = true;
}

namespace v2 {
namespace aspect1 = aspect1::v2;
namespace aspect2 = aspect1::v1;

Version version(2, 0);
bool deprecated = false;
}

namespace latest = v2;
}

Then the code can use `protocol::v1::aspect1::` for explicit v1
communication and `protocol::latest::` in any normal code. It does
require C++11 though. There's probably some template metaprogramming
magic that could be done to instantiate communication ends for each
protocol namespace once communication is done.

I have no idea how maintainable in the long-term this is though.

--Ben
-- 

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] daemon-mode meeting last Tuesday

[Rolf Eike Beer]

>   1.1 Communication:
>   
>   * Clients should talk to daemon mode via a socket (libuv supports that), 
> but we also want to support stdin/stdout at least for a "debug mode" *
> There should be a separate command line switch to start stdin/out mode and
> for socket mode
>  * This is needed before it makes sense to merge the patch set.

What about just passing --server-fd= into it? That way the client can set 
up whatever if wants to pass there and CMake has nothing to do with any setup. 
And if one really wants to get messy one could pass a tty there.

Eike

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] daemon-mode meeting last Tuesday

[Ben Boeckel]

On Thu, Jun 23, 2016 at 16:46:48 -0400, Brad King wrote:
> On 06/23/2016 08:27 AM, Tobias Hunger wrote:
> >   * Figure out whether a PDB file is actually going to be build. Currently
> > the PDB file is added to the list of artifacts whenever there is a .lib
> > file, which is probably wrong. Brad: Do you have an idea how to
> > get this information?
> 
> I'm not sure we have that information.  IIRC CMake only adds settings to the
> generated build system to tell the tools where to put the .pdb and what to
> call it if it happens to be created.  We don't have install rules for them
> so there has never been a need to know whether they will actually be created.
> Perhaps our format for the list of artifacts needs a way to indicate whether
> an artifact is optionally present.

Well, there is this issue:

https://gitlab.kitware.com/cmake/cmake/issues/10636

which requests that they always be generated :) .

> >   2.8 buildsystem (return cmake files)
> >   
> >   * Return a list of cmake files (CMakeLists.txt, etc.) in different 
> > categories
> > (in source directory/in build directory/in the system).
> > 
> >   * Stephen suggested to rename this to "cmake_rerun_depends". I am not sure
> > that name is much better than what is currently used.
> 
> "cmake_rerun_depends" describes the current use case for these.  I don't think
> the name "buildsystem" is clear though.  Other ideas:
> 
> * cmake_files
> * cmake_inputs
> * input_files

Also possible: regen_trigger_files

--Ben
-- 

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] daemon-mode meeting last Tuesday

[Ben Boeckel]

On Thu, Jun 23, 2016 at 16:46:48 -0400, Brad King wrote:
> On 06/23/2016 08:27 AM, Tobias Hunger wrote:
> >   * Some names could be improved. Suggestions welcome.
> 
> We'll cover these in more detail during review.  The most important name is
> the name of the feature, and IMO "daemon" is not an accurate description of
> it (it is never re-parented to 'init' and has a lifetime tied to the client).
> I think "server" would be better but am open to other suggestions.  Even if
> it later really becomes a daemon the name "server" will still be appropriate.
> 
> As you said before there has been a lot of PR with the name "daemon", but I
> don't think it is too late to change it.  Those interested in the features
> will see the new name when it appears in release notes and should easily be
> able to recognize it.

cmake-oracle sounds reasonable for what it's doing to me.

--Ben
-- 

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] daemon-mode meeting last Tuesday

[Brad King]

On 06/23/2016 08:27 AM, Tobias Hunger wrote:
> Stephen Kelly and me met last Tuesday to talk about the daemon-mode patch we
> both have been working on. It was a very productive meeting: We managed to
> resolve almost all the differences of opinion we had.

Great!  Thanks for the detailed summary of the meeting and status of the design.

>   * Some names could be improved. Suggestions welcome.

We'll cover these in more detail during review.  The most important name is
the name of the feature, and IMO "daemon" is not an accurate description of
it (it is never re-parented to 'init' and has a lifetime tied to the client).
I think "server" would be better but am open to other suggestions.  Even if
it later really becomes a daemon the name "server" will still be appropriate.

As you said before there has been a lot of PR with the name "daemon", but I
don't think it is too late to change it.  Those interested in the features
will see the new name when it appears in release notes and should easily be
able to recognize it.

>   * Clients should talk to daemon mode via a socket (libuv supports that),
> but we also want to support stdin/stdout at least for a "debug mode"
>  * There should be a separate command line switch to start stdin/out mode
>and for socket mode
>  * This is needed before it makes sense to merge the patch set.

Given the noise we have on stdout it makes sense to offer a dedicated
communication path for clients.

>   * Currently a reply (and error and all other messages in response to a
> request) contain a "inReplyTo" with the type string from the request
> triggering the reply.
> 
> Stephen thinks that is not necessary and argues anything that is not
> strictly necessary should not be in the first version of the protocol.
> 
> I like having this as it makes it helps to identify what a reply/error is
> related to. I often paste a whole string of requests into the daemon and
> if there is an error it is really easy to see how for things got.

Would each type of query have a known type of response?  Shouldn't the response
objects have a type too?  Also, doesn't the cookie allow the query/response
pairs to be matched?

>   * Should we have a split between header (cookie/type/inReplyTo) and data?
>   
> Stephen suggested passing all data that is from/for the client in a
> "body" attribute to make messages more uniform.
> 
> I think that is just adding one more level into the JSON file for no
> real benefit.

I agree with Tobias that there is no reason to put the body fields in
a sub-object.  However, I think the header fields should go in a sub-object
named by a "header" field.  That will isolate the header field names from
the body fields (good for sorted views, future addition of headers, etc.).

>   * This is currently used to set sourcedirectory, builddirectory and
> generator.
> 
> These three should be passed in via the command line instead, again
> to avoid trouble with users switching to different build directories/etc.
> while the daemon is running, which might trigger problems with state
> cleanup, etc.

Currently cmake-gui supports switching generators, build trees, etc., so
there is some precedent for such switching within a single process.  If
we have (re-)initialization bugs they should simply be fixed.

>   * Figure out whether a PDB file is actually going to be build. Currently
> the PDB file is added to the list of artifacts whenever there is a .lib
> file, which is probably wrong. Brad: Do you have an idea how to
> get this information?

I'm not sure we have that information.  IIRC CMake only adds settings to the
generated build system to tell the tools where to put the .pdb and what to
call it if it happens to be created.  We don't have install rules for them
so there has never been a need to know whether they will actually be created.
Perhaps our format for the list of artifacts needs a way to indicate whether
an artifact is optionally present.

>   2.8 buildsystem (return cmake files)
>   
>   * Return a list of cmake files (CMakeLists.txt, etc.) in different 
> categories
> (in source directory/in build directory/in the system).
> 
>   * Stephen suggested to rename this to "cmake_rerun_depends". I am not sure
> that name is much better than what is currently used.

"cmake_rerun_depends" describes the current use case for these.  I don't think
the name "buildsystem" is clear though.  Other ideas:

* cmake_files
* cmake_inputs
* input_files

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-523-g272f159

[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  272f159ea60d27ff817bd32335a8edcf2a994fcd (commit)
   via  8bbd5db4c160927cf5e9a2eb2f45fe36a2c2d799 (commit)
  from  f8955baf557a8653e1a2b8e0667b6689931c287b (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=272f159ea60d27ff817bd32335a8edcf2a994fcd
commit 272f159ea60d27ff817bd32335a8edcf2a994fcd
Merge: f8955ba 8bbd5db
Author: Brad King 
AuthorDate: Thu Jun 23 15:52:05 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Jun 23 15:52:05 2016 -0400

Merge topic 'ninja-osx-content-on-target' into next

8bbd5db4 Ninja: Make bundle resources a dependency of their target


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8bbd5db4c160927cf5e9a2eb2f45fe36a2c2d799
commit 8bbd5db4c160927cf5e9a2eb2f45fe36a2c2d799
Author: Florent Castelli 
AuthorDate: Thu Jun 23 17:01:29 2016 +0200
Commit: Brad King 
CommitDate: Thu Jun 23 15:50:03 2016 -0400

Ninja: Make bundle resources a dependency of their target

Fixes #13816.

diff --git a/Source/cmNinjaTargetGenerator.cxx 
b/Source/cmNinjaTargetGenerator.cxx
index b413c33..954c73e 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -487,6 +487,10 @@ void cmNinjaTargetGenerator::WriteObjectBuildStatements()
   this->GetLocalGenerator()->AppendTargetDepends(this->GeneratorTarget,
  orderOnlyDeps);
 
+  // Add order-only dependencies on other files associated with the target.
+  orderOnlyDeps.insert(orderOnlyDeps.end(), this->ExtraFiles.begin(),
+   this->ExtraFiles.end());
+
   // Add order-only dependencies on custom command outputs.
   for (std::vector::const_iterator cci =
  this->CustomCommands.begin();
@@ -717,8 +721,8 @@ void 
cmNinjaTargetGenerator::MacOSXContentGeneratorType::operator()(
   this->Generator->GetGlobalGenerator()->WriteMacOSXContentBuild(input,
  output);
 
-  // Add as a dependency of all target so that it gets called.
-  this->Generator->GetGlobalGenerator()->AddDependencyToAll(output);
+  // Add as a dependency to the target so that it gets called.
+  this->Generator->ExtraFiles.push_back(output);
 }
 
 void cmNinjaTargetGenerator::addPoolNinjaVariable(
diff --git a/Source/cmNinjaTargetGenerator.h b/Source/cmNinjaTargetGenerator.h
index 414aa09..44346c1 100644
--- a/Source/cmNinjaTargetGenerator.h
+++ b/Source/cmNinjaTargetGenerator.h
@@ -156,6 +156,7 @@ private:
   /// List of object files for this target.
   cmNinjaDeps Objects;
   std::vector CustomCommands;
+  cmNinjaDeps ExtraFiles;
 };
 
 #endif // ! cmNinjaTargetGenerator_h

---

Summary of changes:
 Source/cmNinjaTargetGenerator.cxx |8 ++--
 Source/cmNinjaTargetGenerator.h   |1 +
 2 files changed, 7 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.6.0-rc3-521-gf8955ba

[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  f8955baf557a8653e1a2b8e0667b6689931c287b (commit)
   via  9f2728cef3763dff93a43b933a10f32eb73f7c6b (commit)
   via  149539d9c2d90da76facbd70c969b82af8e2448a (commit)
   via  f30b0fec749710e7eec68ddd148215609a5c01f9 (commit)
  from  c480bac574a2fb8bc93ab35e052720d003cfd808 (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=f8955baf557a8653e1a2b8e0667b6689931c287b
commit f8955baf557a8653e1a2b8e0667b6689931c287b
Merge: c480bac 9f2728c
Author: Brad King 
AuthorDate: Thu Jun 23 14:10:39 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Jun 23 14:10:39 2016 -0400

Merge topic 'handle_unsiffixed_hdf5' into next

9f2728ce FindHDF5: When component targets not found fallback to compiler 
wrappers
149539d9 FindHDF5: Handle HDF5 builds with non-suffixed components
f30b0fec FindHDF5: correctly add lang to each component target name.


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f2728cef3763dff93a43b933a10f32eb73f7c6b
commit 9f2728cef3763dff93a43b933a10f32eb73f7c6b
Author: Robert Maynard 
AuthorDate: Thu Jun 23 12:31:26 2016 -0400
Commit: Robert Maynard 
CommitDate: Thu Jun 23 12:31:26 2016 -0400

FindHDF5: When component targets not found fallback to compiler wrappers

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index 53c0085..7c1581d 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -366,6 +366,12 @@ if(NOT HDF5_FOUND AND NOT HDF5_ROOT)
 #Older versions of hdf5 don't have a static/shared suffix so
 #if we detect that occurrence clear the suffix
 if(_suffix AND NOT TARGET ${HDF5_${_lang}_TARGET}${_suffix})
+  if(NOT TARGET ${HDF5_${_lang}_TARGET})
+#cant find this component with our without the suffix
+#so bail out, and let the following locate HDF5
+set(HDF5_FOUND FALSE)
+break()
+  endif()
   set(_suffix "")
 endif()
 

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=149539d9c2d90da76facbd70c969b82af8e2448a
commit 149539d9c2d90da76facbd70c969b82af8e2448a
Author: Robert Maynard 
AuthorDate: Thu Jun 23 10:57:58 2016 -0400
Commit: Robert Maynard 
CommitDate: Thu Jun 23 10:57:58 2016 -0400

FindHDF5: Handle HDF5 builds with non-suffixed components

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index cc05f1c..53c0085 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -362,6 +362,13 @@ if(NOT HDF5_FOUND AND NOT HDF5_ROOT)
 set(_suffix "-shared")
 endif()
 foreach(_lang ${HDF5_LANGUAGE_BINDINGS})
+
+#Older versions of hdf5 don't have a static/shared suffix so
+#if we detect that occurrence clear the suffix
+if(_suffix AND NOT TARGET ${HDF5_${_lang}_TARGET}${_suffix})
+  set(_suffix "")
+endif()
+
 get_target_property(_lang_location 
${HDF5_${_lang}_TARGET}${_suffix} LOCATION)
 if( _lang_location )
 set(HDF5_${_lang}_LIBRARY ${_lang_location} CACHE PATH

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f30b0fec749710e7eec68ddd148215609a5c01f9
commit f30b0fec749710e7eec68ddd148215609a5c01f9
Author: Robert Maynard 
AuthorDate: Thu Jun 23 10:56:29 2016 -0400
Commit: Robert Maynard 
CommitDate: Thu Jun 23 10:56:29 2016 -0400

FindHDF5: correctly add lang to each component target name.

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index bc0d50b..cc05f1c 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -362,7 +362,7 @@ if(NOT HDF5_FOUND AND NOT HDF5_ROOT)
 set(_suffix "-shared")
 endif()
 foreach(_lang ${HDF5_LANGUAGE_BINDINGS})
-get_target_property(_lang_location 
${HDF5_${_component}_TARGET}${_suffix} LOCATION)
+get_target_property(_lang_location 
${HDF5_${_lang}_TARGET}${_suffix} LOCATION)
 if( _lang_location )
 set(HDF5_${_lang}_LIBRARY ${_lang_location} CACHE PATH
 "HDF5 ${_lang} library" )

---

Summary of changes:
 Modules/FindHDF5.cmake |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake

Re: [cmake-developers] [PATCH] Update documentation for VERSION and SOVERSION for Mach-O file formats (OSX, iOS, BSD etc.)

[Brad King]

On 06/23/2016 11:50 AM, Bartosz Kosiorek wrote:
> how to set "current version" and "compatibility version" on
> binaries produced by OS X.
> I have updated documentation to describe how to archieve that

Thanks.  I revised the changes a bit and applied the patch:

 Help: Describe VERSION and SOVERSION meanings for Mach-O binaries
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=00caa1dd

> Do you think it could be pushed into CMake 3.6 ?

Yes, since it is a documentation-only update.  I've queued it for
merge to 'release'.

-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.6.0-rc3-517-gc480bac

[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  c480bac574a2fb8bc93ab35e052720d003cfd808 (commit)
   via  00caa1dde8d7381ce98731af8b8083ca5b8b0be2 (commit)
  from  6c530851d68c439ff8829f7028e629a52049e7fa (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=c480bac574a2fb8bc93ab35e052720d003cfd808
commit c480bac574a2fb8bc93ab35e052720d003cfd808
Merge: 6c53085 00caa1d
Author: Brad King 
AuthorDate: Thu Jun 23 13:44:51 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Jun 23 13:44:51 2016 -0400

Merge topic 'doc-osx-versions' into next

00caa1dd Help: Describe VERSION and SOVERSION meanings for Mach-O binaries


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=00caa1dde8d7381ce98731af8b8083ca5b8b0be2
commit 00caa1dde8d7381ce98731af8b8083ca5b8b0be2
Author: Bartosz Kosiorek 
AuthorDate: Mon Jun 20 14:34:09 2016 +0200
Commit: Brad King 
CommitDate: Thu Jun 23 13:44:26 2016 -0400

Help: Describe VERSION and SOVERSION meanings for Mach-O binaries

diff --git a/Help/prop_tgt/FRAMEWORK.rst b/Help/prop_tgt/FRAMEWORK.rst
index 6c212c3..8120c36 100644
--- a/Help/prop_tgt/FRAMEWORK.rst
+++ b/Help/prop_tgt/FRAMEWORK.rst
@@ -26,6 +26,10 @@ Example of creation ``dynamicFramework``:
 FRAMEWORK_VERSION C
 MACOSX_FRAMEWORK_IDENTIFIER com.cmake.dynamicFramework
 MACOSX_FRAMEWORK_INFO_PLIST Info.plist
+# "current version" in semantic format in Mach-O binary file
+VERSION 16.4.0
+# "compatibility version" in semantic format in Mach-O binary file
+SOVERSION 1.0.0
 PUBLIC_HEADER dynamicFramework.h
 XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
   )
diff --git a/Help/prop_tgt/SOVERSION.rst b/Help/prop_tgt/SOVERSION.rst
index 672ff23..82b6b97 100644
--- a/Help/prop_tgt/SOVERSION.rst
+++ b/Help/prop_tgt/SOVERSION.rst
@@ -3,12 +3,25 @@ SOVERSION
 
 What version number is this target.
 
-For shared libraries VERSION and SOVERSION can be used to specify the
-build version and API version respectively.  When building or
+For shared libraries :prop_tgt:`VERSION` and ``SOVERSION`` can be used to
+specify the build version and API version respectively.  When building or
 installing appropriate symlinks are created if the platform supports
 symlinks and the linker supports so-names.  If only one of both is
 specified the missing is assumed to have the same version number.
-SOVERSION is ignored if NO_SONAME property is set.  For shared
-libraries and executables on Windows the VERSION attribute is parsed
-to extract a "major.minor" version number.  These numbers are used as
-the image version of the binary.
+``SOVERSION`` is ignored if :prop_tgt:`NO_SONAME` property is set.
+
+Windows Versions
+
+
+For shared libraries and executables on Windows the :prop_tgt:`VERSION`
+attribute is parsed to extract a ``.`` version number.
+These numbers are used as the image version of the binary.
+
+Mach-O Versions
+^^^
+
+For shared libraries and executables on Mach-O systems (e.g. OS X, iOS),
+the ``SOVERSION`` property corresponds to *compatibility version* and
+:prop_tgt:`VERSION` to *current version*.  See the :prop_tgt:`FRAMEWORK` target
+property for an example.  Versions of Mach-O binaries may be checked with the
+``otool -L `` command.
diff --git a/Help/prop_tgt/VERSION.rst b/Help/prop_tgt/VERSION.rst
index 87f6c49..66e7bde 100644
--- a/Help/prop_tgt/VERSION.rst
+++ b/Help/prop_tgt/VERSION.rst
@@ -3,14 +3,27 @@ VERSION
 
 What version number is this target.
 
-For shared libraries VERSION and SOVERSION can be used to specify the
-build version and API version respectively.  When building or
+For shared libraries ``VERSION`` and :prop_tgt:`SOVERSION` can be used
+to specify the build version and API version respectively.  When building or
 installing appropriate symlinks are created if the platform supports
 symlinks and the linker supports so-names.  If only one of both is
 specified the missing is assumed to have the same version number.  For
-executables VERSION can be used to specify the build version.  When
+executables ``VERSION`` can be used to specify the build version.  When
 building or installing appropriate symlinks are created if the
-platform supports symlinks.  For shared libraries and executables on
-Windows the VERSION attribute is parsed to extract a "major.minor"
-version number.  These numbers are used as the image version of the
-binary.
+platform supports symlinks.
+
+Windows Versions
+
+
+For shared 

[CMake] What is the best way to *export* the transitive dependencies of a library?

[Cfyz]

Say the executable Exe uses some static library Foo which uses other
libraries, e. g. Bar:

  Exe --> Foo --> Bar

As the developer of Foo and I want to make it easy to link against:

  find_package(Foo REQUIRED)
  target_link_libraries(Exe PRIVATE Foo)

The problem lies with the various dependencies of Foo necessary to use it:
definitions, include directories, libraries. The Foo is a complex
multimedia-processing library with a wide range of configuration options,
so there is a reason why a lot of information may be necessary to use it in
another project.

The official (and quite neat) way to prepare a configuration module
(FooConfig.cmake) is to use install/export commands:

  install(TARGETS Foo EXPORT FooExport DESTINATION lib)
  install(EXPORT FooExport DESTINATION lib/cmake/Foo FILE FooConfig.cmake)

That, however does not export transitive properties of the target. If, for
example there was some Bar dependency:

  find_package(Bar REQUIRED)
  target_link_libraries(Foo PUBLIC Bar)

Then it will indeed use INTERFACE_xxx properties of Bar while building Foo.
But FooConfig.cmake will only list a lone Bar dependency in the
INTERFACE_LINK_LIBRARIES property of an imported Foo target:

  add_library(Foo STATIC IMPORTED)
  set_target_properties(Foo PROPERTIES ... INTERFACE_LINK_LIBRARIES
"...;Bar")

Which, obviously, is not enough to link against the Foo target in another
project. This behavior is mentioned a bit in CMake documentation:

  "Note that it is not advisable to populate the INTERFACE_LINK_LIBRARIES
of
  a target with paths for dependencies. That would hard-code into installed
  packages the include directory paths for dependencies as found on the
machine
  the package was made on."

Which is probably the reason why CMake does not export interface part of
dependencies itself. But I do not see any way around it. By not including
transitive dependencies in configuration module, the responsibility to
search for those dependencies is shifted to the Exe project. But Exe cannot
know which dependencies were enabled during particular Foo's configuration
or where to search for them.

Is this a bug? I'd expect there to be at least an option to include
transitive dependencies during the export. There is
EXPORT_LINK_INTERFACE_LIBRARIES option but it uses deprecated properties
and has no visible effect.

Or am I missing something here? What is the proper way to go around this
issue?

It is not hard to come up with a workaround, in fact. It should be enough
to populate the INTERFACE_xxx (COMPILE_DEFINITIONS, INCLUDE_DIRECTORIES,
LINK_LIBRARIES, maybe SYSTEM_INCLUDE_DIRECTORIES as well) properties of Foo
with contents of respective INTERFACE_xxx properties of all Foo's
dependencies. That, however, will require to include a rather noticeable
piece of homebrew (and somewhat obscure) code to every project trying to
export imported dependencies. Not elegant, will probably break in some
corner case and hard to sell while advertising CMake to collegues.
-- 

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] [PATCH] Update documentation for VERSION and SOVERSION for Mach-O file formats (OSX, iOS, BSD etc.)

[Bartosz Kosiorek]

Hello.

Last time I faced problem, how to set "current version" and "compatibility
version" on binaries produced by OS X.

I have updated documentation to describe how to archieve that, to make life
easier for new CMake users.

Please let me know what do you think about it.
Do you think it could be pushed into CMake 3.6 ?

Best Regards
Bartosz


0001-Add-description-of-versions-target-property-for-Mach.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

Re: [CMake] gathering directory names in cmake

[Lee Butler]

Alas, this has no effect.  Consider the following shell script:

-
#!/bin/sh
if [ -d attempt ] ; then rm -rf attempt ; fi
mkdir attempt
cd attempt
for d in src src/app src/plugins/one ; do
mkdir -p $d/xyz
touch $d/xyz/one.txt
touch $d/xyz/two.txt
done
PATTERN="\${CMAKE_SOURCE_DIR}/src/*xyz/"

cat > CMakeLists.txt   wrote:


>I have a source tree which contains multiple directories each of which has
>a subdirectory called "xyz".  I want to create a target that creates a zip
>file with each of the xyz directories.  So if the source tree looks like
>   src
>   src/xyz
>src/application
>src/application/xyz
>src/plugins/one/xyz
>
>I want to end up with a zip file containing:
>src/xyz/*
>src/application/xyz/*
>src/plugins/one/xyz/*
>
>On unix I could just generate the list of these directories with:
>   find src -type d -name test -print
>alas, I need a cross-platform way to do this.
>
>I tried:
>   file(GLOB_RECURSE XYZFILES "${CMAKE_SOURCE_DIR}/src/*xyz)
>and got nothing.
>
>At the moment, it looks like I cannot wildcard any portion of the
>directory path.  The following:
>   file(GLOB_RECURSE XYZFILES "${CMAKE_SOURCE_DIR}/src/*xyz*")
>

what about adding a backslash at end of expression ?
file(GLOB_RECURSE XYZFILES "${CMAKE_SOURCE_DIR}/src/*xyz/")


seems to only produce files which have xyz in their name.

>
>Lee
>--
>
-- Regards, Rashad


-- 

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