another build system for C++ !?! Yikes!
This is really a hard long task, if you want it feature-rich and want to get people to use it. (at least that’s my opinion.)

Particularly with CMake being really very very nice.
To me CMake is the answer to all my build tasks:

* It can do multi-platform and generate Makefiles for Linux, MSYS2, Mingw, Visual Studio, Eclipse, etc.
* It handles Qt moc without problems. http://doc.qt.io/qt-5/cmake-manual.html
* It handles cross-builds nicely (example: https://github.com/arobenko/embxx_on_rpi )
* It has a good plugin system e.g. for finding libraries (e.g. cmake -DBOOST_ROOT=/path/to/boost ..) https://cmake.org/cmake/help/latest/module/FindBoost.html
* It has good support for building libraries (shared, static)
* debug vs release builds
* build vs install commands
* flexible RPath support
* support for pulling in remote projects via git (e.g. https://github.com/Crascit/DownloadProject )
* command language (copy this here, do this after build, etc.)
* detect platform, detect endianness, detect 32 bit vs 64 bit
* generate files (e.g. special .h file)
* support for packaging (e.g. deb files)

Regards,
ajneu

As for conversion of “male” to gender, that’s a good question that is answered in the documentation.

And how do you convert from “male” to gender::male? C++ does not support reflection.

So in my talk I suggested that people don’t corner themselves and instead stick to real XML parsers. There are plenty of conforming and fast implementations out there. And not a single person in the audience raised your “but it works in 99% of use cases” objection.

Regarding the in-memory vs streaming API argument (which is also covered in the talk extensively), most people think they need DOM but I think this is just because of the really bad streaming APIs that were available up to this point. So I tried to convince the audience that streaming is actually sufficient for the majority of cases. Plus, it is easy to go from streaming to in-memory but not the other way around. In fact, libstudxml has the ‘hybrid’ example which shows how to do hybrid, partially streaming/partially in-memory parsing and serialization.

Fast/compact XML libraries solve real problems. As long as a parser can read a valid XML disregarding DTD entities, it’s applicable to 99% real-world problems.

If I were to consider libstudxml vs pugixml in a project, I would *not* use this as a disctinction point. A much more important thing is that all three parsers that you specified are DOM, and this parser is pull-based - so depending on the task at hand one is more applicable.

Seriously, though, I can’t imagine them being very different compared to Raspberry PI, provided you are using one of the Linux distributions on BeagleBone. Most likely it is just a matter of getting a different cross-compiler toolchain.

Alternatively properties that are not specific to a solution can be shared by loading the same Property Sheet in the various projects where required.

I suspect this would avoid the problems you encountered re VS2010 and VS2012 sharing

Not sure if const === serious.

Boost multi_index tries to protect one from accidentally changing the key by returning references to const elements from find(). There is nothing wrong with casting away that const qualifier, it is like saying: “yeah, I know the key must not change, I promise not to do that and I know what I am doing”.