alandefreitas
commented
6 months ago If we are invoking cmake, wouldn't it be better to simply obtain the implicit include directories from it instead?
Not really, because the process for getting the implicit include directories is a separate step in the workflow. We used to run cmake on an empty project and output these directories to a file from cmake. It's a workaround we don't need anymore since mrdocs can already run the compiler directly to find out what these paths are. The workaround would be a long way to achieve what the other PR by Fernando achieved.
Also, it would be better if we searched for cmake in path rather than requiring the user to provide it explicitly.
Very true. Even providing some environment variable to fall back to if possible. Or even also try to fall back to some common locations, like C:\Program Files\CMake.
Lastly, we might want to invoke with '-DBUILD_TESTING=OFF'.
We probably need some option in mrdocs.yml to describe the default cmake configure args.
For instance, Boost.URL needs -DBUILD_TESTING=ON at least for now because if tests aren't compiled, header-only functions (like boost::urls::format) aren't compiled, and mrdocs won't document them.
That's also a problem we have we filters right now. If -DBUILD_TESTING=OFF, some functions are not documented because they're not compiled. If -DBUILD_TESTING=OFF too many functions are documented because they're not filtered.
sdkrystian
fpelliccioni
If we are invoking cmake, wouldn't it be better to simply obtain the implicit include directories from it instead?
Also, it would be better if we searched for cmake in path rather than requiring the user to provide it explicitly.
Lastly, we might want to invoke with '-DBUILD_TESTING=OFF'.