www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Wannabe contributor frustrations

reply =?UTF-8?B?TcOhcmNpbw==?= Martins <marcioapm gmail.com> writes:
I decided to try a couple ideas in druntime and followed this 
http://wiki.dlang.org/Starting_as_a_Contributor#Fetch_dmd_from_GitHub

Everything went fast and smooth - I have a custom built dmd 
version.
Bootstrapping and building dmd was suspiciously fast - took 
around 15 secs maybe, if I remember right,


I did my changes to druntime, rebuilt with make -f posix.mak

Compiled a test case with ../dmd/src/dmd test.d, but my changes 
were not reflected.

So, I double check I actually did recompile druntime and look for 
the output lib files, and immediately thought that it must be 
picking up the system include and lib paths instead of this 
development env.

I create a dmd.conf in ../dmd/src right next to my custom dmd 
binary, but still doesn't work.
I try again invoking ../dmd/src/dmd -conf=../dmd/src/dmd.conf but 
still nothing.
I try passing the -I and -L arguments in the command line but 
still it is not using my custom druntime.

At this point I flip the table and give up - what could I be 
doing wrong?

My expectation was that given I followed the official "tutorial" 
closely, everything was going to just work, instead I spent about 
2 hours on this and got nowhere...

dmd should have a verbose mode where it outputs what it's trying 
to do and with which settings, so I could have a chance at seeing 
what I have messed up, and what linker command it is invoking, 
... as it is, I felt totally in the dark, and that just adds to 
the frustration.

I am on Ubuntu 15 and got a system-wide dmd installed from the 
official .deb package.
Feb 10 2016
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Wed, 10 Feb 2016 23:30:03 +0000, Márcio Martins wrote:


 So, I double check I actually did recompile druntime and look for the
 output lib files, and immediately thought that it must be picking up the
 system include and lib paths instead of this development env.


I'm working on druntime stuff now, and I'm about to run into the same 
issue.

I notice that the dmd 2.070 package does not contain libdruntime. I 
presume it's rolled into libphobos. And I notice that the phobos makefile 
references "../druntime". Try building phobos as well and see how that 
works?
Feb 10 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 2/10/16 6:40 PM, Chris Wright wrote:

 On Wed, 10 Feb 2016 23:30:03 +0000, Márcio Martins wrote:


 So, I double check I actually did recompile druntime and look for the
 output lib files, and immediately thought that it must be picking up the
 system include and lib paths instead of this development env.


 I'm working on druntime stuff now, and I'm about to run into the same
 issue.

 I notice that the dmd 2.070 package does not contain libdruntime. I
 presume it's rolled into libphobos. And I notice that the phobos makefile
 references "../druntime". Try building phobos as well and see how that
 works?


Psst! libdruntime was never used.

It was always used as compiled in phobos. I don't know why it was ever 
included.

-Steve
Feb 10 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins 
wrote:

 I did my changes to druntime, rebuilt with make -f posix.mak


You really need to build all three together to see changes 
effectively...

IMO it is a denial of reality to put them in three separate 
repositories since they are so strongly coupled in practice - 
their makefiles reference each other!


 I create a dmd.conf in ../dmd/src right next to my custom dmd 
 binary, but still doesn't work.


That shouldn't be necessary, but building phobos as well as your 
custom druntime probably is.



 dmd should have a verbose mode where it outputs what it's 
 trying to do and with which settings, so I could have a chance 
 at seeing what I have messed up, and what linker command it is


try `dmd -v`
Feb 10 2016
parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 11.2.2016 v 01:20 Adam D. Ruppe via Digitalmars-d napsal(a):

 On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins wrote:

 I did my changes to druntime, rebuilt with make -f posix.mak


 You really need to build all three together to see changes effectively...

 IMO it is a denial of reality to put them in three separate 
 repositories since they are so strongly coupled in practice - their 
 makefiles reference each other!


Yes, this is the main reason why I  does not do dmd and druntime 
development much often. I really hate when I try to bisect regressions.
Separate repositories make this really annoying. This is one of thing 
where gdc developers makes better than ldc.
Feb 10 2016
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, 11 February 2016 at 06:57:39 UTC, Daniel Kozak wrote:

 Dne 11.2.2016 v 01:20 Adam D. Ruppe via Digitalmars-d napsal(a):

 IMO it is a denial of reality to put them in three separate 
 repositories since they are so strongly coupled in practice - 
 their makefiles reference each other!


 Yes, this is the main reason why I  does not do dmd and 
 druntime development much often. I really hate when I try to 
 bisect regressions.


That's what digger is for: https://github.com/CyberShadow/Digger

But yes, having everything in one repo would make some things 
easier.

- Jonathan M Davis
Feb 10 2016
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 11.2.2016 v 08:23 Jonathan M Davis via Digitalmars-d napsal(a):

 On Thursday, 11 February 2016 at 06:57:39 UTC, Daniel Kozak wrote:

 Dne 11.2.2016 v 01:20 Adam D. Ruppe via Digitalmars-d napsal(a):

 IMO it is a denial of reality to put them in three separate 
 repositories since they are so strongly coupled in practice - their 
 makefiles reference each other!


 Yes, this is the main reason why I  does not do dmd and druntime 
 development much often. I really hate when I try to bisect regressions.


 That's what digger is for: https://github.com/CyberShadow/Digger

 But yes, having everything in one repo would make some things easier.

 - Jonathan M Davis


Yeah I know it there is a some tool, but I can not find it last time. I 
just find dustmite and dvm. Thanks :)
Feb 10 2016
parent Edwin van Leeuwen <edder tkwsping.nl> writes:
On Thursday, 11 February 2016 at 07:31:10 UTC, Daniel Kozak wrote:

 Dne 11.2.2016 v 08:23 Jonathan M Davis via Digitalmars-d 
 napsal(a):

 On Thursday, 11 February 2016 at 06:57:39 UTC, Daniel Kozak 
 wrote:

 Dne 11.2.2016 v 01:20 Adam D. Ruppe via Digitalmars-d 
 napsal(a):

 IMO it is a denial of reality to put them in three separate 
 repositories since they are so strongly coupled in practice 
 - their makefiles reference each other!


 Yes, this is the main reason why I  does not do dmd and 
 druntime development much often. I really hate when I try to 
 bisect regressions.


 That's what digger is for: 
 https://github.com/CyberShadow/Digger

 - Jonathan M Davis


 Yeah I know it there is a some tool, but I can not find it last 
 time. I just find dustmite and dvm. Thanks :)


Maybe the wiki should explain how to use digger and have the more 
detailed explanation as an appendix: "the hard way".
Feb 11 2016
prev sibling parent reply =?UTF-8?B?TcOhcmNpbw==?= Martins <marcioapm gmail.com> writes:
On Thursday, 11 February 2016 at 07:23:26 UTC, Jonathan M Davis 
wrote:

 On Thursday, 11 February 2016 at 06:57:39 UTC, Daniel Kozak 
 wrote:

 Dne 11.2.2016 v 01:20 Adam D. Ruppe via Digitalmars-d 
 napsal(a):

 IMO it is a denial of reality to put them in three separate 
 repositories since they are so strongly coupled in practice - 
 their makefiles reference each other!


 Yes, this is the main reason why I  does not do dmd and 
 druntime development much often. I really hate when I try to 
 bisect regressions.


 That's what digger is for: https://github.com/CyberShadow/Digger

 But yes, having everything in one repo would make some things 
 easier.

 - Jonathan M Davis


Is there a practical reason why they are not in the same repo? It 
seems only logical to me that you'd grab everything at once since 
since they are always in sync anyways...

Thanks for the help guys! I will give it another spin when I have 
an opportunity again.

Meanwhile would be good to add a little note to the makefiles 
warning about this. Perhaps at the end of a build it could issue 
this a warning saying: "Note you need to build Phobos as well!"
Feb 11 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 11 February 2016 at 10:55:12 UTC, Márcio Martins 
wrote:

 Is there a practical reason why they are not in the same repo?


No, other than trying to put them into one would grind everything 
to a halt for a while and would probably cost us more than we'd 
win. (All pull requests would need to be recreated, for one, and 
a lot of tools will break.)
Feb 11 2016
parent reply =?UTF-8?B?TcOhcmNpbw==?= Martins <marcioapm gmail.com> writes:
On Thursday, 11 February 2016 at 11:47:23 UTC, Vladimir Panteleev 
wrote:

 On Thursday, 11 February 2016 at 10:55:12 UTC, Márcio Martins 
 wrote:

 Is there a practical reason why they are not in the same repo?


 No, other than trying to put them into one would grind 
 everything to a halt for a while and would probably cost us 
 more than we'd win. (All pull requests would need to be 
 recreated, for one, and a lot of tools will break.)


Would at having them as submodules of dmd ease everything?
They could be separate repos, but the makefiles would try to find 
them in the submodule location and if there, great, otherwise, 
keep business.

On a separate topic: are the official DMD releases compiled with 
the previous version of DMD or GDC? How does that work?
Feb 11 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 11 February 2016 at 12:08:53 UTC, Márcio Martins 
wrote:

 On Thursday, 11 February 2016 at 11:47:23 UTC, Vladimir 
 Panteleev wrote:

 On Thursday, 11 February 2016 at 10:55:12 UTC, Márcio Martins 
 wrote:

 Is there a practical reason why they are not in the same repo?


 No, other than trying to put them into one would grind 
 everything to a halt for a while and would probably cost us 
 more than we'd win. (All pull requests would need to be 
 recreated, for one, and a lot of tools will break.)


 Would at having them as submodules of dmd ease everything?
 They could be separate repos, but the makefiles would try to 
 find them in the submodule location and if there, great, 
 otherwise, keep business.


The makefiles already assume that all components are cloned in 
one repository (but this can be overridden with make variables).


 On a separate topic: are the official DMD releases compiled 
 with the previous version of DMD or GDC? How does that work?


Yes, with a previous DMD version. IIRC, there is a makefile 
target which downloads an older DMD, if necessary.
Feb 11 2016
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, 11 February 2016 at 12:59:52 UTC, Vladimir Panteleev 
wrote:

 On Thursday, 11 February 2016 at 12:08:53 UTC, Márcio Martins 
 wrote:

 On a separate topic: are the official DMD releases compiled 
 with the previous version of DMD or GDC? How does that work?


 Yes, with a previous DMD version. IIRC, there is a makefile 
 target which downloads an older DMD, if necessary.


IIRC, it uses 2.067 and will continue to do so until GDC and LDC 
have switched to using the D version of the frontend instead of 
the older, C++ version.

- Jonathan M Davis
Feb 11 2016
parent Daniel Murphy <yebbliesnospam gmail.com> writes:
On 12/02/2016 4:10 AM, Jonathan M Davis wrote:

 IIRC, it uses 2.067 and will continue to do so until GDC and LDC have
 switched to using the D version of the frontend instead of the older,
 C++ version.


Most likely we will stick with 2.067 until GDC and LDC both have 2.068 
releases.  There are a couple bugs in 2.067 that affect building DMD, 
but using it as a host compiler has been fairly painless so far and I 
don't think there's any huge motivation to bump it up.
Feb 12 2016
prev sibling next sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins 
wrote:

 dmd should have a verbose mode where it outputs what it's 
 trying to do and with which settings, so I could have a chance 
 at seeing what I have messed up, and what linker command it is 
 invoking, ... as it is, I felt totally in the dark, and that 
 just adds to the frustration.


The "-v" (verbose) option does this.

You can find a list of DMD options and such here: 
http://dlang.org/dmd-linux.html
Feb 10 2016
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Feb 10, 2016 at 11:30:03PM +0000, Márcio Martins via Digitalmars-d
wrote:

 I decided to try a couple ideas in druntime and followed this
 http://wiki.dlang.org/Starting_as_a_Contributor#Fetch_dmd_from_GitHub
 
 Everything went fast and smooth - I have a custom built dmd version.
 Bootstrapping and building dmd was suspiciously fast - took around 15
 secs maybe, if I remember right,
 
 
 I did my changes to druntime, rebuilt with make -f posix.mak
 
 Compiled a test case with ../dmd/src/dmd test.d, but my changes were
 not reflected.


Druntime is not linked to compiled programs by itself; it gets linked as
part of Phobos. So after making changes in druntime, you have to also
rebuild Phobos before you will see your changes reflected.


[...]

 dmd should have a verbose mode where it outputs what it's trying to do
 and with which settings, so I could have a chance at seeing what I
 have messed up, and what linker command it is invoking, ... as it is,
 I felt totally in the dark, and that just adds to the frustration.


[...]

You're looking for:

	dmd -v


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!
Feb 10 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/10/2016 4:45 PM, H. S. Teoh via Digitalmars-d wrote:

 dmd should have a verbose mode where it outputs what it's trying to do
 and with which settings, so I could have a chance at seeing what I
 have messed up, and what linker command it is invoking, ... as it is,
 I felt totally in the dark, and that just adds to the frustration.


 You're looking for:
 	dmd -v


http://dlang.org/dmd-windows.html#switch-v
Feb 10 2016
prev sibling next sibling parent reply Etienne <etcimon gmail.com> writes:
On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins 
wrote:

 My expectation was that given I followed the official 
 "tutorial" closely, everything was going to just work, instead 
 I spent about 2 hours on this and got nowhere...


It took me way more than 2 hours to grasp how this build process 
works. It wasn't until I had read through the whole source code 
actually.
Feb 10 2016
next sibling parent Anonymouse <asdf fdsa.nu> writes:
On Thursday, 11 February 2016 at 02:07:54 UTC, Etienne wrote:

 On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins 
 wrote:

 My expectation was that given I followed the official 
 "tutorial" closely, everything was going to just work, instead 
 I spent about 2 hours on this and got nowhere...


 It took me way more than 2 hours to grasp how this build 
 process works. It wasn't until I had read through the whole 
 source code actually.


"Use the source, Luke!"
Feb 10 2016
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, 11 February 2016 at 02:07:54 UTC, Etienne wrote:

 On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins 
 wrote:

 My expectation was that given I followed the official 
 "tutorial" closely, everything was going to just work, instead 
 I spent about 2 hours on this and got nowhere...


 It took me way more than 2 hours to grasp how this build 
 process works. It wasn't until I had read through the whole 
 source code actually.


It's also a pain to edit. It's been suggested several times that 
we change the build system (e.g. to use 
https://github.com/atilaneves/reggae), but IIRC, Walter and 
Andrei have generally been opposed to the idea of changing it. 
It's one of those things that frequent contributors have more or 
less sorted out and don't usually worry about much anymore (aside 
perhaps from the rare occasions when they need to edit the 
makefiles), whereas it definitely tends to bite folks who aren't 
familiar with it. And building the documentation is that much 
worse.

Personally, I'd love to see it changed to something more 
maintainable, but we'd  have to be sure that what we were 
switching to really was better. As it is, I wrote a program that 
I use to update the source and do builds on my machine so that 
building is semi-sane, and I suspect that other contributors have 
done similar.

- Jonathan M Davis
Feb 10 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 11 February 2016 at 04:37:39 UTC, Jonathan M Davis 
wrote:

 And building the documentation is that much worse.



I'm fixing that at least! My docs: 
http://dpldocs.info/experimental-docs/std.stdio.html

are built with a single simple command:

docs path/to/phobos

done. No need to install several repos of crap.
Feb 10 2016
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 11 February 2016 at 05:02:40 UTC, Adam D. Ruppe 
wrote:

 On Thursday, 11 February 2016 at 04:37:39 UTC, Jonathan M Davis 
 wrote:

 And building the documentation is that much worse.



 I'm fixing that at least! My docs: 
 http://dpldocs.info/experimental-docs/std.stdio.html

 are built with a single simple command:

 docs path/to/phobos

 done. No need to install several repos of crap.


Digger can do it in one command too, without any changes in the 
current build process.

Does your command also build the PDF, CHM and eBook?
Feb 11 2016
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 11 February 2016 at 11:49:35 UTC, Vladimir Panteleev 
wrote:

 Digger can do it in one command too, without any changes in the 
 current build process.


Yeah, digger is pretty cool.


 Does your command also build the PDF, CHM and eBook?


No, I see negative value in supporting these formats as part of 
the build and dropped them entirely.
Feb 11 2016
prev sibling parent Mengu <mengukagan gmail.com> writes:
On Thursday, 11 February 2016 at 05:02:40 UTC, Adam D. Ruppe 
wrote:

 On Thursday, 11 February 2016 at 04:37:39 UTC, Jonathan M Davis 
 wrote:

 And building the documentation is that much worse.



 I'm fixing that at least! My docs: 
 http://dpldocs.info/experimental-docs/std.stdio.html

 are built with a single simple command:

 docs path/to/phobos

 done. No need to install several repos of crap.


at the beginning i was opposing having alternative docs somewhere 
else but i get to like it. when reading phobos source number of 
wtfs i say is reducing with the help of your docs. thanks adam.
Feb 11 2016
prev sibling next sibling parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 11.2.2016 v 05:37 Jonathan M Davis via Digitalmars-d napsal(a):

 On Thursday, 11 February 2016 at 02:07:54 UTC, Etienne wrote:

 On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins wrote:

 My expectation was that given I followed the official "tutorial" 
 closely, everything was going to just work, instead I spent about 2 
 hours on this and got nowhere...


 It took me way more than 2 hours to grasp how this build process 
 works. It wasn't until I had read through the whole source code 
 actually.


 ...

 Personally, I'd love to see it changed to something more maintainable, 
 but we'd  have to be sure that what we were switching to really was 
 better.


   I think that anything would be better than what we have now :)


 - Jonathan M Davis
Feb 10 2016
prev sibling next sibling parent Daniel Murphy <yebbliesnospam gmail.com> writes:
On 11/02/2016 3:37 PM, Jonathan M Davis wrote:

 It's also a pain to edit. It's been suggested several times that we
 change the build system (e.g. to use
 https://github.com/atilaneves/reggae), but IIRC, Walter and Andrei have
 generally been opposed to the idea of changing it. It's one of those
 things that frequent contributors have more or less sorted out and don't
 usually worry about much anymore (aside perhaps from the rare occasions
 when they need to edit the makefiles), whereas it definitely tends to
 bite folks who aren't familiar with it. And building the documentation
 is that much worse.

 Personally, I'd love to see it changed to something more maintainable,
 but we'd  have to be sure that what we were switching to really was
 better. As it is, I wrote a program that I use to update the source and
 do builds on my machine so that building is semi-sane, and I suspect
 that other contributors have done similar.


There is a non-zero possibility that we'll switch to dub eventually.
Feb 11 2016
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 11 February 2016 at 04:37:39 UTC, Jonathan M Davis 
wrote:

 On Thursday, 11 February 2016 at 02:07:54 UTC, Etienne wrote:

 On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins 
 wrote:

 [...]


 It took me way more than 2 hours to grasp how this build 
 process works. It wasn't until I had read through the whole 
 source code actually.


 It's also a pain to edit. It's been suggested several times 
 that we change the build system (e.g. to use 
 https://github.com/atilaneves/reggae), but IIRC, Walter and 
 Andrei have generally been opposed to the idea of changing it. 
 It's one of those things that frequent contributors have more 
 or less sorted out and don't usually worry about much anymore 
 (aside perhaps from the rare occasions when they need to edit 
 the makefiles), whereas it definitely tends to bite folks who 
 aren't familiar with it. And building the documentation is that 
 much worse.


Tell me about it. I'm still not 100% sure what I need to do to 
build the docs and only managed the 1st time at DConf 2015 with 
Robert next to me telling me what to do.

Atila
Feb 11 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/16 9:08 AM, Atila Neves wrote:

 I'm still not 100% sure what I need to do to build the docs


Does 
http://wiki.dlang.org/Starting_as_a_Contributor#Fetch_and_build_dlang.org help? 
-- Andrei
Feb 11 2016
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/10/2016 6:07 PM, Etienne wrote:

 It took me way more than 2 hours to grasp how this build process works. It
 wasn't until I had read through the whole source code actually.


    "Use the Source, Luke" -- Unix Documentation
Feb 10 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/10/2016 6:07 PM, Etienne wrote:

 It took me way more than 2 hours to grasp how this build process works. It
 wasn't until I had read through the whole source code actually.


These are opportunities to improve things. If you could issue PRs to improve
the 
documentation at the pain points, it'll help the next traveler. Or at least
open 
a bugzilla issue for it.
Feb 10 2016
parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 11.2.2016 v 05:52 Walter Bright via Digitalmars-d napsal(a):

 On 2/10/2016 6:07 PM, Etienne wrote:

 It took me way more than 2 hours to grasp how this build process 
 works. It
 wasn't until I had read through the whole source code actually.


 These are opportunities to improve things. If you could issue PRs to 
 improve the documentation at the pain points, it'll help the next 
 traveler. Or at least open a bugzilla issue for it.


Documentation is only one part of problem. Every time when I want to 
contribute to D(dmd, druntime + phobos) it takes hours(days) of 
persuasion of myself.

Adding some new feature or fix something new is generaly easy (still it 
is useless hard), but when I want to find out regression it is really 
annoying and I often give up.
Feb 10 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/10/2016 11:18 PM, Daniel Kozak via Digitalmars-d wrote:

 Dne 11.2.2016 v 05:52 Walter Bright via Digitalmars-d napsal(a):

 On 2/10/2016 6:07 PM, Etienne wrote:

 It took me way more than 2 hours to grasp how this build process works. It
 wasn't until I had read through the whole source code actually.


 These are opportunities to improve things. If you could issue PRs to improve
 the documentation at the pain points, it'll help the next traveler. Or at
 least open a bugzilla issue for it.


 Documentation is only one part of problem.


Improving any part of the problem is good progress.
Feb 11 2016
parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 11.2.2016 v 09:44 Walter Bright via Digitalmars-d napsal(a):

 On 2/10/2016 11:18 PM, Daniel Kozak via Digitalmars-d wrote:

 Dne 11.2.2016 v 05:52 Walter Bright via Digitalmars-d napsal(a):

 On 2/10/2016 6:07 PM, Etienne wrote:

 It took me way more than 2 hours to grasp how this build process 
 works. It
 wasn't until I had read through the whole source code actually.


 These are opportunities to improve things. If you could issue PRs to 
 improve
 the documentation at the pain points, it'll help the next traveler. 
 Or at
 least open a bugzilla issue for it.


 Documentation is only one part of problem.


 Improving any part of the problem is good progress.


Yes, I agree :)
Feb 11 2016
prev sibling next sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins 
wrote:

 I decided to try a couple ideas in druntime and followed this 
 http://wiki.dlang.org/Starting_as_a_Contributor#Fetch_dmd_from_GitHub

 Everything went fast and smooth - I have a custom built dmd 
 version.
 Bootstrapping and building dmd was suspiciously fast - took 
 around 15 secs maybe, if I remember right,


 I did my changes to druntime, rebuilt with make -f posix.mak

 Compiled a test case with ../dmd/src/dmd test.d, but my changes 
 were not reflected.

 So, I double check I actually did recompile druntime and look 
 for the output lib files, and immediately thought that it must 
 be picking up the system include and lib paths instead of this 
 development env.

 I create a dmd.conf in ../dmd/src right next to my custom dmd 
 binary, but still doesn't work.
 I try again invoking ../dmd/src/dmd -conf=../dmd/src/dmd.conf 
 but still nothing.
 I try passing the -I and -L arguments in the command line but 
 still it is not using my custom druntime.

 At this point I flip the table and give up - what could I be 
 doing wrong?

 My expectation was that given I followed the official 
 "tutorial" closely, everything was going to just work, instead 
 I spent about 2 hours on this and got nowhere...

 dmd should have a verbose mode where it outputs what it's 
 trying to do and with which settings, so I could have a chance 
 at seeing what I have messed up, and what linker command it is 
 invoking, ... as it is, I felt totally in the dark, and that 
 just adds to the frustration.

 I am on Ubuntu 15 and got a system-wide dmd installed from the 
 official .deb package.


When you figure it out maybe you could draft a clear explanation 
of whats missing from the existing wiki instructions to append as 
a set of hints and tips.

One of the biggest problems with explaining things is that it's 
hard to remember what it was like not to know something, and so 
experts can often be terrible at explaining things because it 
seems obvious (and as Ray Charles said, everything is easy when 
you know how to do it).
Feb 10 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 11 February 2016 at 04:48:31 UTC, Laeeth Isharc 
wrote:

 (and as Ray Charles said, everything is easy when you know how 
 to do it).


Not the case here: even when you know how to use the D build 
system, it still sucks and is very hard to use. The PR review 
team has let wrong things go past several times because it is so 
convoluted.
Feb 10 2016
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Thursday, 11 February 2016 at 04:48:31 UTC, Laeeth Isharc 
wrote:

 On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins 
 wrote:

 [...]


 When you figure it out maybe you could draft a clear 
 explanation of whats missing from the existing wiki 
 instructions to append as a set of hints and tips.


Updating the wiki is good, but not nearly as important as a 
command you run that just works.

Atila
Feb 11 2016
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/10/16 6:30 PM, Márcio Martins wrote:

 I decided to try a couple ideas in druntime and followed this
 http://wiki.dlang.org/Starting_as_a_Contributor#Fetch_dmd_from_GitHub

 Everything went fast and smooth - I have a custom built dmd version.
 Bootstrapping and building dmd was suspiciously fast - took around 15
 secs maybe, if I remember right,


 I did my changes to druntime, rebuilt with make -f posix.mak

 Compiled a test case with ../dmd/src/dmd test.d, but my changes were not
 reflected.

 So, I double check I actually did recompile druntime and look for the
 output lib files, and immediately thought that it must be picking up the
 system include and lib paths instead of this development env.

 I create a dmd.conf in ../dmd/src right next to my custom dmd binary,
 but still doesn't work.
 I try again invoking ../dmd/src/dmd -conf=../dmd/src/dmd.conf but still
 nothing.
 I try passing the -I and -L arguments in the command line but still it
 is not using my custom druntime.

 At this point I flip the table and give up - what could I be doing wrong?

 My expectation was that given I followed the official "tutorial"
 closely, everything was going to just work, instead I spent about 2
 hours on this and got nowhere...

 dmd should have a verbose mode where it outputs what it's trying to do
 and with which settings, so I could have a chance at seeing what I have
 messed up, and what linker command it is invoking, ... as it is, I felt
 totally in the dark, and that just adds to the frustration.

 I am on Ubuntu 15 and got a system-wide dmd installed from the official
 .deb package.


Hi Márcio, thanks for reaching out. You actually did everything right 
and you succeeded. The only thing missing is a misunderstanding that 
I'll fix in the document.

That page is meant for folks who want to change dmd, phobos, or 
druntime. With your setup, if you make a change to druntime and rebuild 
it (and phobos), the change _will_ be reflected properly. E.g. put an 
assert(0); in some unittest and see it failing. This is because all 
paths to dmd, druntime, phobos are set up properly in the makefiles.

However, when you tried to compile some independent program outside 
these, indeed your system defaults entered in action. You need a 
different command line for those, which I'll specify in 
http://wiki.dlang.org/Starting_as_a_Contributor.


Thanks,

Andrei
Feb 11 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/10/16 6:30 PM, Márcio Martins wrote:

 I decided to try a couple ideas in druntime and followed this
 http://wiki.dlang.org/Starting_as_a_Contributor#Fetch_dmd_from_GitHub


OK, I added this section: 
http://wiki.dlang.org/Starting_as_a_Contributor#Running_Independent_Programs

Please let me know if it floats your boat. Thanks!


Andrei
Feb 11 2016
parent =?UTF-8?B?TcOhcmNpbw==?= Martins <marcioapm gmail.com> writes:
On Thursday, 11 February 2016 at 14:19:13 UTC, Andrei 
Alexandrescu wrote:

 On 2/10/16 6:30 PM, Márcio Martins wrote:

 I decided to try a couple ideas in druntime and followed this
 http://wiki.dlang.org/Starting_as_a_Contributor#Fetch_dmd_from_GitHub


 OK, I added this section: 
 http://wiki.dlang.org/Starting_as_a_Contributor#Running_Independent_Programs

 Please let me know if it floats your boat. Thanks!


 Andrei


Great, thanks Andrei!

Here is my first contribution: 
https://github.com/D-Programming-Language/druntime/pull/1497

Go ahead and destroy!
Feb 11 2016