On Sunday, 25 November 2018 at 22:00:21 UTC, Chris Katko wrote:
So 1) I have to compile manually, then link. Except that also
runs the files every time even if they're up-to-date. Is that
normal behavior for C/C++?
Yes, C and C++ compilers behave the same way.
#1 How to I only build files that are dirty? Do I actually need
a build program like DUB, MAKE, or CMAKE to do that? (Can make,
cmake be used?) How do they recognize files are out-dated if
DMD can't? Is that just an industry-standard
specialization/separation-of-responsibilities to not have the
compiler auto-detect up-to-date builds?
cmake doesn't actually build anything. It generates make files or
IDE project files. I don't know if DUB currently has an option to
build only dirty files. Make does it by default.
To do something like that requires looking for a source file's
corresponding object file in the output directory and only
compiling the source if the object file doesn't exist or if it
has an older timestamp.
But consider what happens when you change the command line
options, say enable a version on a build that wasn't enabled
earlier. With make, you have to run `make clean` first, otherwise
only dirty files will get the new options. It doesn't track build
options per file from run to run. What should the compiler do?
Have a -clean command line switch? Maintain a database of command
line options per file? That's the realm of build systems. The
compiler just compiles.
I've heard "just use dub" but I've also heard that dub have
flaws/gotchas that I can't remember when it comes to say,
dynamic linking DLLs/SOs. So I've been hesitant to learn it.
DUB is easy. I've been using it for years and I do full
compilation of every file on every invocation in a
code->build->run cycle. Some aren't happy with it because it
doesn't support some of the things they want to use it for, but
it has plenty of satisfied users. I'm unaware of any gotchas
about linking shared libraries.
#2 I ran individual file times. They're pretty shocking.
-------------------------------------------------------
I have to tell you that, as an outsider (who is VERY interested
in D), this is very frustrating. "Compile times are fast" !=
"build times" is a huge misconception that borders on being a
clever lie or twisting of words. When people hear "compile
times", they think "time to compile the whole project" not
"time to compile a simple test case that doesn't use any
typical D features--also, it's not linking." Second, as shown
here, it's not fast even for compiling! Because the second you
touch std.regex (which has NO WARNINGS in the documentation),
you're greeted with another clever lie-by-omission: a 10x
explosion of build time over some modules.
Now let's stop for a moment. I'm not accusing anyone, and "lie"
is a strong word with heavy guilt implications--like people are
intentionally being very sneaky to deceive new-comers. I'm not
saying any of that, so you can relax and put down the
pitchfork. I'm not attacking you or your group personally.
However, I can't think of any better word.
So my point is, I keep running into either misconceptions that
conveniently make D look good, and other gotchas with NO
DOCUMENTATION that make the language much slower to work with
than expected.
There is no misleading or misconception or lying or misdirection
here. DMD has fast compile times. Heavily templated code is going
to slow it down, but if you compile the same sort of heavily
templated code in C++, you'll get slow downs there as well. And
in your case, you'll find that if you add many more files to your
project and they aren't heavily templated, the increase in build
time will be very small.
If someone can dig into the compilers and optimize how templates
are handled, they might be able to shave a bit of time off, but
when you are using a code base that does a lot of work at compile
time, then there's no avoiding increasing the length of that
compile time.
But that by no means is the same as saying it's not fast, because
overall compile times in D are still fast.
I mean, can you think of any module in the Python/Javascript/C#
standard library that simply including it will swell your
program to the point it can't compile? I'm not an omnipotent
master programmer, but as a professional, I can't recall ever
having this situation in another library or language.
Have you reached the point in D where you can't compile?
