[Python-Dev] Snake farm

Martin v. Loewis martin@v.loewis.de
11 Nov 2002 20:56:52 +0100


Marc Recht <marc@informatik.uni-bremen.de> writes:

> Sorry. Trying to. I've posted more detail (including a build log) on
> SourceForge.  But again the major problem is certain defines and
> typedefs like PF_INET or u_char, u_int (see SourceForge) are only
> defined in the __BSD_VISIBLE case. These defines typedefs are needed
> by certain Python modules like sockemodule, nismodule.

As I commented on SF: Python does not use u_char or u_int. So if that
fails to compile, it's a bug on FreeBSD (it is the system headers,
after all, which fail to compile - something I have no regrets for).

> I also a friend of generic/standard solutions,I don't see one here. I
> would be more than happy proved to be wrong...

Taking the failure to compile system headers away (which really needs
to be fixed in the system), then Python does compile correctly,
doesn't it? Looks like an almost-generic solution to me (if it wasn't
for the warnings about implicitly-defined functions - which all get
defined correctly implicitly).

> "The whole point of the standards constants is to specify a strict
> environment.  If you want a BSD environment don't specify a particular
> standard, it's simple.".

We do want a POSIX environment. If the system offers alternatives, we
want the POSIX alternative, not the native alternative. BSD has a
tradition of doing things differently than POSIX, so I have the strong
urge to tell the system "I want POSIX, dammit". If the system offers
extensions over POSIX, we want them as well. There is unfortunately no
standard way to access those extensions, but most systems do have a
means to access them (while *still* allowing to favour POSIX over any
native semantics). It is really unfortunate that neither OpenBSD nor
FreeBSD offer such an environment.

> I understand that, but this is a build fix. So the evaluation is quite
> simple..

No, it isn't. Python builds just fine without your patch, if we
consider the bugs in the system headers fixed.

> > > Some problems are left, because some functions (like ftello) are
> > > only defined at a higher POSIX level.
> > 
> > Why is that a problem?
> Because Python tries to use them.

Ah, that is indeed a problem. Autoconf is bad in finding out that a
function is available, but has no prototype. This can be fixed (on a
case-by-case basis), and I have fixed it for chroot, link, and
symlink.

This is not a big problem, though. In C, a prototype is implied from
the first call, and that implied prototype is correct.

> Because certain stuff Python seems to rely on isn't there. (see
> SourceForge)

Python relies on none of this. Instead, Python wraps the functions,
and exposes them to the application. There is no "internal" use of any
of the features we are talking about. So if configure determines that
a feature is absent, it just won't be exposed. No big deal.

> An other option could be that Python doesn't use non-POSIX
> functions/definitions were they aren't available..

That is indeed an option. As I said, Python does *not* use these
functions. Not wrapping them is really simple.

Regards,
Martin