On Wed, Nov 02, 2022 at 03:08:36PM +0000, JN via Digitalmars-d-learn wrote: > On Tuesday, 1 November 2022 at 23:40:22 UTC, Christian Köstlin wrote: > > sh("touch %s".format(t.name)); > > One of the problems of many Make-like tools is that they offer lots of > freedom, especially when allowing you to launch arbitrary shell > commands. But this also comes with drawbacks, because this touch > command will instantly break Windows builds, might also be a problem > on some non-Linux platforms like macOS. Declarative approach from > tools like dub might be restrictive, but it also lets me as a user > know that I can download an arbitrary dub project and 99% chance it > will just compile out of the box on Windows.
IMO, the ideal situation is a hybrid situation: the underlying build mechanism should be purely declarative, because otherwise the complexity just goes out of control and you end up with non-portability, non-reproducible builds, intractibility of static analysis (e.g., for an external tool to understand what the build does). However, quite often in a large project you need to perform some complex tasks, and doing this declaratively can be too cumbersome. So what you want is a procedural element to the build description that *generates* the underlying declarative elements of the build. The procedural part does not perform any build actions; its job is to generate the declarative build description. The actual build is carried out based on this declarative build description. T -- Life would be easier if I had the source code. -- YHL