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 -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
