www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Reggae binary backend: build your project with a D compiled executable

reply "Atila Neves" <atila.neves gmail.com> writes:
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
Jun 06 2015
next sibling parent reply "Mike" <none none.com> writes:
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
Jun 06 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
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
Jun 07 2015
next sibling parent "Mike" <none none.com> writes:
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!
Jun 07 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
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?
Jun 07 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
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
Jun 07 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Monday, 8 June 2015 at 05:51:58 UTC, Atila Neves wrote:

 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


I still agree with what he says. ninja and make have had 
countless manhours poured into them, from optimizations to 
bugfixes. D community seems obsessed with NIH.
Jun 07 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Monday, 8 June 2015 at 06:59:26 UTC, weaselcat wrote:

 On Monday, 8 June 2015 at 05:51:58 UTC, Atila Neves wrote:

 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


 I still agree with what he says. ninja and make have had 
 countless manhours poured into them, from optimizations to 
 bugfixes. D community seems obsessed with NIH.


I'm personally more than ok with using ninja (as mentioned 
previously, make is slow). Or tup, which I plan to add a backend 
for.

But... if we're to think of replacing the current Makefiles for 
dmd, druntime and phobos, and if the build descriptions that are 
to replace them are to be truly cross-platform, then a binary 
backend is needed and a stripped down version that won't clutter 
the repositories desired.

The version available on dub will always be one with all the 
features turned on.

Atila
Jun 08 2015
parent reply "Kagamin" <spam here.lot> writes:
On Monday, 8 June 2015 at 08:00:12 UTC, Atila Neves wrote:

 But... if we're to think of replacing the current Makefiles for 
 dmd, druntime and phobos, and if the build descriptions that 
 are to replace them are to be truly cross-platform, then a 
 binary backend is needed and a stripped down version that won't 
 clutter the repositories desired.


I think, they are useful. Why do you think they would clutter the 
repositories?
Jun 08 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
On Monday, 8 June 2015 at 08:47:21 UTC, Kagamin wrote:

 On Monday, 8 June 2015 at 08:00:12 UTC, Atila Neves wrote:

 But... if we're to think of replacing the current Makefiles 
 for dmd, druntime and phobos, and if the build descriptions 
 that are to replace them are to be truly cross-platform, then 
 a binary backend is needed and a stripped down version that 
 won't clutter the repositories desired.


 I think, they are useful. Why do you think they would clutter 
 the repositories?


I obviously think they're useful as well. As to the clutter, it's 
the vibe I get from the people who maintain them. I'm just trying 
to make reggae easier to adopt.

Atila
Jun 08 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 06 Jun 2015 20:07:20 +0000, Atila Neves wrote:


 Original discussion:
=20
 http://forum.dlang.org/post/ranqlmrjornlvopsuris forum.dlang.org
=20
=20
 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.
=20
 Atila


wow. now i'm really thinking about migrating to Reggae! ;-)=
Jun 06 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
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
Jun 07 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
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=20
install another build tool too. so binary that doesn't require any other=20
tool is great addition.=
Jun 07 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
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
Jun 07 2015