Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)

[Jamie Lokier <jamie@shareable.org>]

Enrico Weigelt wrote:
> Most times I've seen those checks, they silently enable some 
> features, eg. if it looks for certain kernel devices. Definitively
> the wrong way!

Agreed.  Though, you do often have to check for headers etc.,
otherwise you won't have the definitions needed to work with those
devices.  (Think: inotify).

> It really should be in users/packagers control to
> explicitly enable features.

But then there's a problem with 100 or more --enable-foo command line
options.  The user's script will _calls_ ./configure will
bitrot... there's no way you'll be typing it on the command line.

A big package can easily depend on that many local features.

> Nevertheless, the existence of some file or device says nothing
> about whether it will be usable (or *should* be used) at
> runtime. I've seen packages silently enabling some feature and then
> failing at runtime since the previously detected device is missing
> later. What a nightamare for packagers.

I agree, assume they're all there is not sane.

> Another point are broken syscalls. Well, you *have* check at runtime 
> to be sure, or perhaps choose to ignore it and expect a sane system.

That said, to use rsync as an example.  It uses the utimes() system
call when available, and utime() otherwise, because the former is
better.

On current GNU/Linux it will use utimes().  Recently someone tried to
run it on an old kernel, and it failed.  If it tried utimes() first
then fell back to utime(), it was fine, and rsync has a patch to do
that now.

But here's the thing: do you really want every package have code
calling every different variation on a system call, at run time, until
it finds one that works?

-- Jamie