Snapping LDC (LLVM-based D compiler)

[Joseph Rushton Wakeling]

On 28.08.2016 00:05, Mark Shuttleworth wrote:
> 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 :)

Just the weekend, in my case, but the same principle applies ... :-)

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

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

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

I tried also using strict confinement, just to see if it would make a 
difference, but it doesn't.

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

... ?

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

Ah, interesting thought -- I'd considered the interface to the linker, but the 
thought of just bundling it hadn't occurred to me.  I'll chat with the LDC devs 
and see what the minimal requirement would be here.

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

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?

>> 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 :)

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

As it happens I don't know if I _need_ snappy, but I am finding myself wanting 
it and I'm reasonably on the path to loving it ... a better 2 out of 3 than 
Meatloaf's, I feel ... :-)

> Nicely done and welcome aboard!

Cheers!

Thanks again & best wishes,

     -- Joe