Re: Debian and package-framework

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