Re: Question: Cross compilation

[Chris Yate]

On 27 Sep 2016 18:31, "Jan Nieuwenhuizen" <address@hidden> wrote:.
>
> > A Lilypond build tool for all platforms to which someone's added half
> > a dozen extra unrelated targets (possibly very large ones such as
> > OpenOffice) = a terrible idea.
>
> Thanks!  GUB was the first to be so generic that it could be used for
> other projects as well, with almost no cost.  I hoped for GUB to be
> adopted by other projects, so that we would share maintenance and
> development effort on it.  It is (or was?) actively used by GNU Denemo,
> so that's where the GTK+ stuff comes from and at the time I worked on
> go-oo (the predecessor to LibreOffice) so I hooked that in too.  The
> idea was: once such a project uses this, others will join.
> Apparently, I did not succeed in bringing easy cross builds to other
> projects and with as a consequence I also failed in sharing maintenance
> load. 

>So, please remove any OpenOffice references and depnedencies (git
> will remember anyway). 

As David said, they're not really an overhead - but they are unmaintained.

> You may want to check with the GNU Denemo team
> before removing their dependencies.

Jan, I gather from your tone that you don't take all this too personally... I'm glad. GUB clearly had great intentions. I suspect its complexity has been a barrier to developing it into something more readily usable.

My struggle is building a local Lilypond build for one platform and in fact, in principle, I think it's pretty well suited to the task. Currently, it's not working for me (some dependency is broken). But that's not really the fault of GUB, as such. 

If building all dependencies from scratch could be avoided, that would be helpful.

I believe Denemo are still using this, based on a message above here in the thread, but they may have their own fork.

> I think GUB is beyond fixing, simply because it's community is too
> small.

It contains logic that could be used to create a new cross-build tool. The fear I have with modifying very bespoke and complicated tools is a lack of knowledge of failure modes - And especially that one can't possibly test every output.

> ... because a build tool that takes 24+ hours to rebuild
>
> There are reasons for this.  GUB's aim was to find the sweet spot
> between complete OS independency/separation (fedora/debian/whatnot)
> and reproducibility.  It fails at both of these requirements, but I
> maintain that it was a fair effort.  If you want to be OS-independent
> and reliable, you'll have to build your own toolchain.

It's a really complicated task and I think a valiant effort. I wonder whether there are now better ways one would build the same thing...

> I am currently working on Guix/GuixSD and have implemented a MinGW cross
> build facility that can cross build Guile which has been reviewed and
> will be merged soon.  I have patches that will cross build LilyPond
> and all its dependencies, some of those need cleanups and they need
> to be reviewed.
>
> Using Guix as a LilyPond build system presents a whole new set of
> problems/questions, but it would solve the biggest problems with GUB.
> It has an active community, so effort is shared.  It is very well
> documented and a whole lot more mature, better designed.  It has /full/
> OS separation; produces bit-reproducible binaries.  And it has a system
> of using binary substitutes: cross builds do not need to take longer
> than other builds.
>