[cmake-developers] Debug through config/gen inside Visual Studio

[Brad King]

On 09/16/2016 06:32 AM, csiga.biga at aol.com wrote:
> Now it’s only up to me to understand the entire process of Makefile generation.
> Global/Local Generators, LocalMakeFileGenerator3 (does 3 correspond to the
> third layer of makefiles? If yes, where is 2?)

The 3 is the third generation of makefile generator design.  The older
versions are only available in version control history.

> The code is fairly convoluted (seems a bit more complex than neccessary,
> but it might be my lack of understanding that makes me feel this way).

There are many years of redesigns and partial refactors accumulated ;)

> One sidequestion: what is the reason for eliding STL algorithms?
> There are nice iterators all over the place, yet no algorithms used,
> even when it were possible. Algorithms make the code much easier to
> understand (the name of the algorithm states the intent of the for-loop)

Only in the last few years have we dropped support for ancient compilers
that don't have all that implemented correctly.  Some progress has been
made on modernizing some of the internals, but no thorough sweep has
been done.  Any place you see that can have a loop replaced with an
algorithm is fair game to update (with normal review of course).

> plus when C++17 hits (configure-time check?), parallel STL invocations
> could speed up the configuration process automatically with minimal
> code impact. Would you accept such patches, where loops are exchanged
> for algorithms where possible?

We do need to continue supporting C++98-only builds because we still
support platforms where C++11 compilers are hard to come by.  We do
allow compiling as any newer standard on compilers that support it
(e.g. the nightly binaries currently all build as C++11 or above).
One can see some configure-time checks for things like unordered_map.
Other optional optimizations like this are allowed, so long as they
do not produce too much clutter or layers of macros.

-Brad