(Maybe this should be in D.learn but it's a somewhat advanced
topic)
I would really like to understand how D compiles a program or
library. I looked through TDPL and it doesn't seem to say
anything about how compilation works.
- Does it compile all source files in a project at once?
- Does t
On Wed, 25 Jul 2012 02:16:04 +0200
"David Piepgrass" wrote:
> (Maybe this should be in D.learn but it's a somewhat advanced
> topic)
>
> I would really like to understand how D compiles a program or
> library. I looked through TDPL and it doesn't seem to say
> anything about how compilation w
On Tuesday, July 24, 2012 22:00:56 Nick Sabalausky wrote:
> But with D, you get a HUGE boost in compilation speed by
> not compiling one-at-a-time. So if you have a huge, slow-to-compile
> codebase (for example, 15 seconds or so),
I find it shocking that anyone would consider 15 seconds slow to co
On Tue, 24 Jul 2012 20:35:27 -0700
Jonathan M Davis wrote:
> On Tuesday, July 24, 2012 22:00:56 Nick Sabalausky wrote:
> > But with D, you get a HUGE boost in compilation speed by
> > not compiling one-at-a-time. So if you have a huge, slow-to-compile
> > codebase (for example, 15 seconds or so),
On 2012-07-25 04:00, Nick Sabalausky wrote:
But that's just the DMD compiler itself. Instead of using DMD
directly, there's a better modern trick that's generally preferred:
RDMD.
If you use rdmd to compile (instead of dmd), you *just* give it
your *one* main source file (typically the one with
On Tue, 2012-07-24 at 20:35 -0700, Jonathan M Davis wrote:
[…]
> I find it shocking that anyone would consider 15 seconds slow to compile for
> a
> large program. Yes, D's builds are lightning fast in general, and 15 seconds
> is probably a longer build, but calling 15 seconds "slow-to-compile"
On Wednesday, July 25, 2012 08:54:24 Russel Winder wrote:
> On Tue, 2012-07-24 at 20:35 -0700, Jonathan M Davis wrote:
> […]
>
> > I find it shocking that anyone would consider 15 seconds slow to compile
> > for a large program. Yes, D's builds are lightning fast in general, and
> > 15 seconds is
On Wed, 25 Jul 2012 08:54:24 +0100
Russel Winder wrote:
> On Tue, 2012-07-24 at 20:35 -0700, Jonathan M Davis wrote:
> […]
> > I find it shocking that anyone would consider 15 seconds slow to
> > compile for a large program. Yes, D's builds are lightning fast in
> > general, and 15 seconds is pro
On 7/25/12, Jonathan M Davis wrote:
> I find it shocking that anyone would consider 15 seconds slow to compile for
> a large program.
It's not shocking if you're used to a fast edit-compile-run cycle
which takes a few seconds and then starts to slow down considerably
when you involve more and mor
I find it shocking that anyone would consider 15 seconds slow
to compile for a
large program. Yes, D's builds are lightning fast in general,
and 15 seconds
is probably a longer build, but calling 15 seconds
"slow-to-compile" just
about blows my mind. 15 seconds for a large program is _fast_.
On Wednesday, July 25, 2012 17:35:09 David Piepgrass wrote:
> > I find it shocking that anyone would consider 15 seconds slow
> > to compile for a
> > large program. Yes, D's builds are lightning fast in general,
> > and 15 seconds
> > is probably a longer build, but calling 15 seconds
> > "slow-to
On Wednesday, July 25, 2012 14:57:23 Andrej Mitrovic wrote:
> Hell I can't believe how outdated the compiler technology is. I can
> play incredibly realistic and interactive 3D games in real-time with
> practically no input lag, but I have to wait a dozen seconds for a
> tool to convert lines of te
Thanks for the very good description, Nick! So if I understand
correctly, if
1. I use an "auto" return value or suchlike in a module Y.d
2. module X.d calls this function
3. I call "dmd -c X.d" and "dmd -c Y.d" as separate steps
Then the compiler will have to fully parse Y twice and fully
anal
On Wednesday, 25 July 2012 at 19:54:31 UTC, David Piepgrass wrote:
It keeps diving deeper and deeper to find anything it can
"start" with.
One it finds that, it'll just build everything back up in
whatever
order is necessary.
I hope someone can give more details about this.
TDPL chapter 11
If you use rdmd to compile (instead of dmd), you *just* give it
your *one* main source file (typically the one with your
"main()"
function). This file must be the *last* parameter passed to
rdmd:
$rdmd --build-only (any other flags) main.d
Then, RDMD will figure out *all* of the source files
I hope someone can give more details about this.
TDPL chapter 11 "Scaling Up".
That's where I was looking. As I said already, TDPL does not
explain how compilation works, especially not anything about the
low-level semantic analysis which has me most curious.
On Wednesday, 25 July 2012 at 20:25:19 UTC, David Piepgrass wrote:
I hope someone can give more details about this.
TDPL chapter 11 "Scaling Up".
That's where I was looking. As I said already, TDPL does not
explain how compilation works, especially not anything about
the low-level semantic
On Wednesday, 25 July 2012 at 08:06:23 UTC, Nick Sabalausky wrote:
Yea, my understanding is that full-build times measured in days
are (or
used to be, don't know if they still are) also typical of
high-budget
C++-based videogames.
You must be thinking of full data rebuilds, not code recompile
On Wed, 25 Jul 2012 23:20:04 +0200
"Peter Alexander" wrote:
> On Wednesday, 25 July 2012 at 08:06:23 UTC, Nick Sabalausky wrote:
> > Yea, my understanding is that full-build times measured in days
> > are (or
> > used to be, don't know if they still are) also typical of
> > high-budget
> > C++-
On Wed, 25 Jul 2012 22:18:37 +0200
"David Piepgrass" wrote:
>
> I meant to ask, why would it recompile *all* of the source files
> if only one changed? Seems like it only should recompile the
> changed ones (but still compile them together as a unit.) Is it
> because of bugs (e.g. the template
On Wed, 25 Jul 2012 21:54:29 +0200
"David Piepgrass" wrote:
> Thanks for the very good description, Nick! So if I understand
> correctly, if
>
> 1. I use an "auto" return value or suchlike in a module Y.d
> 2. module X.d calls this function
> 3. I call "dmd -c X.d" and "dmd -c Y.d" as separate
On 2012-07-25 17:35, David Piepgrass wrote:
Plus, it isn't just build times that concern me. In C# I'm used to
having an IDE that immediately understands what I have typed, giving me
error messages and keeping metadata about the program up-to-date within
2 seconds. I can edit a class definition
On 2012-07-25 21:54, David Piepgrass wrote:
Thanks for the very good description, Nick! So if I understand
correctly, if
1. I use an "auto" return value or suchlike in a module Y.d
2. module X.d calls this function
3. I call "dmd -c X.d" and "dmd -c Y.d" as separate steps
Then the compiler will
On Wed, 2012-07-25 at 01:03 -0700, Jonathan M Davis wrote:
[…]
> I've heard of overnight builds, and I've heard of _regression tests_ running
> for over a week, but I've never heard of builds being over 2 days. Ouch.
Indeed the full test suite did take about a week to run. I think the
core proble
On Thu, 26 Jul 2012 09:27:03 +0100
Russel Winder wrote:
> On Wed, 2012-07-25 at 01:03 -0700, Jonathan M Davis wrote:
>
> > In any case, much as I like C++ (not as much as D, but I still like
> > it quite a bit), its build times are undeniably horrible.
>
> Indeed, especially with -O2 or -O3.
>
25 matches
Mail list logo
