Snapping LDC (LLVM-based D compiler)

[Mark Shuttleworth]

On 28/08/16 08:00, Joseph Rushton Wakeling wrote:
>
>> 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.
>
> Well, no promises (busy times elsewhere in life), but I'll certainly
> try to take a glance.  I've never written go code before, but there's
> a first time for everything...
>

Can highly recommend learning Go, but this would be the deep end, better
to find more straightforward starting point :)

>> 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.
>
> Cool, thanks!  I'll rename the snap to `ldc2` then (this is the
> expected compiler command).
>
> That still leaves `ldmd2` to deal with later, but that's less
> important in general.

Yeah, that would end up as ldc2.ldmd2 for the moment, but once we have
multiple commands mapped in from the snap we could allocate the ldmd2
command to it and it would automatically become available without the
snap namespace prefix.


> I presume a complication here is that a snap package might be
> installed into /snap/ or into /home/<user>/snap/ so the precise path
> would have to be determined at install time, it can't be known at
> packaging time ... ?
>
> Is there any wildcard that could be used in order to get the snap's
> install dir, that could be inserted into the config file?  Along the
> lines of,
>
>     -I$WHERE_THE_SNAP_LIVES/include/d/ldc
>

Try $SNAP for the location of the snap root, and there are a few others
like $SNAP_DATA and $SNAP_COMMON and $SNAP_USER_DATA and
$SNAP_USER_COMMON which are writable directories (the COMMON ones are
unversioned the others get snapshotted on update). The snap also get its
own /tmp directory.


> Re the classic system -- it did occur to me that the most
> straightforward short-term solution would be to require that the
> `classic` snap be present.  So in that case it's just a matter of
> exposing (say) a `gcc` interface from the classic snap, or just the
> linker if it's possible to be narrower?

Yes you can arrange for the snap to see stuff from the rest of the
world, but the more of that you have, the more you burden the user to
get all those bits in place. I would explore the bundling option and see
how that pans out. It doesn't look like it's particularly large. And
we're adding delta updates so even if it is quite large it will only
affect update sizes when it changes.


> Is this the point where we start singing, "I want you, I need you" to
> one another? :-P

LOL :)

Mark