gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Debian and package-framework


From: Thomas Lord
Subject: Re: [Gnu-arch-users] Debian and package-framework
Date: Wed, 10 May 2006 10:39:55 -0700
User-agent: Thunderbird 1.5 (X11/20060313)

Ludovic Courtès wrote:
 `package-framework' is lucky to exist in a *slightly* simpler
 world.  It is much easier to write portable code, even for
 many low-level system operations, without any pre-processor
 conditionals at all.

This may only be true when writing very simple C code.  When it comes to
things like raw I/O (i.e., not ANSI C's `fopen' et al. functions, but
rather `read', `write', etc.), in particular in non-nominal situations
(e.g., non-blocking I/O), or, worse, socket-based networking,
portability among Unices does not exist at all and feature tests looks
like the best way to overcome this.
`tla' uses *nothing but* POSIX `read', `write', etc.   It contains
socket-based networking code that seems to port just fine (I recall
an extra library must be linked against on Solaris, or something
like that).   So far as I know, `O_NONBLOCK' works fine everywhere.
And there's not a feature test or conditionalized line of code in
site.

I'm sure you are right that there are some areas where portability
is harder to achieve but I think you are exaggerating with those
examples.

I also agree that *sometimes* feature tests are the right thing --
it's just that those cases are far rarer the number of cases where
people use feature tests anyway.

One thing you might be thinking of:  The Linux kernel and
GNU libc both tend to offer and encourage the use of
non-portable features.   For a small number of important
applications there may be real value to this but it is a mistake
for people to use these features widely or depend on libraries
which rely on these features.   Portability is not just about
how well free software runs on proprietary platforms, but
also about how it will run on future free systems.

OTOH, fortunately, more and more higher-level, portable libraries are
being used (e.g., GNet, Glib, and G-friends), and a lot of portable
language runtimes are available as well (for Scheme, CL, Python, etc.).
Portability and utility libraries are a good tactic (if well applied) for avoiding
configuration hair.

But in the latter case, the configuration step is mostly unneeded.

It's amusing, isn't it, that so many of the scripting languages (Python, Perl,
Ruby, notably) wind up with their own little package, configure, install
systems.


-t






reply via email to

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