Re: A proposal for a modern build-system

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2024-03-22 14:02:04

>
> 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_at_[hidden]> 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
>