Put me in the +1 column here – the generated config.hpp file is a massive issue that breaks header only usage without cmake and cases like godbolt. Besides the library above this solution has created issues in inplace_vector, scope, any_view and iterator_interface – there’s probably more but those are discussions I’ve personally been involved with.
@dsankel says that supporting dropping headers into a project isn’t a case we should support, but I continue to disagree strongly. I’d argue it’s far more important than the more complicated cases which the rule is attempting to provide benefit. Part of this is that the majority of Beman libraries are in fact header-only – and as you observe this is exactly when the code needs to stand alone.
I think what you’re suggesting is the moral equivalent of boost.config? To me that seems like overkill for the bounds_test and many other cases.
Like I’ve argued for any_view I don’t think that selecting the built-in as an implementation detail on gcc impacts in any fashion the desire for link time compatibility – which is at the root of the rule. As a header only choice that’s internal to the offered api, if you compile with gcc you get the optimization in the .o (.so, .a) and there’s no impact on linkage. Or am I missing some nuance?
So after we potentially remove cases where I think the flag forking rule currently over reaches or is misapplied, lets discuss the no-exceptions fork for inplace_vector. As it stands that BEMAN_INPLACE_VECTOR_NO_EXCEPTIONS flag also does not impact linkage – however it clearly impacts behavior (abort versus exception). This library also uses the config.hpp when present – and I think that’s also not a violation of the flag forking requirement. Specifically, in the header here the library consumes the generated config.hpp if it exists which can set the flags. However, if the file does not exist the library selects a default. This allows inplace vector to work in godbolt without heroics - and for user to copy the header into a project and get appropriate defaults.
tldr: I think we need a much more nuanced definition of what can be forked and what cannot – and we need to allow libraries to set defaults in code like above when the config.hpp does not exist.
Thoughts?