www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Attempt to get rid of phobos Makefiles, using reggae

reply "Atila Neves" <atila.neves gmail.com> writes:
http://dpaste.dzfl.pl/562f1ddc1aad

This can build the static and dynamic libraries on Linux. I then 
linked to the static version to make sure my programs still 
worked. They did.

For other OSs there'd be some logic to select different files. It 
was a pain figuring out exactly what posix.mak did but at least 
this works. Is this horrible or is this the kind of direction we 
might want to go? Also, why are some Linux files not being built 
on Linux with the current Makefile?

In theory this approach would mean readable build descriptions in 
D, and only one of them for all OSs instead of 3 makefiles. Also, 
never again typing `make clean`.

Once reggae has a binary backend this would mean no dependency on 
make, ninja or tup. Just a D compiler.


Atila
Jun 04 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/4/15 5:50 PM, Atila Neves wrote:

 http://dpaste.dzfl.pl/562f1ddc1aad

 This can build the static and dynamic libraries on Linux. I then linked
 to the static version to make sure my programs still worked. They did.

 For other OSs there'd be some logic to select different files. It was a
 pain figuring out exactly what posix.mak did but at least this works. Is
 this horrible or is this the kind of direction we might want to go?
 Also, why are some Linux files not being built on Linux with the current
 Makefile?

 In theory this approach would mean readable build descriptions in D, and
 only one of them for all OSs instead of 3 makefiles. Also, never again
 typing `make clean`.

 Once reggae has a binary backend this would mean no dependency on make,
 ninja or tup. Just a D compiler.


This is very cool.

I read somewhere that reggae builds itself. I'd suggest a way to build 
reggae with only OS-provided common tools, since you'd have to include 
it in the toolchain in order to build dmd/phobos otherwise.

-Steve
Jun 04 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
 I read somewhere that reggae builds itself. I'd suggest a way 
 to build reggae with only OS-provided common tools, since you'd 
 have to include it in the toolchain in order to build 
 dmd/phobos otherwise.


It can build itself, yes. Since I've only developed and tested it 
on Linux, the `bootstrap.sh` script in the repo builds it by 
calling dmd on all the sources. After that it can (and does) 
build itself. There'd have to be a .bat for Windows but any other 
POSIX system should be able to call `bootstrap.sh`.

Atila
Jun 05 2015
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Thursday, 4 June 2015 at 21:50:41 UTC, Atila Neves wrote:


 Is this horrible or is this the kind of direction we might want 
 to go?


This is a nice work, but I think I would prefer a library over a 
tool.

I envision a single package with much of what you've already 
built (Target struct, Build template, etc...) that I can simply 
import into my own build.d file, and call with rdmd.  Maybe even 
get it merged into phobos as std.build.

Mike
Jun 04 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 4 June 2015 at 23:28:37 UTC, Mike wrote:

 On Thursday, 4 June 2015 at 21:50:41 UTC, Atila Neves wrote:


 Is this horrible or is this the kind of direction we might 
 want to go?


 This is a nice work, but I think I would prefer a library over 
 a tool.

 I envision a single package with much of what you've already 
 built (Target struct, Build template, etc...) that I can simply 
 import into my own build.d file, and call with rdmd.  Maybe 
 even get it merged into phobos as std.build.


I thought of that during DConf. It's "run this tool that includes 
your description and runs the compiler for you" vs "as a library 
now I have to build the build generator myself". It didn't seem 
to make much sense to me since it'd just be more work.

I could always split the code into libreggae and have the reggae 
tool depend on it, but at this point I'm not convinced.

Atila
Jun 05 2015
prev sibling next sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 4 June 2015 at 21:50:41 UTC, Atila Neves wrote:

 http://dpaste.dzfl.pl/562f1ddc1aad

 This can build the static and dynamic libraries on Linux. I 
 then linked to the static version to make sure my programs 
 still worked. They did.

 For other OSs there'd be some logic to select different files. 
 It was a pain figuring out exactly what posix.mak did but at 
 least this works. Is this horrible or is this the kind of 
 direction we might want to go? Also, why are some Linux files 
 not being built on Linux with the current Makefile?

 In theory this approach would mean readable build descriptions 
 in D, and only one of them for all OSs instead of 3 makefiles. 
 Also, never again typing `make clean`.

 Once reggae has a binary backend this would mean no dependency 
 on make, ninja or tup. Just a D compiler.


Nice, I'm looking forward to the day we can get rid of makefiles 
to build the D toolchain, as they're such an anachronism.  Having 
the build configured in D itself would be wonderful, :) really 
looking forward to using reggae.  Since dmd already requires a 
host D compiler to build now, there certainly isn't any problem 
with the D dependency.
Jun 04 2015
prev sibling next sibling parent reply "Daniel N" <ufo orbiting.us> writes:
On Thursday, 4 June 2015 at 21:50:41 UTC, Atila Neves wrote:

 In theory this approach would mean readable build descriptions 
 in D, and only one of them for all OSs instead of 3 makefiles. 
 Also, never again typing `make clean`.

 Once reggae has a binary backend this would mean no dependency 
 on make, ninja or tup. Just a D compiler.


 Atila


Sweet! Would you be in favor of adding Exclude-Dirs as well?
Jun 05 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 5 June 2015 at 07:56:49 UTC, Daniel N wrote:

 On Thursday, 4 June 2015 at 21:50:41 UTC, Atila Neves wrote:

 In theory this approach would mean readable build descriptions 
 in D, and only one of them for all OSs instead of 3 makefiles. 
 Also, never again typing `make clean`.

 Once reggae has a binary backend this would mean no dependency 
 on make, ninja or tup. Just a D compiler.


 Atila


 Sweet! Would you be in favor of adding Exclude-Dirs as well?


I guess. I'd need some evidence it'd be needed first though. I am 
toying with the idea of passing in parameters in any order, which 
would make adding optional seldom used things like ExcludeDirs 
easier.

TBH I don't understand why other people mix files that are built 
with ones that aren't in the same directory tree.

Atila
Jun 05 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-06-04 23:50, Atila Neves wrote:

 http://dpaste.dzfl.pl/562f1ddc1aad


Reggae doesn't support shell globbing of files? Something like:

ExcludeFiles(["std/c/windows/**/*.d"]);

Or just specifying a directory.

BTW, why are some Linux specific files ignored?

-- 
/Jacob Carlborg
Jun 05 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 5 June 2015 at 09:22:14 UTC, Jacob Carlborg wrote:

 On 2015-06-04 23:50, Atila Neves wrote:

 http://dpaste.dzfl.pl/562f1ddc1aad


 Reggae doesn't support shell globbing of files? Something like:

 ExcludeFiles(["std/c/windows/**/*.d"]);


Not right now, no. The good thing about how it's designed is you 
could write your own. Of course, the whole point is to have 
usable high-level builtins as well. It's a good idea, but like I 
said before, I hardly ever have to exclude anything in my own 
projects. Feel free to open an enhancement request.


 Or just specifying a directory.


I think somebody else mentioned that already.


 BTW, why are some Linux specific files ignored?


No clue, I just went with the output of `make -f posix.mak`. It's 
the kind of thing that'd be more explicit if the build 
description were in D. It was one of my questions in the original 
post ;)

Atila
Jun 05 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/5/15 11:03 AM, Atila Neves wrote:

 On Friday, 5 June 2015 at 09:22:14 UTC, Jacob Carlborg wrote:

 On 2015-06-04 23:50, Atila Neves wrote:

 http://dpaste.dzfl.pl/562f1ddc1aad


 Reggae doesn't support shell globbing of files? Something like:

 ExcludeFiles(["std/c/windows/**/*.d"]);


 Not right now, no. The good thing about how it's designed is you could
 write your own. Of course, the whole point is to have usable high-level
 builtins as well. It's a good idea, but like I said before, I hardly
 ever have to exclude anything in my own projects. Feel free to open an
 enhancement request.


This sounds like a job for CAPTAIN RANGE!!!

Seriously though, the thought of using ranges to allow specifying files 
fits perfectly. Imagine the power!

"std/c/windows/".allSubFiles.filter!(a => a.name.extension == ".d");

Need that allSubFiles range, it probably already exists :)

-Steve
Jun 05 2015
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Friday, 5 June 2015 at 19:17:14 UTC, Steven Schveighoffer 
wrote:

 This sounds like a job for CAPTAIN RANGE!!!

 Seriously though, the thought of using ranges to allow 
 specifying files fits perfectly. Imagine the power!

 "std/c/windows/".allSubFiles.filter!(a => a.name.extension == 
 ".d");

 Need that allSubFiles range, it probably already exists :)

 -Steve




"std/c/windows/".dirEntries(SpanMode.breadth).filter!(/* etc. */);
Jun 05 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/5/15 4:01 PM, Meta wrote:

 On Friday, 5 June 2015 at 19:17:14 UTC, Steven Schveighoffer wrote:

 This sounds like a job for CAPTAIN RANGE!!!

 Seriously though, the thought of using ranges to allow specifying
 files fits perfectly. Imagine the power!

 "std/c/windows/".allSubFiles.filter!(a => a.name.extension == ".d");

 Need that allSubFiles range, it probably already exists :)




 "std/c/windows/".dirEntries(SpanMode.breadth).filter!(/* etc. */);


Nice, I was too lazy to look it up :)

-Steve
Jun 05 2015
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 5 June 2015 at 19:17:14 UTC, Steven Schveighoffer 
wrote:

 This sounds like a job for CAPTAIN RANGE!!!

 Seriously though, the thought of using ranges to allow 
 specifying files fits perfectly. Imagine the power!

 "std/c/windows/".allSubFiles.filter!(a => a.name.extension == 
 ".d");

 Need that allSubFiles range, it probably already exists :)



https://github.com/atilaneves/reggae/issues/1 :)
Jun 05 2015
prev sibling next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 5 June 2015 at 19:17:14 UTC, Steven Schveighoffer 
wrote:

 On 6/5/15 11:03 AM, Atila Neves wrote:

 On Friday, 5 June 2015 at 09:22:14 UTC, Jacob Carlborg wrote:

 On 2015-06-04 23:50, Atila Neves wrote:

 http://dpaste.dzfl.pl/562f1ddc1aad


 Reggae doesn't support shell globbing of files? Something 
 like:

 ExcludeFiles(["std/c/windows/**/*.d"]);


 Not right now, no. The good thing about how it's designed is 
 you could
 write your own. Of course, the whole point is to have usable 
 high-level
 builtins as well. It's a good idea, but like I said before, I 
 hardly
 ever have to exclude anything in my own projects. Feel free to 
 open an
 enhancement request.


 This sounds like a job for CAPTAIN RANGE!!!

 Seriously though, the thought of using ranges to allow 
 specifying files fits perfectly. Imagine the power!

 "std/c/windows/".allSubFiles.filter!(a => a.name.extension == 
 ".d");

 Need that allSubFiles range, it probably already exists :)


That... is an awesome idea.

Atila
Jun 06 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/6/15 5:05 AM, Atila Neves wrote:

 On Friday, 5 June 2015 at 19:17:14 UTC, Steven Schveighoffer wrote:

 On 6/5/15 11:03 AM, Atila Neves wrote:

 On Friday, 5 June 2015 at 09:22:14 UTC, Jacob Carlborg wrote:

 On 2015-06-04 23:50, Atila Neves wrote:

 http://dpaste.dzfl.pl/562f1ddc1aad


 Reggae doesn't support shell globbing of files? Something like:

 ExcludeFiles(["std/c/windows/**/*.d"]);


 Not right now, no. The good thing about how it's designed is you could
 write your own. Of course, the whole point is to have usable high-level
 builtins as well. It's a good idea, but like I said before, I hardly
 ever have to exclude anything in my own projects. Feel free to open an
 enhancement request.


 This sounds like a job for CAPTAIN RANGE!!!

 Seriously though, the thought of using ranges to allow specifying
 files fits perfectly. Imagine the power!

 "std/c/windows/".allSubFiles.filter!(a => a.name.extension == ".d");

 Need that allSubFiles range, it probably already exists :)


 That... is an awesome idea.

 Atila


Worth a blog post. We have these wonderful facilities that can be 
combined in great surprising ways, and... nobody knows.

Andrei
Jun 06 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Saturday, 6 June 2015 at 15:36:05 UTC, Andrei Alexandrescu 
wrote:

 On 6/6/15 5:05 AM, Atila Neves wrote:

 On Friday, 5 June 2015 at 19:17:14 UTC, Steven Schveighoffer 
 wrote:

 On 6/5/15 11:03 AM, Atila Neves wrote:

 On Friday, 5 June 2015 at 09:22:14 UTC, Jacob Carlborg wrote:

 On 2015-06-04 23:50, Atila Neves wrote:

 http://dpaste.dzfl.pl/562f1ddc1aad


 Reggae doesn't support shell globbing of files? Something 
 like:

 ExcludeFiles(["std/c/windows/**/*.d"]);


 Not right now, no. The good thing about how it's designed is 
 you could
 write your own. Of course, the whole point is to have usable 
 high-level
 builtins as well. It's a good idea, but like I said before, 
 I hardly
 ever have to exclude anything in my own projects. Feel free 
 to open an
 enhancement request.


 This sounds like a job for CAPTAIN RANGE!!!

 Seriously though, the thought of using ranges to allow 
 specifying
 files fits perfectly. Imagine the power!

 "std/c/windows/".allSubFiles.filter!(a => a.name.extension == 
 ".d");

 Need that allSubFiles range, it probably already exists :)


 That... is an awesome idea.

 Atila


 Worth a blog post. We have these wonderful facilities that can 
 be combined in great surprising ways, and... nobody knows.


I was planning on writing a blog post. I just wanted reggae to 
get more mature first. Maybe I should do one anyway.

Atila
Jun 06 2015
parent "Joakim" <dlang joakim.fea.st> writes:
On Saturday, 6 June 2015 at 15:48:30 UTC, Atila Neves wrote:

 I was planning on writing a blog post. I just wanted reggae to 
 get more mature first. Maybe I should do one anyway.


btw, you asked for a large project to build before, botan seems 
like a good candidate:

https://github.com/etcimon/botan

Seems to be around 150 klocs, maybe two-thirds the size of 
phobos.  You could use reggae to build the C++ and D versions and 
compare build times of the various compilers and build tools.  
Seems like that would be good fodder for a blog post about reggae 
and D.
Jun 06 2015
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 5 June 2015 at 19:17:14 UTC, Steven Schveighoffer 
wrote:

 On 6/5/15 11:03 AM, Atila Neves wrote:

 On Friday, 5 June 2015 at 09:22:14 UTC, Jacob Carlborg wrote:

 On 2015-06-04 23:50, Atila Neves wrote:

 http://dpaste.dzfl.pl/562f1ddc1aad


 Reggae doesn't support shell globbing of files? Something 
 like:

 ExcludeFiles(["std/c/windows/**/*.d"]);


 Not right now, no. The good thing about how it's designed is 
 you could
 write your own. Of course, the whole point is to have usable 
 high-level
 builtins as well. It's a good idea, but like I said before, I 
 hardly
 ever have to exclude anything in my own projects. Feel free to 
 open an
 enhancement request.


 This sounds like a job for CAPTAIN RANGE!!!

 Seriously though, the thought of using ranges to allow 
 specifying files fits perfectly. Imagine the power!

 "std/c/windows/".allSubFiles.filter!(a => a.name.extension == 
 ".d");

 Need that allSubFiles range, it probably already exists :)

 -Steve


So, given the range input, I realised that trying to accomodate 
what every user would never need when selecting source files, 
instead... I settled on this:

Sources!(["dir1, "dir2"]) //or
Sources!(Dirs(["dir1", "dir2"),
          Files(["extrafile1.d", "extrafile2.d"]),
          Filter!(a => ...));

Simple. Define source directories, define extra files, filter 
whatever isn't wanted out. Why reinvent the wheel when D already 
has pretty good wheels?


The result of all this (and many bug discoveries trying to copy 
posix.mak) is this:

https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d

It doesn't completely replicate the UT build with its shared 
library (I got lazy), but... right now it builds both static and 
shard phobos, creates the symlinks just like posix.mak, _and_ 
does both unit tests runs (debug and release), building the unit 
tests binaries in the process. Oh, and the html documentation 
too. I tested with the make, ninja and binary backends, and 
everything seems to work. I wouldn't be surprised if there are 
still bugs, especially with the binary backend.

Worth making a PR for? The PR would only add this file, it 
wouldn't change anything about the current build, but could be 
used for testing purposes in the meanwhile.

Oh, and given the manual filtering in the config, it obviously 
won't work on Mac OS. I have to get a hold of a Mac and make it 
work there too. Then... Windows.

Atila
Jun 29 2015
next sibling parent reply "Mike" <none none.com> writes:
On Monday, 29 June 2015 at 10:35:34 UTC, Atila Neves wrote:


 The result of all this (and many bug discoveries trying to copy 
 posix.mak) is this:

 https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d


Ah... so that's what posix.mak is doing.  And 1/3 the size.  Nice 
work!
Jun 29 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Monday, 29 June 2015 at 10:53:46 UTC, Mike wrote:

 On Monday, 29 June 2015 at 10:35:34 UTC, Atila Neves wrote:


 The result of all this (and many bug discoveries trying to 
 copy posix.mak) is this:

 https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d


 Ah... so that's what posix.mak is doing.  And 1/3 the size.  
 Nice work!


No, there's more. I don't think much more (reading makefiles is 
tedious), I concentrated on getting the important ones right 
first.

Notably, that reggaefile.d doesn't define the module.test targets 
to only test one phobos module, but that can be added easily.

It also hard-codes a lot of what are configurable variables in 
posix.mak, like the 64-bit build. All of this is doable, I just 
haven't gotten around to it yet.

Then there's the issue of making sure the functionality really is 
the same. For some reason the reggaefile is producing more HTML 
files than posix.mak but to figure out why I'll have to go and 
debug.

I wouldn't do a PR until the outputs are exactly the same, I 
posted this trying to gauge what the interest / opinions were.

Atila
Jun 29 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, 29 June 2015 at 12:06:39 UTC, Atila Neves wrote:

 I wouldn't do a PR until the outputs are exactly the same, I 
 posted this trying to gauge what the interest / opinions were.


Moving away from Makefiles to something like this definitely 
appeals to me (editing the makefiles is _not_ fun, and sadly, in 
spite of how bad it is, posix.mak is far less of a pain than 
win32.mak). However, as far as actually moving away from the 
Makefiles goes, you'd have to convince Walter and Andrei, and I 
don't know how convincible they are or aren't. And I don't think 
that we really want to have multiple ways to build the standard D 
toolchain, since then that increases maintenance to keep them in 
line with one another. So, if we have raggae builds (or anything 
like it) for the D toolchain, then I think that we need to fully 
move over to them and ditch the makefiles altogether.

- Jonathan M Davis
Jun 29 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
On Monday, 29 June 2015 at 16:52:34 UTC, Jonathan M Davis wrote:

 On Monday, 29 June 2015 at 12:06:39 UTC, Atila Neves wrote:

 I wouldn't do a PR until the outputs are exactly the same, I 
 posted this trying to gauge what the interest / opinions were.


 Moving away from Makefiles to something like this definitely 
 appeals to me (editing the makefiles is _not_ fun, and sadly, 
 in spite of how bad it is, posix.mak is far less of a pain than 
 win32.mak). However, as far as actually moving away from the 
 Makefiles goes, you'd have to convince Walter and Andrei, and I 
 don't know how convincible they are or aren't. And I don't 
 think that we really want to have multiple ways to build the 
 standard D toolchain, since then that increases maintenance to 
 keep them in line with one another. So, if we have raggae 
 builds (or anything like it) for the D toolchain, then I think 
 that we need to fully move over to them and ditch the makefiles 
 altogether.

 - Jonathan M Davis


Well, yes, the idea would be to ultimately move away from the 
current makefiles (all 3 of them). And yes, that would mean 
convincing the big two. But I had to show how it'd look like 
first instead of just saying "we should get rid of the 
makefiles". The idea behind adding the file if a PR is ever 
approved is so enough people use it and find any other lurking 
bugs. Once proven to work, the switch would be made.

Even if it never happens, this exercise has only ironed out bugs 
for reggae so it was still worthwhile.

Atila
Jun 29 2015
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Monday, 29 June 2015 at 10:35:34 UTC, Atila Neves wrote:

 Worth making a PR for? The PR would only add this file, it 
 wouldn't change anything about the current build, but could be 
 used for testing purposes in the meanwhile.


Yes, those who want reggae can use it, and the makefile can 
remain the default for now.  I can't wait to ditch the makefiles.


 Oh, and given the manual filtering in the config, it obviously 
 won't work on Mac OS. I have to get a hold of a Mac and make it 
 work there too. Then... Windows.


You could probably use the auto-tester to test reggae: simply add 
the reggae source to your PR, build it with a patched makefile, 
and then use reggae to build druntime/phobos.  I've used the 
auto-tester to test a couple PRs for various OSs that I don't 
have, especially OS X.
Jun 29 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Monday, 29 June 2015 at 16:05:07 UTC, Joakim wrote:

 On Monday, 29 June 2015 at 10:35:34 UTC, Atila Neves wrote:

 Worth making a PR for? The PR would only add this file, it 
 wouldn't change anything about the current build, but could be 
 used for testing purposes in the meanwhile.


 Yes, those who want reggae can use it, and the makefile can 
 remain the default for now.  I can't wait to ditch the 
 makefiles.


 Oh, and given the manual filtering in the config, it obviously 
 won't work on Mac OS. I have to get a hold of a Mac and make 
 it work there too. Then... Windows.


 You could probably use the auto-tester to test reggae: simply 
 add the reggae source to your PR, build it with a patched 
 makefile, and then use reggae to build druntime/phobos.  I've 
 used the auto-tester to test a couple PRs for various OSs that 
 I don't have, especially OS X.


You mean make a posix.mak that actually calls reggae instead? 
Hmm... I guess that's doable. Otherwise I'd have to edit the 
script the auto-tester is using.

I'm not sure that'd guarantee the same output though.

Atila
Jun 29 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Monday, 29 June 2015 at 18:59:31 UTC, Atila Neves wrote:

 On Monday, 29 June 2015 at 16:05:07 UTC, Joakim wrote:

 On Monday, 29 June 2015 at 10:35:34 UTC, Atila Neves wrote:

 Worth making a PR for? The PR would only add this file, it 
 wouldn't change anything about the current build, but could 
 be used for testing purposes in the meanwhile.


 Yes, those who want reggae can use it, and the makefile can 
 remain the default for now.  I can't wait to ditch the 
 makefiles.


 Oh, and given the manual filtering in the config, it 
 obviously won't work on Mac OS. I have to get a hold of a Mac 
 and make it work there too. Then... Windows.


 You could probably use the auto-tester to test reggae: simply 
 add the reggae source to your PR, build it with a patched 
 makefile, and then use reggae to build druntime/phobos.  I've 
 used the auto-tester to test a couple PRs for various OSs that 
 I don't have, especially OS X.


 You mean make a posix.mak that actually calls reggae instead? 
 Hmm... I guess that's doable. Otherwise I'd have to edit the 
 script the auto-tester is using.


Yes, submit a PR that adds the reggae source and modifies the 
existing druntime or phobos posix.mak to build reggae, then runs 
reggae to build druntime/phobos, using the linked reggae file.  
Once you're sure it all works, you can delete the reggae source 
and the makefile modifications and simply submit the single 
reggae file that you know works, because you just tested it on 
the auto-tester.


 I'm not sure that'd guarantee the same output though.


If you follow the process above, I don't see why not.
Jun 29 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 30 June 2015 at 01:07:33 UTC, Joakim wrote:

 On Monday, 29 June 2015 at 18:59:31 UTC, Atila Neves wrote:

 On Monday, 29 June 2015 at 16:05:07 UTC, Joakim wrote:

 On Monday, 29 June 2015 at 10:35:34 UTC, Atila Neves wrote:

 [...]


 Yes, those who want reggae can use it, and the makefile can 
 remain the default for now.  I can't wait to ditch the 
 makefiles.


 [...]


 You could probably use the auto-tester to test reggae: simply 
 add the reggae source to your PR, build it with a patched 
 makefile, and then use reggae to build druntime/phobos.  I've 
 used the auto-tester to test a couple PRs for various OSs 
 that I don't have, especially OS X.


 You mean make a posix.mak that actually calls reggae instead? 
 Hmm... I guess that's doable. Otherwise I'd have to edit the 
 script the auto-tester is using.


 Yes, submit a PR that adds the reggae source and modifies the 
 existing druntime or phobos posix.mak to build reggae, then 
 runs reggae to build druntime/phobos, using the linked reggae 
 file.  Once you're sure it all works, you can delete the reggae 
 source and the makefile modifications and simply submit the 
 single reggae file that you know works, because you just tested 
 it on the auto-tester.


 I'm not sure that'd guarantee the same output though.


 If you follow the process above, I don't see why not.


Well, for instance my extra html files. If there's no explicit 
check (and there probably isn't) the auto-tester will be fine 
with it but the build isn't actually the same. Things... can 
happen. Maybe anything that doesn't break the auto-tester doesn't 
matter, it wouldn't be a crazy opinion to have.

Atila
Jun 30 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 29/06/15 12:35, Atila Neves wrote:


 https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d


One major advantage with this is that the files are not hard coded, 
still don't understand why they are in the makefiles.  I think in 
druntime every file is listed at least three times. When adding a new 
file, it's very easy to forget adding in all places.

-- 
/Jacob Carlborg
Jun 29 2015
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29-Jun-2015 13:35, Atila Neves wrote:
[snip]


 The result of all this (and many bug discoveries trying to copy
 posix.mak) is this:

 https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d

 It doesn't completely replicate the UT build with its shared library (I
 got lazy), but... right now it builds both static and shard phobos,
 creates the symlinks just like posix.mak, _and_ does both unit tests
 runs (debug and release), building the unit tests binaries in the
 process. Oh, and the html documentation too. I tested with the make,
 ninja and binary backends, and everything seems to work. I wouldn't be
 surprised if there are still bugs, especially with the binary backend.

 Worth making a PR for? The PR would only add this file, it wouldn't
 change anything about the current build, but could be used for testing
 purposes in the meanwhile.


Awesome! Since raggae has Makefile backend it seems to me that we may 
switch over to raggae and keep generated Makefiles as a transitional 
measure.

Ideally if reggae doesn't depend on Phobos/druntime (e.g. builds with 
-betterC switch) then Makefile has no use at all - builds are completely 
bootstrappable.


-- 
Dmitry Olshansky
Jun 29 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 29 June 2015 at 18:10:32 UTC, Dmitry Olshansky wrote:

 Ideally if reggae doesn't depend on Phobos/druntime (e.g. 
 builds with -betterC switch) then Makefile has no use at all - 
 builds are completely bootstrappable.


We already require valid install of previous release for 
bootstrapping because of DDMD. No reason to require -betterC - 
just getting reggae as a library into Phobos is enough.
Jun 29 2015
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29-Jun-2015 21:24, Dicebot wrote:

 On Monday, 29 June 2015 at 18:10:32 UTC, Dmitry Olshansky wrote:

 Ideally if reggae doesn't depend on Phobos/druntime (e.g. builds with
 -betterC switch) then Makefile has no use at all - builds are
 completely bootstrappable.


 We already require valid install of previous release for bootstrapping
 because of DDMD.


Yeah, forgot about that. It has all manner of nice side effects ;)


 No reason to require -betterC - just getting reggae as
 a library into Phobos is enough.


Hm, this might just work.

-- 
Dmitry Olshansky
Jun 29 2015
prev sibling parent "Mike" <none none.com> writes:
On Monday, 29 June 2015 at 18:24:23 UTC, Dicebot wrote:


 No reason to require -betterC - just getting reggae as a 
 library into Phobos is enough.


What are you thinking here?  std.build or std.make?

I think the plan was to put reggae in the Tools repository, but a 
library in Phobos that can simply be imported into an rdmd script 
is more appealing to me.

Mike
Jun 29 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Friday, 5 June 2015 at 15:03:27 UTC, Atila Neves wrote:

 On Friday, 5 June 2015 at 09:22:14 UTC, Jacob Carlborg wrote:

 BTW, why are some Linux specific files ignored?


 No clue, I just went with the output of `make -f posix.mak`. 
 It's the kind of thing that'd be more explicit if the build 
 description were in D. It was one of my questions in the 
 original post ;)


Oh, I can answer that, std.c.* has been deprecated:

https://github.com/D-Programming-Language/phobos/pull/2337

It is unused in phobos, so it doesn't need to be built.  It's 
only around for users who might still be employing it, giving 
them time to phase it out of their code.
Jun 05 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-06-06 05:52, Joakim wrote:


 Oh, I can answer that, std.c.* has been deprecated:

 https://github.com/D-Programming-Language/phobos/pull/2337

 It is unused in phobos, so it doesn't need to be built.  It's only
 around for users who might still be employing it, giving them time to
 phase it out of their code.


I see, make sense.

-- 
/Jacob Carlborg
Jun 06 2015