(Not entirely) working LDC snap
On 04/09/16 13:55, Joseph Rushton Wakeling wrote: On 27/08/16 22:45, Joseph Rushton Wakeling wrote: I thought I'd have a go at making a snap of LDC, the LLVM-based compiler for the D programming language. A "final first draft" of the working snap is available here: https://github.com/WebDrake/ldc2.snap/pull/1 So, you'd think I'd have tested this before, given that I'm trying to snap a compiler, but ... :-P Turns out the snap-packaged LDC will fail if it's trying to compile a project that needs other libraries to be linked in. This isn't surprising, of course -- system libraries won't be on the library paths of the snap -- but it does put in place a BIG constraint on what can be built and what not. Any thoughts on how this might be addressed? Thanks & best wishes, -- Joe -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: (Not entirely) working LDC snap
On 05/09/16 18:15, Joseph Rushton Wakeling wrote: > On 04/09/16 13:55, Joseph Rushton Wakeling wrote: >> On 27/08/16 22:45, Joseph Rushton Wakeling wrote: >>> I thought I'd have a go at making a snap of LDC, the LLVM-based >>> compiler for the >>> D programming language. >> >> A "final first draft" of the working snap is available here: >> https://github.com/WebDrake/ldc2.snap/pull/1 > > So, you'd think I'd have tested this before, given that I'm trying to > snap a compiler, but ... :-P > > Turns out the snap-packaged LDC will fail if it's trying to compile a > project that needs other libraries to be linked in. This isn't > surprising, of course -- system libraries won't be on the library > paths of the snap -- but it does put in place a BIG constraint on what > can be built and what not. > > Any thoughts on how this might be addressed? Yeah, this is exactly what I ran into snapping asciinema - it's a tool best used WITH the other files on your system. In my case, I wanted to make an asciinema movie of a Juju deployment, but as soon as I hit "asciinema record" I was essentially inside the asciinema sandbox and unable to see binaries installed in the classic filesystem. I started a thread on one or other snapcraft list about 'snaps that can properly see the system'. A chef or puppet snap, for example is going to want to manipulate /etc/foo.conf. Your LDC snap wants to use libraries in "real" /lib/ not "sandbox" /lib/. There is a balance - the upside of having a "sandbox" /lib/ is that it is *the same everywhere* even if your snap is running on openwrt. But for this class of developer tool, snaps will be much more useful if they can really integrate into the CLASSIC environment. We'll get to this. My straw man proposal is an interface which essentially makes "/classic/lib/" and "/classic/bin/" available to your snap, so as long as your snap's $PATH is twisted appropriately it will find things there. That's a proper bit of yoga on where snaps came from and how we got them onto classic in the first place, but I think it has merit as a starting point. On the other hand, snapping redis, rethinkdb and rqlite has gone really smoothly :) Mark -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: (Not entirely) working LDC snap
On 06/09/16 00:53, Mark Shuttleworth wrote: There is a balance - the upside of having a "sandbox" /lib/ is that it is *the same everywhere* even if your snap is running on openwrt. But for this class of developer tool, snaps will be much more useful if they can really integrate into the CLASSIC environment. We'll get to this. My straw man proposal is an interface which essentially makes "/classic/lib/" and "/classic/bin/" available to your snap, so as long as your snap's $PATH is twisted appropriately it will find things there. That's a proper bit of yoga on where snaps came from and how we got them onto classic in the first place, but I think it has merit as a starting point. Yea, makes sense. It'll be fun to play with when it's ready :-) There was an idea that occurred to me, which I'm not sure necessarily fits with the snappy vision, but here goes. The metaphor for interfaces is plugs and sockets -- which suggests one to one connections. But where things like development libraries are concerned, one could imagine this more like posts on a bulletin board: the individual services post their availability via a particular board (in this case, the "development library" board), and snaps interested in consuming a particular class of service can find out about and access all the services of a particular kind by asking to read the associated board. IOW instead of requesting access to one particular interface, snaps could request access to collections of services, and other snaps could add individual services to a given collection. This could be an interesting way to make development libraries available without relying on an underlying "classic" system. On the other hand, snapping redis, rethinkdb and rqlite has gone really smoothly :) Nice! Congratulations :-) -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: (Not entirely) working LDC snap
On 06/09/16 23:21, Joseph Rushton Wakeling wrote: > IOW instead of requesting access to one particular interface, snaps > could request access to collections of services, and other snaps could > add individual services to a given collection. In a sense the "set of slots that have a matching interface to your plug" is the collection (though some of those slots are generative - you ask for a disk, they give you a disk but keep offering disks until they have no more to offer). I like the metaphor though, let's see if we can work it into the story. Mark -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
