D-lighted, I'm Sure

[Jacob Carlborg]

On 2019-01-18 15:29, Mike Parker wrote:
> Not long ago, in my retrospective on the D Blog in 2018, I invited folks 
> to write about their first impressions of D. Ron Tarrant, who you may 
> have seen in the Lear forum, answered the call. The result is the latest 
> post on the blog, the first guest post of 2019. Thanks, Ron!
> 
> The blog:
> https://dlang.org/blog/2019/01/18/d-lighted-im-sure/

Regarding Dub. If you only have a project without any dependencies or 
perhaps only system dependencies already available on the system it 
might not add that much. But as soon as you want to use someone else D 
code it helps tremendously. Dub both acts as a build tool and a package 
manager. It will automatically download the source code for the 
dependencies, build them and handle the imports paths. As for JSON 
files, it's possible to use the alternative format SDL. One extremely 
valuable feature this has over JSON is that it supports comments.

To address some of the direct questions in the blog post:

"information about how I would go about packaging a D app (with GtkD) 
for distribution".

When it comes to distribution D applications there isn't much that is 
specific to D. Most of the approaches and documentation that applies to 
any native language would apply to D as well. There are two D specific 
things (that I can think of for now) that are worth mentioning:

* When you compile a release build for distribution, use the LDC [1] 
compiler. It produces better code. You can also add things like LTO 
(Link Time Optimization) and possibly PGO (Profile Guided Optimization).

* If you have any static assets for you application, like images, sound 
videos, config files or similar, it's possible to embed those directly 
in the executable using the "import expression" [2] feature. This will 
read a file, at compile time, into a string literal inside the code.

Some more general things about distribution. I think it's more platform 
specific than language specific. I can only speak for macOS (since 
that's the main platform I use). There it's expected to have the 
application distributed as a disk image (DMG). This image would contain 
an application bundle. An application bundle is a regular directory with 
the ".app" extension with a specific directory and file structure. Some 
applications in the OS treats these bundles specially. For example, 
double clicking on this bundle in the file browser will launch the 
application. The bundle will contain the actual executable and and 
resources like libraries and assets like images and audio. In your case, 
don't expect a Mac user to have GTK installed, bundle that in the 
application bundle.

Then there's the issue of which versions of the platforms you want to 
support. For macOS it's possible to specify a minimum deployment target 
using the "MACOSX_DEPLOYMENT_TARGET" environment variable. This allows 
to build the application on the latest version of the OS but still have 
the application work on older versions.

On *BSD and Linux it's not that easy and Linux has the additional axis 
of distros which adds another level of issues. The best is to compile 
for each distro and version you want to support, but that's a lot of 
work. I would provide fully statically linked binaries, including 
statically linked to the C standard library. This way to can provide one 
binary for all version of and distros of Linux and you know it will 
always work.

"how to build on one platform for distribution on another (if that’s 
even possible)"

I can say that it's possible, but unless you're targeting a platform 
that doesn't provide a compiler, like mobile or an embedded platform, I 
think it's rare to need to cross-compile. I'll tell you way:

When building an application that targets multiple platforms you would 
need to test it at some point. That means running the application on all 
the supported platforms. That means you need to have access to these 
platforms. Usually a lot in the beginning when developing the 
application and in the end when doing final verification before a release.

Having said that, I'm all for automating as much as possible. That means 
automatically running all the tests and building the final release build 
and packing for distribution. For that I recommend hooking up you're 
project to one of the publicly available and free CI services. Travis CI 
[3] is one of them that supports Linux, macOS and Windows (early release 
[4]). AppVeyor is an alternative that has a much more mature support for 
Windows.

If you really want to cross-compile, it's possible if you use LDC. DMD 
can compile for the same platform for either 32 bit or 64 bit, but not 
for a different platform. I think it's simplest to use Docker. I have 
two Docker files for a container containing LDC setup for 
cross-compiling to macOS [6] and for Windows [7]. Unfortunately these 
Docker files pulls down the SDKs from someones (not mine) Dropbox account.

[1] https://github.com/ldc-developers/ldc
[2] https://dlang.org/spec/expression.html#import_expressions
[3] https://travis-ci.com/
[4] https://blog.travis-ci.com/2018-10-11-windows-early-release
[5] https://www.appveyor.com
[6] 
https://github.com/jacob-carlborg/docker-ldc-darwin/blob/master/Dockerfile
[7] 
https://github.com/jacob-carlborg/docker-ldc-windows/blob/master/Dockerfile

-- 
/Jacob Carlborg