Vala and Snapcraft. Issues with a library part in Vala.

[Luca Dionisi]

Maybe I found my error. It is in (lack of) usage of data from
pkg-config files. Thus it is not strictly related to snapcraft.
When mylib-x is built (and staged) by snapcraft the corresponding
mylib-x.pc file is saved in [...]/stage/[...]/pkgconfig and it states
that "prefix" variable is [...]/stage/usr.
When building mylib-y, which depends on mylib-x, the configure part
read this pc file. Now, the makefile should use this "prefix" variable
and add this line to the valac command:
  --vapidir=$prefix/share/vala/vapi
Since usually I install with prefix=/usr and the directory
/usr/share/vala/vapi is searched by default by valac, the lack of this
line was not a problem until now.

I need some trial and error test now. I'll keep you posted on progress.

On Wed, Feb 1, 2017 at 11:29 PM, Luca Dionisi <luca.dionisi at gmail.com> wrote:
> I am already doing "after: [mylib-x]".
> Snapcraft builds correctly mylib-x and stages it.
> Then snacraft tries to build mylib-y with the valac compiler.
> The compiler valac looks by default in /usr/share/vala/vapi for a vapi
> file that is produced by mylib-x.
> The problem is that that file now is in .../stage/usr/share/vala/vapi.
> The makefile should add a "--vapidir" flag to the compiler. This was
> not needed before because I was always installing mylib-x in the host.
> Now I want to create a snap and I am struggling with this issue.
> I realize that I don't know how to tell to autotools (in Makefile.am)
> that it has to add this flag when the package is being built with
> snapcraft.
> Maybe I should check DESTDIR, because I see [here
> https://snapcraft.io/docs/reference/plugins/autotools] that the
> autotools plugin of snapcraft uses DESTDIR by default as a mean to
> redirect installation.
>
> But I am afraid that this thing could be a ugly workaround, not very
> manageable. What do you think?
>
> On Wed, Feb 1, 2017 at 10:19 PM, Joe Talbott <joe.talbott at canonical.com> wrote:
>> I think you'll want something along the lines of:
>>
>> parts:
>>     mylib-x:
>>         ...
>>     mylib-y:
>>         ...
>>         after: [mylib-x]
>>
>> This will include both mylib-x and mylib-y in your snap and ensure
>> that mylib-x is built before mylib-y is.
>>
>> Joe
>>
>> On Wed, Feb 1, 2017 at 10:01 AM, Luca Dionisi <luca.dionisi at gmail.com> wrote:
>>> On Wed, Feb 1, 2017 at 1:29 PM, Gustavo Niemeyer <gustavo at niemeyer.net> wrote:
>>>> Yeah, besides "build-packages" there's also "stage-packages" which does
>>>> exactly that.
>>>
>>> I think you misunderstood. "build-packages" puts a deb package in the
>>> build host, "stage-packages" puts a deb package in stage.
>>> But I don't have a deb package of mylib-y.
>>> I want snapcraft to build both mylib-y and mylib-x, where mylib-x
>>> depends on mylib-y being installed.
>>> What I want is snapcraft to put the "install" pieces of the part
>>> "mylib-y" in the build host too (other than in stage).
>>> Is that doable?
>>> Or... wait, are you telling me that I can put the name of another
>>> "part" in "build-packages" instead of the name of a deb?
>>>
>>>
>>>> On Wed, Feb 1, 2017 at 8:34 AM, Luca Dionisi <luca.dionisi at gmail.com> wrote:
>>>>>
>>>>> This is another solution that I thought of.
>>>>> I want to put the library mylib-y (the one that is needed by mylib-x)
>>>>> both in the ./stage tree and in the /usr/ prefix of the host system
>>>>> where I prepare the snap.
>>>>> Is there a way to tell snapcraft to do so?
>>>>> It should be similar to the way one can use 'build-packages' to
>>>>> install deb packages on the build host.
>>>>>
>>>>> --Luca
>>>
>>> --
>>> Snapcraft mailing list
>>> Snapcraft at lists.snapcraft.io
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
>>
>> --
>> Snapcraft mailing list
>> Snapcraft at lists.snapcraft.io
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft