Jump to page: 1 2
Thread overview
Make IN Dlang
Nov 01, 2022
Christian Köstlin
Nov 01, 2022
Adam D Ruppe
Nov 02, 2022
Christian Köstlin
Nov 02, 2022
Tejas
Nov 02, 2022
Christian Köstlin
Nov 02, 2022
rikki cattermole
Nov 02, 2022
Christian Köstlin
Nov 02, 2022
JN
Nov 02, 2022
H. S. Teoh
Nov 02, 2022
Christian Köstlin
Nov 03, 2022
H. S. Teoh
Nov 02, 2022
Kagamin
Nov 02, 2022
Kagamin
Nov 02, 2022
Kagamin
Nov 02, 2022
Christian Köstlin
Nov 05, 2022
H. S. Teoh
November 02, 2022
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.

Dlang is also quite expressive, so I thought why not define the build in Dlang.

The result is mind (https://gitlab.com/gizmomogwai/mind). An example mindfile looks like this:
```
#!/usr/bin/env dub
/+ dub.sdl:
   name "mindfile"
   dependency "mind" version="~master"
   ...further dependencies...
 +/
import mind;
import std.stdio : writeln;
import std.format : format;
import std.range : iota;
import std.algorithm : map;
import std.array : array;
import core.thread.osthread : Thread;
import core.time : msecs;

int main(string[] args)
{
    description("Do all");
    auto all = task("all", null, (t) {});

    for (int i=0; i<1000; ++i)
    {
        auto fileName = "out/file-%s.txt".format(i);
        all.enhance(fileName);
        description(fileName);
        file(fileName, null, (t)
             {
                 Thread.sleep(100.msecs);
                 sh("touch %s".format(t.name));
             },
        );
    }

    return mindMain(args);
}

```

This uses dub's single file feature
(https://dub.pm/advanced_usage#single-file) to get the helper library
and "execution engine" (mind).

The main functions defines a bunch of tasks or file-tasks and finally
forwards to the main function of the library for parallel (if possible)
execution of the tasks.

At the moment this is still in an experimental stage, but has nice
features such as:
- colorized --help (thanks to argparse)
- --tasks to show all defined (and commented tasks)
- parallel execution


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?
2. How can the program as is made nicer/shorter? (one could just import
   std, or make use of https://code.dlang.org/packages/scriptlike)?
3. Does this make sense at all, or should we just use make/rake? (dub
   also uses a custom build.d file).


Kind regards,
Christian
November 01, 2022
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
November 02, 2022

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

Reggae, the build system mentioned by Adam, supports tup as a backend, so you could use that as well

November 02, 2022
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).
November 02, 2022
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

November 02, 2022
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

November 02, 2022
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

November 02, 2022
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.
November 02, 2022

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.

November 02, 2022

But embedded sdl is likely to be dwarfed by the actual code anyway.

« First   ‹ Prev
1 2