On Tue, Jun 28, 2016 at 12:04 AM, Eric Noulard <eric.noul...@gmail.com> wrote:
> > > 2016-06-25 17:42 GMT+02:00 Ruslan Baratov <ruslan_bara...@yahoo.com>: > >> On 25-Jun-16 10:44, Craig Scott wrote: >> >> One of the slight wrinkles here is that the distinction between configure >> and generation times is now a little stronger due to generator expressions. >> In order to really understand generator expressions, you cannot really >> avoid getting your head around configure and generate being distinct parts >> of the process. Personally, I tend to gloss over the distinction when >> explaining things so as not to distract the reader, but if I'm explaining >> something to do with generator expressions, then the distinction has to be >> made and I deliberately use the terms *configure* and *generation* >> stages. >> >> I'm not sure I understand the link between "generator expressions" and >> "confusing configure+generate stage". Do you mean "generator expressions" >> on "configure+generate stage" vs "build stage"? >> > > Generator expression came up because one needs to evaluate some variable > value [apparently]at "build time" > like knowing the exact name (with path) of a target (using TARGET_FILE > generator expression in custom command). > > Knowing that "generator expression" are in fact evaluated during > "generation step" and not really at build time > is an implementation detail. (Which is a big one for implementors) but not > really important to user. > My original comment was more about the fact that users have to understand that the *result* of a generator expression is not available at configure time. This is what makes them unique compared to things like ordinary CMake variables. A classic case of this is where the developer may want to know the binary directory of a particular target. In the past, they might try using the LOCATION target property, but this would have been wrong for multi-config generators like Xcode or Visual Studio. The right way to do it is to use a generator expression like $<TARGET_FILE_DIR:myTarget>, but you cannot use that in contexts where the value is needed immediately, such as in a call to configure_file(). This example is contrived (there are other ways to achieve the developer's goal), but it illustrates a common thought process and if the developer doesn't understand when a generator expression result is computed/available, they won't understand why using one in such contexts doesn't work. Not my best explanation, but hopefully that made sense. ;) -- Craig Scott Melbourne, Australia http://crascit.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
