Re: component groups and preparatory patches for sdk/platform work

[Alexander Larsson <alexl redhat com>]

On fre, 2014-11-07 at 15:56 -0500, Colin Walters wrote:
> On Thu, Nov 6, 2014, at 10:22 AM, Alexander Larsson wrote:
>
> > So, I've been thinking a bit about how this should work, and I'm not
> > sure i'm 100% sold on using gnome-continuos for the platform stuff. I
> > like some parts of it, but not others.
>
> Yeah.
>
> > One thing I don't like is all the complexity involved in making it build
> > incrementally. The updating of git mirrors, the resolving for changes,
> > partial builds, etc. For the usecase we have here, which is to build
> > release-quality binaries, the incremental work is not what we want as it
> > gives you no repeatability.
>
> 1) Anytime we want to rebuild everything from source, it's just a matter of setting buildAll=true and 
> bumping the manifest epoch.  
> 2) It would make sense, and not be too terribly hard to have a separate builder that does this at some 
> interval (once a week?)

Its not that its not possible. Its more that the amount of scaffolding
and complexity to allow this makes the entire thing complex to
understand and debug.

> > Another thing continuous does is building and installing the non-base
> > modules and extracts runtime/devel/docs/debuginfo subtrees which it can
> > then (via ostree) combine into a build. I'm a bit undecided about this
> > part. One option is to extract this part and use it for a more
> > streamlined "build a set of modules in order" operation. This is quite
> > doable for the basic platform and sdk relasese, but I would also like
> > the tools used for building the sdk/platform to be useful to people
> > building applications, for instance as a way to build pre-build
> > dependencies that app developers can easily bundle. 
>
> Right...though one would also need to support 3rd parties using their
> own custom build systems.

Obviously, people can do whatever, but we should supply an "easy" way
that most people can use (in part or in its entirety).

> > For instance, once you get out of the simple linear "this set
> > of module make up the platform" you really need dependency and version
> > tracking to avoid e.g. forgetting to bundle a dependency.
>
> Wouldn't your app just fail to run, and that would be obvious?

In the most trivial case (lacks linked to .so), yeah. But there are
other less obvious failures, that happen at runtime only and not during
startup.

> > So, I want to experiment with a different path. We use the g-c yocto
> > base, with the extra work I've done to make it build a minimal
> > non-bootable platform image. Then we use gnome-sdk to build stuff inside
> > a container with this base, exactly like how you build apps. To drive
> > the builds we use rpm[1], producing packages that we can then install
> > when building apps or runtimes. The packages that goes into the runtime
> > is build with prefix /usr, but we can also build packages in the
> > app-bundling prefix (/self atm) for easy bundling into apps.
>
> Mmmm....do you see us taking apps out of the Continuous manifest and
> using this system on build.gnome.org?  Or we keep Continuous as is
> and this is a separate system?

I think we should continue to build gnome as-is from continuos. Its a
very good test of everything. I think we should keep this.

However, maybe we should also build a few apps as bundles in order to
verify that the bundle framework itself works...

> I'd really like to have at least some core applications continuously delivered
> and *tested*.  We've barely tapped this now, but I personally think
> it's really quite cool that we automatically at least run+screenshot Epiphany when GTK+
> changes (or for that matter, glib, kernel).  I'm not aware of anyone else that comes
> close to the speed of re-integration here.

Nod.