Doc explaining [CMAKE.PASSIVE_PROJECTS] and [CPP.NO_FLAG_FORKING]

[wusatosi]

We need centralized, well written documentation (either a blog post on the beman project website or underneath the docs folder) that explains the rational behind [CMAKE.PASSIVE_PROJECTS] and [CPP.NO_FLAG_FORKING]. Confusion about this rule always comes up with new contributors (e.g. bemanproject/inplace_vector#77 (comment) ).

Relevant: #76 bemanproject/exemplar#40
Maybe @bretbrownjr 's CppNow talk once it's released.

This is marked as good-first-issue, for any one interested in taking this, most rational is already listed in the above mentioned threads and a compilation would be helpful, reply to this thread if you are interested in taking this issue, or if you have any questions.

[nickelpro]

A C99-style "Rationale" is always a good document to have hanging around somewhere. Prevents the same arguments from cropping up over and over again.

[ashu3103]

Hi @wusatosi, I am new here

Can I take this issue?

[JeffGarland]

@ashu3103 my sense is that this isn't a great first issue. It's a controversial topic even among beman leadership. The blog post below has the best treatise on the subject I've found -- and as you can see is quite involved.

https://vector-of-bool.github.io/2020/10/04/lib-configuration.html

Note that I believe what is advocated in the post is what we should do, but are not doing consistently. Specifically, at the moment some libraries (based on the current rules) are generating a tweak header (we call it config.hpp) from cmake. I believe is a flawed approach given because

• it presumes a user will actually run your cmake
• makes the cmake more complex than necessary

For header only libraries (aka most Beman libs) I don't believe the running cmake assumption is a good one. Specifically, it complicates the Godbolt use case -- as we found out when adding libraries there. Also, for many projects versioning things involves just dropping in the headers tree for a library adding a .hpp to their files -- nice when that works. I'd also argue that on principle, the C++ code should be able to stand on it's own with dependence on a build tool. A library dependent on a config/tweak header generated by cmake fails this test.

As for cmake complexities, Brett and Vito have sold me that the best cmake is generally the minimal cmake. As things stand, we require the developer to learn the rule of how to change a config.in file into a config.hpp and all the conditionals required to generate that file need to be coded. I would much rather see docs that explain to users how to construct a config/tweak header from a supplied with comments config-example.hpp file. Which is the exact equivalent of the current config.in, but with comments to change the file to config.hpp manually. As mentioned in the link the library uses has_include to either consume this file and override the default settings, or just uses it's defaults.

There's more as well. Examples and tests that fork on say the c++ version are perfectly fine to do as they don't impact the consumed library directly. And then we could get into the nuances of why it would be perfectly fine to fork some library code because it's say consteval and has zero impact on ABI -- which is the main driver for the rule.

Ok, that's more than I wanted but if you're still wanting to dig in I'm willing to help you -- but it might be better to climb a smaller hill before aiming for Everest.

[ashu3103]

@ashu3103 my sense is that this isn't a great first issue. It's a controversial topic even among beman leadership. The blog post below has the best treatise on the subject I've found -- and as you can see is quite involved.

https://vector-of-bool.github.io/2020/10/04/lib-configuration.html

That was really some good stuff, thanks for sharing

Note that I believe what is advocated in the post is what we should do, but are not doing consistently. Specifically, at the moment some libraries (based on the current rules) are generating a tweak header (we call it config.hpp) from cmake. I believe is a flawed approach given because

* it _presumes_ a user will actually run your cmake

* makes the cmake more complex than necessary

For header only libraries (aka most Beman libs) I don't believe the running cmake assumption is a good one. Specifically, it complicates the Godbolt use case -- as we found out when adding libraries there. Also, for many projects versioning things involves just dropping in the headers tree for a library adding a .hpp to their files -- nice when that works. I'd also argue that on principle, the C++ code should be able to stand on it's own with dependence on a build tool. A library dependent on a config/tweak header generated by cmake fails this test.

As for cmake complexities, Brett and Vito have sold me that the best cmake is generally the minimal cmake. As things stand, we require the developer to learn the rule of how to change a config.in file into a config.hpp and all the conditionals required to generate that file need to be coded. I would much rather see docs that explain to users how to construct a config/tweak header from a supplied with comments config-example.hpp file. Which is the exact equivalent of the current config.in, but with comments to change the file to config.hpp manually. As mentioned in the link the library uses has_include to either consume this file and override the default settings, or just uses it's defaults.

Ok, that's more than I wanted but if you're still wanting to dig in I'm willing to help you -- but it might be better to climb a smaller hill before aiming for Everest.

@JeffGarland I kind of get the idea what you are trying to convey and I completely agree with you to take small steps first. Since I'm new to C++ (I have a C background but want to make my hands dirty in C++) can you suggest me a better issue to work on. Also I have gone some of the libraries under beman, can I contribute in any of them to make myself familiar with the infrastructure and design principles of the organization.

Thanks!

[JeffGarland]

Well if you want to get you're hands on some code I'd suggest this issue #142 (slice view) since you can almost cut and paste the implementation from the paper and it's pretty small.

If you want to stick with docs I suggest this issue: #50. Which should recommend the approach followed here.

https://github.com/bemanproject/scope/blob/main/include/beman/scope/scope.hpp#L13-L15

That is, it should always be a check in the C++ code since this always works independent of the cmake (see above).

[ashu3103]

Well if you want to get you're hands on some code I'd suggest this issue #142 (slice view) since you can almost cut and paste the implementation from the paper and it's pretty small.

Okay I am moving ahead with this one.

Thanks for the opportunity!