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