On 09/20/2018 07:13 PM, aliak wrote:
On a related note: He also mentions some really cool compilation
features like having compiler hooks that tell you when compilation is
done, when executable and where it will be written so you can create
your build recipe inside the program itself. Also allows you do do
things like:
whenCompilationFinishes(exeLocation) => loadExecutableIcon(myIcon,
exeLocation)
During the build!
Your source knows how to build itself as a concept is awesome! There's
actually a D runner [1] that kind of allows for source files to set
stuff up.
[0] https://www.youtube.com/watch?v=uZgbKrDEzAs
[1] https://github.com/marler8997/rund
Just watched that part of the video. It sounds like it really just boils
down to these three things:
1. He did away with C/C++'s awful header system, just like every other
language out there.
(It's a good thing, but it's also a bare minimum expectation in ANY
language that isn't C or C++. Yawn.)
2. He created a standard (and presumably mandatory) build tool to go
along with his language, but is avoiding *calling* it a build
tool...even though it's clearly just a build tool that happens to be
built into the compiler.
(I've already used a language that did that: Haxe. There are definitely
some nice things about it, but the problem is: What happens when the
official buildsystem doesn't fit your needs? Your pretty much SOL. Just
imagine if DUB was the ONLY way to compile D and you get the picture of
why this isn't as great as it sounds. And even if his compiler DOES let
you opt-out of the official built-in buildsystem, it's ultimately still
just yet another buildsystem, nothing inherently special or new except
for...)
3. You can embed your buildscript into one of your project's existing
source files, instead of putting it in a dedicated buildscript file.
(We can do that in D too, by utilizing version identifiers, but we don't
because its messy and mostly pointless. Just like you wouldn't put your
graphics code in an XML-parsing module, or your JSON serializer in an
audio-mixing module. They each get their own file or dir. Basic
separation of concerns. For one-file scripts, this IS actually really,
really nice though, which is why I like both rund and DUB's embedded
dub.sdl. But aside from one-file scripts, there's not much point to
avoiding basic separation-of-concerns.)
