Re: A proposal for a modern build-system

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2024-03-23 18:49:42

You have raised 3 points in your email.
1) git tracking
I think one option could be to define all configurations wrapped by cache
variables, out of which just one builds.

<quote>
void buildSpecification()
{
    if(CacheVariable("Debug", true).value)
    {
        Configuration &debug = GetConfiguration("Debug");
        debug.ASSIGN(ConfigType::DEBUG);
        configurationSpecification(debug);
    }
    if(CacheVariable("Release", false).value)
    {
        Configuration &release = GetConfiguration("Release");
        release.ASSIGN(LTO::ON);
        configurationSpecification(release);
    }
}
</quote>

Now, there is a cache variable Release set to false in cache.json in
build-dir. By default, there will be only one configuration Debug
configured. To configure the Release configuration, the user will have to
set the Release variable in cache.json to true and then run hhelper command
again in the build-dir. This way user can control the configured
configurations by changing the cache.json file which is not tracked by git.

2) CI automation
I think the above could be configured through command-line as-well.

3) And will also require them to know hmake.
The alternative is to learn the command-line.

So, I feel that it is better as it is. But the alternative is possible
as-well. hbuild could be configured to pass command-line options to our
hmake.cpp where we can parse them and define configurations based on those
variables.

On Sat, Mar 23, 2024 at 7:38 PM Дмитрий Архипов via Boost <
boost_at_[hidden]> wrote:

> сб, 23 мар. 2024 г. в 17:15, Hassan Sajjad <hassan.sajjad069_at_[hidden]>:
> > You have explained the HMake working correctly but I fail to see why it
> is a serious issue. You can define a new configuration by adding one more
> line in the configuration file.  In other build-systems, you would write
> this line on the command-line. In HMake, you write this in the
> configuration file.
>
> The key difference is that users' configuration files and common line
> invocations are not project files. Build scripts are necessarily a
> part of the project, they have to be tracked by git. If in order to
> try a different configuration I would have to change a tracked file, I
> suddenly have a non-clean workspace, and the change is most likely not
> something I would want to add to the next commit. Further, now to
> build the project for their required configuration users would have to
> effectively patch the project sources. This is very unwieldy for any
> kind of automation (CI). And will also require them to know hmake.
>
> I don't see how this is reasonable from UX perspective.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>