[Cmake-commits] CMake branch, master, updated. v3.12.1-495-ge04a023

2018-08-29 Thread 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  e04a023eabc9ec309d002a9acd887d79f65d4b84 (commit)
  from  6783fac20a060d0078a03775f179a0f020c53267 (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=e04a023eabc9ec309d002a9acd887d79f65d4b84
commit e04a023eabc9ec309d002a9acd887d79f65d4b84
Author: Kitware Robot 
AuthorDate: Thu Aug 30 00:01:09 2018 -0400
Commit: Kitware Robot 
CommitDate: Thu Aug 30 00:01:09 2018 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 651ef61..e88f20e 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 12)
-set(CMake_VERSION_PATCH 20180829)
+set(CMake_VERSION_PATCH 20180830)
 #set(CMake_VERSION_RC 1)

---

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


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


Re: [CMake] Iterating over a generator expression list, specifically $ of an OBJECT library

2018-08-29 Thread Eric Noulard
Le mer. 29 août 2018 à 14:44, George PF  a écrit :

>
> >
> > My opinion (but I may be proven wrong by others) is that genex contains
> > generator specific bits that cannot be **evaluated**
> > until the build system is generated.  Properties (on target, or
> directory,
> > or files) contains informations that is available as soon
> > as the corresponding CMakeLists.txt part defining the object has been
> > processed.
>
> That seems more like an internal cmake limitation. Though maybe on purpose
> so
> the scripts can not be tailored for just one backend.
>

I think this was a design choice thus the name "Generator" expression they
are evaluated at generation time
not configuration time and I don't think it's an internal cmake limitation,
I think (but I may be wrong) that this
"generation step" would happen for any generative build system.

And there is more than that about "when" you'll know some var values.
Some generators are supporting "multiple build configuration" like MSVC and
Xcode so that
the build output dir is "mangled" with a prefix **at build time** (since
you can switch configuration after you have generated your project files).
see e.g.
https://cmake.org/cmake/help/latest/variable/CMAKE_CFG_INTDIR.html

And the documentation says quite optimistically: "Generator expressions are
> allowed
> in the context of many target properties", a more restrictive phrasing -
> "only works
> with X / Y for reasons Z" would help there.


I agree this could be clearer.
Having a possibly exhaustive description of where genex may be used would
be nice.
May be it's worth a bug report with a proposal doc update?

Genex support is added in places where it is useful (and possible I guess):
https://gitlab.kitware.com/cmake/cmake/issues/15374
https://gitlab.kitware.com/cmake/cmake/issues/15785

And concerning having them "at configure time", there is open issue
about "configuration expression":
https://gitlab.kitware.com/cmake/cmake/issues/17962


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Iterating over a generator expression list, specifically $ of an OBJECT library

2018-08-29 Thread George PF
> I cc the list because I think you drop it inadvertently.

Ah, thanks. I'll pay more attention to that now.

> Le mar. 28 août 2018 à 16:18, George PF  a écrit :
> 
> > > Because generator expressions are not handled in every cmake construct:
> > >
> > https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html
> > >
> > > genex is probably not handled in foreach.
> >
> > That is a harsh limitation, set() or list() also does not expand this
> > expression.
> >
> 
> genex are evaluated during "Generation time" i.e. when CMake
> produces/generates the specific build system
> files (makefile, [build|rules].ninja, MSVC solution etc...). This is
> convenient because some (most of) genex informations
> may be generator specific (library file name, build artefact location,
> etc...)
> 
> https://stackoverflow.com/questions/46206495/cmake-generator-expressions
> 
> set() , list(), foreach() are "running" at "CMake time" i.e. when cmake
> runs and processes CMakeLists.txt and other cmake scripts
> that is before "Generation time".
> 
> 
> And the variable XYZ, when set via this indirection to TARGET_OBJECTS,
> >
> > add_library(lib12 SHARED $)
> > get_property(XYZ TARGET lib12 PROPERTY SOURCES)
> >
> > is also not expanded yet. Is there a workaround regarding the generator
> > expressions, or
> > another way to get the TARGET_OBJECTS of an object library (and why is
> > this hidden
> > behind a generator and not available as a property)?
> >
> 
> My opinion (but I may be proven wrong by others) is that genex contains
> generator specific bits that cannot be **evaluated**
> until the build system is generated.  Properties (on target, or directory,
> or files) contains informations that is available as soon
> as the corresponding CMakeLists.txt part defining the object has been
> processed.

That seems more like an internal cmake limitation. Though maybe on purpose so 
the scripts can not be tailored for just one backend.
 
And the documentation says quite optimistically: "Generator expressions are 
allowed 
in the context of many target properties", a more restrictive phrasing - "only 
works 
with X / Y for reasons Z" would help there.
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake