Snapping LDC (LLVM-based D compiler)

[Mark Shuttleworth]

On 27/08/16 16:45, Joseph Rushton Wakeling wrote:
> It's been very exciting to see how straightforward most things are to
> get set up,

Yeah, it's been fun here too working on a few holiday snaps :)

> but I ran into a few issues that are blockers to finalizing the snap,
> so I thought I'd ask here for advice on how to address them.
>
> [snip]
>
> This happily builds and generates a snap, and so far as I can tell
> from the install, all the usual required files are there.  (By the
> way, I really do mean to have ldc in the `build-packages`; LDC now
> requires a D compiler to build it, so it's necessary to have the older
> ubuntu-packaged ldc 0.17.1 to build with.)
>
> The problems with the snap are threefold:
>
>   * LDC creates two different executables, ldc2 and ldmd2 (the latter
> is a
>     wrapper that implements compiler flags to match D's reference
> compiler,
>     "Digital Mars D" or dmd).  However, the names given to the snap
> executables
>     are ldc.ldc2 and ldc.ldmd2.  While I understand the wish to
> namespace, is
>     there any way to drop the `ldc.` prefix ... ?

We would like to add the ability to have a single snap offer up multiple
base-level commands. This will require some changes to snapd, if you are
comfortable writing code in Go then feel free to take this on as a
challenge :) Niemeyer or MVO on IRC would be able to give you some
implementation strategy ideas.

For now, if you have a command with the same name as your snap, then
that one can drop the namespacing. So if your one command was "ldc" then
you would not need ldc.ldc you could have just ldc.


>   * LDC creates a config file, `/etc/ldc2.conf`, using libconfig. 
> This defines
>     some default compiler flags, including the default 'include'
> location of
>     header files for the runtime and standard library.  However,
> perhaps because
>     of how the snap is built, the include paths are specified as if
> the snap's
>     install dir was the root:
>
>         switches = [
>             "-I/include/d/ldc",
>             "-I/include/d",
>             "-L-L/lib",
>             "-defaultlib=phobos2-ldc,druntime-ldc",
>             "-debuglib=phobos2-ldc-debug,druntime-ldc-debug"
>         ];
>
>     This means that when one tries to compile anything, the compiler
> emits
>     error messages that it is unable to locate the headers for runtime or
>     standard-library modules.  If one manually specifies the full-path
>     include locations:
>
>         -I/snap/ldc/current/include/d/ldc -I/snap/ldc/current/include/d
>
>     ... then the compiler can build an object file, but runs into the
> third
>     of the problems ...


Not sure here, I think someone closer to the mechanics of snap paths can
help.


>
>   * LDC uses the default C compiler for linking, but the snap-installed
>     compiler fails to find it, exiting with a message:
>
>         Error: failed to locate gcc
>

The easy way to fix this is to bundle the linker. The slightly longer
way is to arrange for an interface that gets you a linker command. Bear
in mind that in Ubuntu Core environments you don't have apt-get to bring
in things like that to the base OS, you only have the core snap which is
minimal and definitely doesn't have the compiler :) If you depend on a
compiler outside, you will only work in places where someone has
provided that. My suggestion would be to add the linker to your snap,
which gets you unblocked at the price of a fatter snap. Then if you feel
inspired go about getting the linker interface set up, in such a way
that it can work first on classic systems which happen to have gcc, and
then even on all-snap core systems where the linker might be another snap.

> Can anyone advise on how best to address any of these problems?  I
> would assume the last in particular is down to the lack of an
> interface for access to things like a linker or other aspects of a
> build system? 

2 out of 3 ain't bad :)

Nicely done and welcome aboard!

Mark