Re: Make IN Dlang
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.
Re: Make IN Dlang
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
Re: Make IN Dlang
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
Re: Make IN Dlang
On 02.11.22 20:16, H. S. Teoh wrote:
On Wed, Nov 02, 2022 at 03:08:36PM +, 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
Re: Make IN Dlang
On Wed, Nov 02, 2022 at 03:08:36PM +, 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
Re: Make IN Dlang
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
```
Re: Make IN Dlang
But embedded sdl is likely to be dwarfed by the actual code anyway.
Re: Make IN Dlang
On Tuesday, 1 November 2022 at 23:40:22 UTC, Christian Köstlin wrote: I am still trying to find answers to the following questions: 1. Is it somehow possible to get rid of the dub single file scheme, and e.g. interpret a full dlang script at runtime? If there was an interpreter like ``` #!/bin/mind ...code ``` maybe it could run dub with right options and thus won't need a build script.
Re: Make IN Dlang
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.
Re: Make IN Dlang
On 02.11.22 04:07, rikki cattermole wrote: Something to consider: dub can be used as a library. You can add your own logic in main to allow using your build specification to generate a dub file (either in memory or in file system). Nice ... I will perhaps give that a try! Kind regards, Christian
Re: Make IN Dlang
On 02.11.22 03:25, Tejas wrote: On Tuesday, 1 November 2022 at 23:40:22 UTC, Christian Köstlin wrote: Dear dlang-folk, one of the tools I always return to is rake (https://ruby.github.io/rake/). For those that do not know it, its a little like make in the sense that you describe your build as a graph of tasks with dependencies between them, but in contrast to make the definition is written in a normal programming language (in this case ruby) with all features of it. [...] Sounds pretty similar to [tup](https://gittup.org/tup/) I am a great admirer of tup (especially because they incorporated as the first system (that I know of) a filesystem monitor outside of IDEs). Its language is make like I would say, for that I do not like it that much. Reggae, the build system mentioned by Adam, supports tup as a backend, so you could use that as well +1 Kind regards, Christian
Re: Make IN Dlang
On 02.11.22 00:51, Adam D Ruppe wrote: I don't have specific answers to your questions but your goal sounds similar to Atila's reggae project so it might be good for you to take a look at: https://code.dlang.org/packages/reggae Hi Adam, thanks for the pointer. I forgot about reggae ;-) From the documentation it looks more high level and already defines things like libraries and so on. It's also very ambitious in that it tries to support different backends! Mind is more low level (although some language specific things could be added on top of it. I like reggaes approach in reading in the "source" and creating something new from it (perhaps with dub as library) this could get rid of some of the boilerplate of what I have now. Kind regards, Christian
Re: Make IN Dlang
Something to consider: dub can be used as a library. You can add your own logic in main to allow using your build specification to generate a dub file (either in memory or in file system).
Re: Make IN Dlang
On Tuesday, 1 November 2022 at 23:40:22 UTC, Christian Köstlin wrote: Dear dlang-folk, one of the tools I always return to is rake (https://ruby.github.io/rake/). For those that do not know it, its a little like make in the sense that you describe your build as a graph of tasks with dependencies between them, but in contrast to make the definition is written in a normal programming language (in this case ruby) with all features of it. [...] Sounds pretty similar to [tup](https://gittup.org/tup/) Reggae, the build system mentioned by Adam, supports tup as a backend, so you could use that as well
Re: Make IN Dlang
I don't have specific answers to your questions but your goal sounds similar to Atila's reggae project so it might be good for you to take a look at: https://code.dlang.org/packages/reggae
