On Fri, Mar 16, 2018 at 6:26 PM, Titus Winters <titus@google.com> wrote:
Here's a concrete example of why the preprocessor matters deeply in this discussion.

If we build from source, we have to handle the (all too common) situation where a given library has an arbitrary set of build inputs (-D flags, compiler flags, etc).  If those aren't compatible, that'll be a problem.

If we force them to all be the same, then we have to worry about providing a mechanism to specify which flags (from an unbounded list) are required / compatible with a given library.  That's hard to extract from source.

If we instead allow each library to be built from different compiler invocations, we risk ODR.  Keep in mind that even something as simple as an assert() in a header is an ODR violation if we don't enforce consistent build flags: building that header with one definition of NDEBUG in one TU results in a different definition than one built without NDEBUG in another TU.  

Indeed ODR is a concern. But even with that concern we somehow manage today. Again, how much do we want to prevent such concerns?

In all honesty, the preprocessor and consistent build invocation is possibly the hard part.  If we come to agreement on those points, relying on existing package management solutions probably suffices.

Yes, indeed. And that's the first thing I want to tackle. I want to tackle it by standardizing compiler invocations. This is not some fanciful idea either.. It's what we've been doing with Boost Build for more than a decade by abstracting the compiler flags to portable features. Some other build systems, like cmake, do similar abstractions to some varied degrees. 


--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net