El 27/10/16 a las 17:13, Joseph Rushton Wakeling escribió:
On 27/10/16 08:37, Didier Roche wrote:
It would be great to have D support! Thanks for working on that :)
Great to hear :-)
Just to be clear, it's already in principle possible to package D
applications as snaps; DUB support isn't needed, but is very helpful,
because a lot of D projects do use it.
I'm going to try to answer to some of your questions, but I'm sure
Sergio (CCed) would be able to give deeper insights on some parts as
being the snapcraft upstream.
Thanks very much. I'll respond to some of your suggestions below ...
I would really advise going the build.sh route. Doing a custom snapcraft
plugin as you started is definitively the right path.
Yes, agreed. I was curious about the `build.sh` option not because I
think it's a good idea, but because I was thinking: "What if it was
the only build option for this project?" I'd like to know how to
handle that situation if I ever encounter it in another project.
From your questions and the statement that there is no explicit install
steps, I think you mean that D programs just build in tree (snapcraft
tries to encourage builds out of trees) and then, the install step for
people is to copy the resulting binaries and assets manually?
Yes, exactly. It's not _entirely_ as bad as it sounds because each
project's `dub.json` config file can define a `targetPath` variable
where built programs will be placed. The plugin can use that if
available.
If so, I can see 2 paths here:
- either you expect people to explicitely list assets and binaries that
should be installed (this could again be a custom option of your plugin)
This is pretty much the direction I've taken for now.
The make plugin has an `artifacts` option (if you inherit from it you
get it for free). If necessary we can move this to the base plugin or
even as a core capability. Used for projects that are older or do not
follow GNU conventions of having an `install` target.
- either you try to be starter, as you told, and detect extra files
being created in the parts//build. There is no built-in
features in snapcraft for this as far as I know, but, it would be quite
easy to build it as part of your plugin: list at the start of the build
phase files in parts//build and redo the same thing after the
build. Then, in the install phase, use that list (that you store on
disk) to copy newly created content in parts//install. Then,
snapcraft will pick it up from there. Note that I think you still need a
manual options for your users to list eventual assets (or they can use
the dump plugin in another part).
Nice thought. I'll try to look into that.
There is a 3rd option which could be for the plugin to read the
`dub.json` config file of the project being built, and parse that to
discover the targets that will be built, but honestly that feels like
duplication of effort, and it would probably be better to encourage
the DUB developers to provide an `install` option.
If you prefer to copy everything and have your users filtering from the
stage area to the prime area, you can use the "snap:" stenza (don't use
filesets for now if you don't plan to repeat the file list name).
Yup, this is the option I use now.
I would advise in a first step to consider the D compiler used by DUB to
build other things to be part of your snap. You want to control the
version in it and consider it as part of your dependencies you need in
your snap. We can discuss later about an interface, but I would really
go that way as a first step.
Yup, bundling the compiler into the snap is the way I have gone as a
first step.
However, the real issue is that DUB is supposed to provide the user
with the option to choose the D compiler to use. It's tolerable as a
first step to just give one option bundled, but ideally the user would
be able to invoke DUB and specify to it any compiler they like --
whether a snap-packaged one, or one installed on the host system.
I was assuming that allowing the user to (optionally) specify a
compiler of choice via an interface would be easier to achieve, but I
don't know if that's true.
There is no way right now on definining new interfaces apart from
building them in snapd, and so, use your own local version. (That's the
reason why I advise you to not bother with this right now, let's take an
easier path first, figure the rest, and then, we can rediscuss)
Well, I already took the easier path, so that's why I raised the
discussion of alternatives ... :-)
I would look at /var/log/syslogs. Apparmor and seccomp denials are
listed there. Note that if you didn't already, you should really start
developping your snap in devmode. That way, it will get confinment out
of the equasion to get your relocatable code and dependencies working.
Then, we can turn on confinement and figure out those issues to be able
to publish in the stable channel.
Yea, I probably should have started with
