Fix reference to libc++ on Mac (__1 and __LIBCPP_ABI_VERSION are both… - #33

From the message at cppreference talk page it seems that you have larger plans. Could you present them so that we can devise the best way to proceed?

Several comments and comments about the current PR:

1. Why XSLT has been replaced with BeautifulSoup parser? Is it to get more capabilities to process the content, or any other reason?

2. Before changing the HTML preprocessor implementation I'd like to have some kind of regression test suite. Could you implement a python script that takes a HTML file, calls some API to be tested and then compares the resulting DOM tree with a stored reference HTML file. Please put it in test/postprocess.py. Having this, I'll take care of the actual test data myself.

3. QtCreator ibc++ issues will better be handled by users overriding the standard library with the dummy API which is in headers/ directory of this repo. This will enable better code completion too.

4. What's the point of a75377a? Is it just to move link map generation in the preprocess step?

5. Please don't combine commits that do different things and write longer commit messages. It's quite hard to understand the reasoning behind some of the changes e.g. here 6ea11ad :)

6. In the wiki you mentioned you intend to write generation of index-functions-* in the future. Could you tell me more about how are you plan to do that? This is not trivial problem, because cppreference is not structured enough to pull this kind of data easily.
   Thanks a lot.

P.S. I've already cherry picked some of the trivial changes.

When the PR started my intention was to PR only the changes for MacOSX, but I didn't find an option for just doing that. And since there were many warning messages during conversion I started to have a deeper look.

1. XSLT gave many warning messages. I don't know if the HTML is not valid, or if it is valid as HTML but not as XML. Beautifulsoup can handle even bad HTML files and so it seemes to be a good choice here.
2. When time permits sure. It's the question, if these are some scripts or if it should evolve in a conversion suite. For the last I would like to consider some other ideas, too.
3. I don't want to put any burden on users. Could you please explain how extra headers will help with code completion and what you expect users to do to use the qch?
4. The enhanced clean up of the code removed information used for link map generation (but not useful for the offline version as far as I can judge), so this commit put the link map generation first.
5. Yes, well, hobby side project, not always as clean as it should be...
6. I know some of the pages but for sure not all. And from those I checked it looked possible to extract the needed information. I haven't started with that yet. The question is, if it possible to get maybe a 80%-90% version automatically compared to a 100% version with regular manual maintenance (the 100% only, if there are no human errors, and there will be... ).

My problem was, that I wanted an up to date offline version, the scripts were not working and after getting them to work on Mac they produced lots of warnings... I really love cppreference for my C++ day job, and so I want to see how far this can go.
A dream would be to get cppreference, boost (and other) docs, and maybe scraped reference articles from the web in one source for individual reference, but that is far ahead. I got a clean and up to date export that helps me and my colleagues with their jobs and that is very nice.

It would be very nice if we could find a common ground to evolve the export project.

1. These warnings are valid. Cppreference is not valid HTML in a lot of cases. However xsltproc could handle that just fine and warnings were a good way to see which pages need attention.
2. Basically what I'd like to have is a bunch of test HTML files in one folder and expected HTML output files in another. The test runner invokes the preprocess script for each one, compares the output to the expected files and fires errors if mismatch is found.
3. This is extra feature. Basically, with these simplified headers if you write: std::vector<std::string> z; auto x = z.begin(); x-> then the autocomplete fires with members of std::string. This is one of the simpliest case, there are many more possibilities.
4. Hmm, not good :( I'd like to check what exact information has got removed. Maybe the new implementation cleans up all the scripts, etc..
5. It would be comparatively hard to separate the manual and automatic parts. But if you manage to get something more maintainable than the current situation, that would be great.

I've included most of the functionality form this PR to the repository. The reasons for inclusion the rest is as follows:

• lxml -> BeautifulSoup: not enough reasons for the change, except simpler API. Both use libxml for parsing and error recovery. The point wrt. testing that I raised previously was stupid; it's not hard just to commit parsing results to version control and inspect changes manually.
• merge C and C++ devhelp files - C and C++ are separated for a reason. They are different languages, using C reference for C subset of C++ works until the little differences start to bite.
• remove "About this image" icons - can't do that due to license (all images must be attributed)
• process FAQ - the page is not important enough for this amount of complexity, sorry :-)

Anyway, thanks a lot for your work