Original discussion:

http://forum.dlang.org/post/ranqlmrjornlvopsuris@forum.dlang.org


Now, with the `-b binary` option, reggae creates an executable called "build" in the build directory (i.e. wherever the CWD was when calling the tool) that knows how to build the project. If needed, there is no longer a dependency on make or ninja. I haven't tested it extensively, but it does pass all the other tests I wrote for make and ninja, so it looks good.

Atila

On Saturday, 6 June 2015 at 20:07:22 UTC, Atila Neves wrote:
> Original discussion:
>
> http://forum.dlang.org/post/ranqlmrjornlvopsuris@forum.dlang.org
>
> Now, with the `-b binary` option, reggae creates an executable called "build" in the build directory (i.e. wherever the CWD was when calling the tool) that knows how to build the project. If needed, there is no longer a dependency on make or ninja. I haven't tested it extensively, but it does pass all the other tests I wrote for make and ninja, so it looks good.
>

I like what you're doing with reggae, and I salute the work.

I will reiterate my suggestion to consider making Reggae a simple package import so this build functionality can be used in anyone's D program, including the Reggae tool.

We already have the ability to generate a binary with the compiler, so the binary backend seems a little redundant.  You have all the great features one would need:  Targets, dependencies, flags, build driver, etc...  so it seems plausible to move some of your driver code to the payload/reggae package to make one's task of building a custom driver trivial.

I don't suggest making a libreggae library as a separate repository from the Reggae tool, but rather simply do the refactoring to make payload/reggae folder importable from any D program, including the Reggae tool itself.

Mike

On Sat, 06 Jun 2015 20:07:20 +0000, Atila Neves wrote:

> Original discussion:
> 
> http://forum.dlang.org/post/ranqlmrjornlvopsuris@forum.dlang.org
> 
> 
> Now, with the `-b binary` option, reggae creates an executable called "build" in the build directory (i.e. wherever the CWD was when calling the tool) that knows how to build the project. If needed, there is no longer a dependency on make or ninja. I haven't tested it extensively, but it does pass all the other tests I wrote for make and ninja, so it looks good.
> 
> Atila

wow. now i'm really thinking about migrating to Reggae! ;-)

On Sunday, 7 June 2015 at 02:04:33 UTC, Mike wrote:
> On Saturday, 6 June 2015 at 20:07:22 UTC, Atila Neves wrote:
>> Original discussion:
>>
>> http://forum.dlang.org/post/ranqlmrjornlvopsuris@forum.dlang.org
>>
>> Now, with the `-b binary` option, reggae creates an executable called "build" in the build directory (i.e. wherever the CWD was when calling the tool) that knows how to build the project. If needed, there is no longer a dependency on make or ninja. I haven't tested it extensively, but it does pass all the other tests I wrote for make and ninja, so it looks good.
>>
>
> I like what you're doing with reggae, and I salute the work.
>
> I will reiterate my suggestion to consider making Reggae a simple package import so this build functionality can be used in anyone's D program, including the Reggae tool.
>
> We already have the ability to generate a binary with the compiler, so the binary backend seems a little redundant.  You have all the great features one would need:  Targets, dependencies, flags, build driver, etc...  so it seems plausible to move some of your driver code to the payload/reggae package to make one's task of building a custom driver trivial.
>
> I don't suggest making a libreggae library as a separate repository from the Reggae tool, but rather simply do the refactoring to make payload/reggae folder importable from any D program, including the Reggae tool itself.

I'll think about it. I don't think it's that easy, but I might be wrong. I had to solve all sorts of interesting problems to get a build description in D to work at all, but who knows, it might be simpler than I"m making it out to be.

I'm currently considering (because of dmd, druntime and phobos) how to strip it down to its bare essentials and have a core set of source files that only knows how to build D code, i.e. no C/C++, no dub, no make/ninja. That way just the small core can be distributed which can bootstrap itself and then build D code. I'm still figuring it out.

Atila

On Sunday, 7 June 2015 at 05:30:56 UTC, ketmar wrote:
> On Sat, 06 Jun 2015 20:07:20 +0000, Atila Neves wrote:
>
>> Original discussion:
>> 
>> http://forum.dlang.org/post/ranqlmrjornlvopsuris@forum.dlang.org
>> 
>> 
>> Now, with the `-b binary` option, reggae creates an executable called
>> "build" in the build directory (i.e. wherever the CWD was when calling
>> the tool) that knows how to build the project. If needed, there is no
>> longer a dependency on make or ninja. I haven't tested it extensively,
>> but it does pass all the other tests I wrote for make and ninja, so it
>> looks good.
>> 
>> Atila
>
> wow. now i'm really thinking about migrating to Reggae! ;-)

Cool. :)

The binary backend isn't very good (it's probably as slow as make); I did the simplest thing that would work. I want to eventually optimise it so it's competitive with ninja and tup. But to do that I need to measure, and to do that I need to write the tup backend and a program to generate a synthetic project with thousands of files.

Atila

Atila

On Sun, 07 Jun 2015 07:02:49 +0000, Atila Neves wrote:

> The binary backend isn't very good (it's probably as slow as make); I did the simplest thing that would work. I want to eventually optimise it so it's competitive with ninja and tup. But to do that I need to measure, and to do that I need to write the tup backend and a program to generate a synthetic project with thousands of files.

yet it's a good start anyway. i'm not using make, and don't want to install another build tool too. so binary that doesn't require any other tool is great addition.

On Sunday, 7 June 2015 at 07:00:18 UTC, Atila Neves wrote:

> I'm currently considering (because of dmd, druntime and phobos) how to strip it down to its bare essentials and have a core set of source files that only knows how to build D code, i.e. no C/C++, no dub, no make/ninja. That way just the small core can be distributed which can bootstrap itself and then build D code. I'm still figuring it out.

Thumbs Up!

The interface can follow that of vibe:
--- build.d ---
import std.experimental.build;

Build myBuild(){ ... }

mixin BuildMain!(myBuild);
---

Then
$ rdmd build.d
 - compile and run the script, which builds the project by default
$ rdmd build.d -ninja
 - the script run with -ninja switch only generates ninja scipt
$ rdmd build.d -make
 - same, but generates make script
$ rdmd --build-only build.d
 - compiles the script, which can then be run with whatever switches you want

On Sunday, 7 June 2015 at 07:00:18 UTC, Atila Neves wrote:
> I'm currently considering (because of dmd, druntime and phobos) how to strip it down to its bare essentials and have a core set of source files that only knows how to build D code, i.e. no C/C++, no dub, no make/ninja.

Why strip?

On Sunday, 7 June 2015 at 12:06:52 UTC, Kagamin wrote:
> On Sunday, 7 June 2015 at 07:00:18 UTC, Atila Neves wrote:
>> I'm currently considering (because of dmd, druntime and phobos) how to strip it down to its bare essentials and have a core set of source files that only knows how to build D code, i.e. no C/C++, no dub, no make/ninja.
>
> Why strip?

I meant "strip" in a general sense, not in the sense of stripping symbols.

Atila