Re: dpkg-cross maintenance status
In the article <[🔎] 200201070834.g078YaM02286@mule.m17n.org>,
NIIBE Yutaka <email@example.com> wrote:
> David Schleef wrote:
> > Perhaps some day, we might have cross-compiling as part of Debian
> > policy (or at least a tag for cross-compiliability), but I
> > certainly wouldn't advocate that now, as it would cause too much
> > turmoil.
> Things I've noticed:
> (1) Original software is not ready for cross compiling, hard to solve.
> Typical case is the one which builds small program at first
> and then run it to generate full-featured one.
> Perl, GNU Emacs and others.
> (2) Original software is not ready for cross compiling, easy to fix.
> Software which hard-code C compiler as "gcc" in Makefile.
> Just fix it to $(CC).
> (3) Pakcages which need --host=XXX option when invoking configure.
> (4) Packaging mistake. Confusion of BUILD and HOST.
> (5) Package which does test on build. We cannot test generated
> executable in case of cross compiling.
> I think that for case #5, we could have some sort of guildline or
> tools, separation of build and test would be good thing (in general).
Good summary. This reminds me of most troubles I've ever suffered
when cross compiling. :->
Today I was told that some source packages support cross compiling by
itself (see Bug#127909; thanks to Marcus Brinkmann).
That's very helpful indeed, but IMO every package doesn't need to
support cross compiling. This request would increase maintainer's
load and it would take a long time.
Rather than that, standard tools like dpkg-buildpackage should take
care of trivial matters, for example setting CC=sh3-linux-gcc before
I think that the additional functionality of dpkg-cross is not so
complicated. It would be good if some of that would be commonly
supported by the standard dpkg-dev suite.
YAEGASHI Takeshi <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>