Re: Cross-building and debugging

[Baurzhan Ismagulov <ibr@radix50.net>]

On Mon, Oct 30, 2017 at 02:43:05PM +0100, Henning Schild wrote:
> If you ask me now, cross compile support should not be added to Isar,
> because it is against what Debian is doing.

Debian happens not to cross-build due to various reasons. That said,
cross-building isn't officially prohibited. In fact, Emdebian, debian-cross,
and debian-bootstrap are using it. There were mass bug filings that resulted
IIRC in a couple of hundred packages accepting cross-building patches. I'm also
very curious what debian-mobile comes up with.

You are right that without testing, those changes would bitrot. The efforts
above are not a part of the official Debian infrastructure yet, but there are
discussions about that.


> If the only upside of such complexity is gain in speed i would probably
> reject patches that try to introduce something like that.

The efforts of e.g. debian-bootstrap is to be able to reproducibly bootstrap
any arch from zero. This is an important ability for any distro, desktop or
embedded.

The implementation involves installing the compiler and passing the right
options to configure and dpkg-buildpackage, which we do already for native
building. So, additional complexity is marginal. Debugging may be one level
more complex, but cross-building is officially supported in Debian tools. Isar
itself doesn't impose one or another way of building, so the user would choose
whichever one is suitable for him -- individually for debug or release builds
of the same working copy.

Build times are critical in times where developers are scarce and their time is
expensive. The slower the development loop, the more is the developer blocked.
And what is not tested doesn't work. This is one of the reasons Isar explicitly
cares for performance -- as the last but not least aspect.


> With the
> recently merged cache features one could just keep the .debs and the
> compile-time would only be a problem once and maybe for CI.

The initial "cache" name turned out to be unfortunate and has caused much
confusion. The idea behind the feature is to provide mechanism for deploying to
apt repos. The policy -- i.e., how the users are going to use it -- is up to
them. The intended use cases are:

1. Hardware vendors providing layers for Isar with their source and binary
   packages (kernel modules, libraries, tools, etc.).

2. Product builders managing binary artifacts as a part of their CM, especially
   safety-oriented processes.

And sharing the binary artifacts between the developers to speed up build times
is a nice add-on.


> Today you could use dpkg-raw and just package your binaries, that maybe
> came from another build-system.

In the long run, I'd like to see that extended to a more Debian way, Isar
generating debian/rules on the fly.


With kind regards,
Baurzhan.