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?




Reply via email to