bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] Re: [PATCH] ping on GNU/KFreeBSD patch sent a while ago


From: Paul Eggert
Subject: Re: [Bug-gnulib] Re: [PATCH] ping on GNU/KFreeBSD patch sent a while ago
Date: 30 Oct 2003 11:31:07 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Robert Millan <address@hidden> writes:

> >         i386-pc-kfreebsd-freebsd
> 
> This is is correct, although redundant and very impractical.

Why is it impractical?

> If you want to change it, take this up with the FreeBSD developers.

The FreeBSD developers aren't in charge of the strings that
config.guess uses to name kernels.  These strings are designed for the
GNU project's convenience.  Why should the FreeBSD developers care, or
have any say over, whether config.guess calls the FreeBSD kernel
"kfreebsd" or "freebsd" or "FreeBSD" or "freebsd_kernel" or whatever?

> > But using different $host_kernel values ("freebsd" for one and "kfreebsd"
> > for the other) will only create porting hassles for programs which depend
> > on the kernel (e.g. which depend on the way to access the sound card or
> > the console keyboard map etc).
> 
> This only happens for a very reduced set of packages. The normal tendency is
> to use the triplet to check for userland (typicaly, libc). On most of the
> situations, the same rule that checks for "-linux*-gnu" or "-gnu*" works for
> "-k*bsd*-gnu" pretty well.

The checks that you're talking about happen only for a small set of
configuration variables.  Most configuration variables are deduced
directly from the system, without caring what the system's name is.
The normal tendency for most configuration variables is to not look at
these names at all.

For example, if 'configure' really needs to know whether it's using
GNU libc or some other libc, then it should do so directly, by
compiling a little program and seeing what the GNU libc version is.
This is far more reliable than trusting config.guess, which sometimes
makes incorrect assumptions in this area.

> And believe me, having ported the first hundreds of software packages to
> GNU/K*BSD, I have some idea on what I'm talking about.

I believe that you've come up with a system that solves your
particular problem.  But we need a solution that everybody understands
well.  Maintainers need to understand what's going on, and the current
naming convention is confusing.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]