Re: Using BuildStream as a module maintainer




On Fri, Feb 16, 2018 at 4:15 PM, Shaun McCance <shaunm gnome org> wrote:
> $ bst build --track-all --track-save core/yelp.bst
> # For some reason I have to do this too? Not sure.
> $ bst build core/yelp.bst

It's a bug (very recently fixed):
https://gitlab.com/BuildStream/buildstream/issues/236

> $ bst shell --build core/yelp.bst bash
>
> That drops me in a shell in a yelp clone. I can do the autogen.sh,
> make, make distcheck dance. (I'll catch on to meson soon, promise.)
> But
> I don't know what to do next. I can't seem to scp. The only editor I
> have for writing NEWS entries and commit messages is vi. I don't have
> my ssh keys, pgp keys, git configs, etc. I'm kind of thinking this
> sandbox isn't the place for me to be doing things.

This confused me too. The missing step is, on the host:

$ bst workspace open core/yelp.bst ~/src/yelp

where the last parameter is the path to wherever you want your git
checkout to be. Then the bst shell command will take you to that
directory, inside the sandbox. You can do make distcheck there, the
generated tarball will appear, and then you can scp it from the host.

> And what about doing general development work? I can't really do much
> inside BuildStream's shell. And even running yelp leaves it pretty
> crippled, because it doesn't have access to /usr/share or D-Bus.
>
> I need some sort of build environment to keep up with dependencies,
> but
> I feel like I'm not fully grokking how people do stuff these days.
> Could somebody shed more light on how they do things?

I don't have a good answer, other than to use JHBuild. That's not a
very great answer, since you know I sent a mail a couple weeks ago
announcing that release team wouldn't be maintaining JHBuild anymore.
(Emmanuele has since taken up that role, in addition to maintaining the
Continuous manifest.) Perhaps that was premature, because many or
perhaps even most GNOME applications are barely functional inside the
bst shell. I've reported an issue for this:

https://gitlab.com/BuildStream/buildstream/issues/223

Problem is, if we keep using both JHBuild and BuildStream, then we have
four different sets of build definitions to maintain, rather than
three, and we're worse off than before. So we'll need to discuss what
we want to do about this.

Michael



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]