Drop stubs

[K-ballo]

No description provided.

[cppalliance-bot]

An automated preview of the documentation is available at https://1030.mrdocs.prtest2.cppalliance.org/index.html

[cppalliance-bot]

An automated preview of the documentation is available at https://1030.mrdocs.prtest2.cppalliance.org/index.html

[cppalliance-bot]

An automated preview of the documentation is available at https://1030.mrdocs.prtest2.cppalliance.org/index.html

[cppalliance-bot]

An automated preview of the documentation is available at https://1030.mrdocs.prtest2.cppalliance.org/index.html

[cppalliance-bot]

An automated preview of the documentation is available at https://1030.mrdocs.prtest2.cppalliance.org/index.html

[cppalliance-bot]

An automated preview of the documentation is available at https://1030.mrdocs.prtest2.cppalliance.org/index.html

[cppalliance-bot]

An automated preview of the documentation is available at https://1030.mrdocs.prtest2.cppalliance.org/index.html

[cppalliance-bot]

An automated preview of the documentation is available at https://1030.mrdocs.prtest2.cppalliance.org/index.html

[cppalliance-bot]

An automated preview of the documentation is available at https://1030.mrdocs.prtest2.cppalliance.org/index.html

[alandefreitas]

Oh... This drops not only the stubs but the whole libcxx library from the MrDocs installation. I understand how this option can be inconvenient. You run your project on Windows and Linux, but then it has some errors on MrDocs because the stubs are different or are missing some system library function.

Still, that's a bold proposal, especially considering this is just an option. Many engineers spent months implementing and maintaining this because, as you are probably already noticing in CI, using MrDocs without this feature is hell. We seen how things are like without it, and we've been keeping it for good reason. Even though some projects might find it annoying because they get errors before they turn off the libc stubs, most other projects are avoiding lots of mistakes with reproducible builds and don't even notice it. Even the projects that turned off libc stubs are still using the libcxx headers and probably don't even know about it.

In a sense, I understand why it isn't very pleasant. This feature is like plastic surgery; you notice the ones that didn't work.

While I'm not emotionally attached to code at all, I have two obvious questions:

1. What is the motivation for removing this feature? Even if someone finds the errors super-annoying, it's still just an option, and we could even change the default parameters at any time. Problem learning MrDocs from the start, don't even notice this option (my plastic surgery metaphor). Only people who have libraries interacting with system libraries would have to know what this option is about and then make a choice (like they would with any other tool). (If the motivation is "no one ever needs this feature at all", please see (2))
2. What are we going to do about the Boost releases? Before this feature, the whole Boost release was breaking all the time because of MrDocs and Boost.URL, and everyone was angry about it. Doxygen has all kinds of defects, but it does give you reproducible builds. If we have these kinds of problems again, who's going to keep fixing them? Notice it's very expensive to test the whole thing, even if your fix works. One single round of tests to find out the line of code you changed that worked can take many hours because of the way it's set up. And even more importantly, what if the few people who know how to do this (currently me and maaaaybe Sam, depending on the bug) leave for any reason?

In the Boost release, without stable stubs, MrDocs can give you different results when you change it to an environment you haven't tested yet. Even small changes in the system could break it, because of how the process interacts with CMake and everything. And you don't have control over new environments, which is precisely the case with the Boost releases, where we don't check if each library is testing that new environment before changing it. Release managers just assume a library workflow (especially just the documentation generator) won't break the whole thing.