Snapping LDC (LLVM-based D compiler)

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Sat Aug 27 20:45:55 UTC 2016


Hello all,

I thought I'd have a go at making a snap of LDC, the LLVM-based compiler for the 
D programming language.  I recognize that snapping a compiler might be jumping 
ahead of the current intended use-case(s), but it's fun to see what could be 
possible -- and besides, D's compilers are updated fairly often, so it would be 
great to be able to package them easily in a truly cross-distro form.

It's been very exciting to see how straightforward most things are to get set 
up, 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.

First things first: LDC is built using cmake, and getting the essentials of the 
`snapcraft.yaml` file set up was super-simple:

-----------------------------------------
name: ldc
version: "1.0.0"
summary: D compiler with LLVM backend
description: LDC is a compiler for the D programming Language.
              It is based on the latest DMD frontend and uses LLVM as backend.
confinement: devmode

apps:
   ldc2:
     command: ldc2
     plugs: [home]
   ldmd2:
     command: ldmd2
     plugs: [home]

parts:
   ldc:
     plugin: cmake
     source: git://github.com/ldc-developers/ldc.git
     source-tag: v1.0.0
     build-packages:
     - ldc
     - llvm-dev
     - libconfig++-dev
     - libcurl4-gnutls-dev
     - libedit-dev
     - zlib1g-dev
-----------------------------------------

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 ... ?

   * 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 ...

   * 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

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?

I'm really delighted with how blissfully simple it was to get the essentials of 
packaging in place, and it would be really great if there were straightforward 
solutions to the remaining issues.

Thanks in advance for any advice, and best wishes,

     -- Joe




More information about the Snapcraft mailing list