[CMake] Iterating over a generator expression list, specifically $<TARGET_OBJECTS:objlib> of an OBJECT library

[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 <george.p.f at mail.com> 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 $<TARGET_OBJECTS:objlib12>)
> >     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.