Make IN Dlang
Christian Köstlin
christian.koestlin at gmail.com
Wed Nov 2 20:16:22 UTC 2022
On 02.11.22 20:16, H. S. Teoh wrote:
> 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
>
Thats an interesting approach. Reggae goes a little bit in that
direction, right?
Kind regards,
Christian
More information about the Digitalmars-d-learn
mailing list