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

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

On 02.11.22 17:24, Kagamin wrote:
> Another idea is to separate the script and interpreter then compile them together.
> ```
> --- interp.d ---
> import script;
> import ...more stuff
> ...boilerplate code
> int main()
> {
>    interpret(script.All);
>    return 0;
> }
> 
> --- script.d ---
> #! ?
> module script;
> import mind;
> 
> auto All=Task(...);
> ...more declarative tasks
> 
> --- run ---
> dmd /usr/local/interp.d /path/to/script.d
> ```
Thanks, have to think a little about that :)

Kind regards,
Christian

On Wed, Nov 02, 2022 at 09:16:22PM +0100, Christian Köstlin via Digitalmars-d-learn wrote:
> On 02.11.22 20:16, H. S. Teoh wrote:
[...]
> > 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.
[...]
> Thats an interesting approach. Reggae goes a little bit in that direction, right?
[...]

I haven't actually used reggae myself, but a cursory look suggests that this is probably the case.


T

-- 
A mathematician is a device for turning coffee into theorems. -- P. Erdos

Happened to stumble across this today, which I thought is a relevant, if sadly humorous, take on build systems:

	https://pozorvlak.dreamwidth.org/174323.html


T

-- 
ASCII stupid question, getty stupid ANSI.