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