It is better for some things and worse for others
We can design API on top of std::filesystem in case something is missed. My first complaint would be that it doesn't exist.
Why do you say this? Because there is very detailed documentation. I would appreciate it if you could give one example of the limitation of HMake. I feel all of what you are describing is either supported or can be supported. On Fri, Mar 22, 2024 at 6:22 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 3/22/24 16:03, Hassan Sajjad wrote:
Please, don't top-post.
Sorry, what do you mean by that? I use Reply All button in Gmail.
I've included a link to our discussion policies that, among other things, explains what top-posting is. I'm including the link again, for your convenience:
https://www.boost.org/community/policy.html#quoting
I can see you're explicitly using std::filesystem in some examples, and that reinforces my suspicion.
std::filesystem is much better than CMake filesystem API or any other build-system's filesystem API. And for anything advanced, much less verbose as-well.
It is better for some things and worse for others. Where in b2 or CMake you would glob the filesystem using a wildcard, std::filesystem would require one to write a loop with directory iterators and applying a wildcard (which is not available in the std::filesystem). It would also require one to handle any errors that might arise in the process.
I can believe it was easier *for you* to implement the build
scenario in
HMake - because you know HMake. It won't be necessarily the case for someone new to HMake, especially without documentation.
I would love to address if you have any specific complaints regarding documentation.
My first complaint would be that it doesn't exist. Have a look at b2 docs or CMake reference for a few examples of what I have in mind.
Also, SFML looks like a much smaller library than Boost.
But it could be considered a middle-sized project. And I don't see a reason for my build-system to not scale.
It's not so much about scaling (although scaling is not a given, too) but about various features and corner cases. I mentioned configure-time checks earlier. Then there are non-trivial dependencies between libraries. There is support for configuration (e.g. which Boost libraries to build, release/debug, single/multi-threaded, which C++ runtime to link, etc.). Then there are tests and documentation, which also use a variety of tools to build.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost