[Python-Dev] Snake farm (original) (raw)

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 PFINET or uchar, uint (see SourceForge) are only _defined in the BSDVISIBLE 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