Re: [boost] A proposal for a modern build-system

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@lists.boost.org> wrote:

...

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

сб, 23 мар. 2024 г. в 17:15, Hassan Sajjad : 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