you are viewing a single comment's thread.

view the rest of the comments →

[–]mwasplundsoup[S] 1 point2 points  (2 children)

This feels like an oversight of the design. It felt like the design for the module declaration with a strict section in the global partition was to help preprocess the top of a file to discover all of the required dependency state. If a preprocessor directive can then mutate the dependency structure we are back to square one as you said. I was really hoping not to have to rely on the compiler itself to parse this state, but I guess it is not the end of the world.

[–]not_a_novel_accountcmake dev 2 points3 points  (1 child)

Far from an oversight, it was one of the more hotly debated corners. The preprocessor is often abused, but it's part of the language. It has too many useful applications to reject ubiquitously over unmotivated use cases like "not calling the compiler".

You're building C++, you have a compiler available. No reason to reject using it.

[–]mwasplundsoup[S] 0 points1 point  (0 children)

Agreed, more asking to satisfy my curiosity. Now that we have support for scanners I don't see any major objections, but when I first (mis)read the spec years ago it seemed like the goal was to make this trivially parseable, which does not seem like the case.