Re: [PATCH] OS/2 dynalinking

["Karim.Belabas" <Karim.Belabas@math.u-psud.fr>]

On Wed, 7 Mar 2001, Ilya Zakharevich wrote:
> This patch brings three new files into the distribution, dl_os2.c, dlfcn.h,
> and pari.def.base.  Tentatively, I put them into src/systems/os2/.

Hi Ilya,

  thank you for your recent batch of patches. I've included them all in the
CVS development archive [2.2.0.alpha.alpha.alpha, don't download it yet,
unless you are prepared for frequent upgrades], EXCEPT for this last one.

Of course, it's probably the most important one (at least for OS/2 users),
but it's annoying to rename things once they have been taught to cvs. So I'd
like to discuss a few things first. So far, for system specific stuff, PARI has

1) #define in the middle of general code [NOT a good thing, to be eliminated]

2) generic trivial wrappers: os_read, os_signal, os_getenv, ... in
src/language/es.c, which fail automatically on some architectures (e.g
WinCE). [Better, but not uniform]

3) Odos/pariCE.c which is only linked in the CE binary and contains a number
of needed standard routines, trivially implemented, or in terms of the
Windows API.

Would a directory src/systems, containing e.g.

  os2.c     unix.c   winCE.c
  os2.h     unix.h   winCE.h

each system being represented by only 2 files, be acceptable ? We could then
eventually remove all instances of 1).  The unix.c file would contain most of
the current conditional code, e.g wrappers for all system calls we use (the
current 2)). Files for "alien" systems return failure codes for most of them,
and implement some others. Ideally, most system-oriented of feature-oriented
#ifdef would disappear from the general code and be concentrated in that
directory.

This would make clearer the actual dependance on various OS features in the
PARI code [e.g it is not normal that current src/modules/galois.c contains an
#ifdef UNIX !!!]. And might initiate implementations of obviously missing
features :-). But I think it would be too much of a hassle to link in many
additional small code modules for each system (as your proposed naming scheme
implies), hence the "bulk" approach. Does this look OK ?

    Karim.
-- 
Karim Belabas                    email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud             Tel: (00 33) 1 69 15 57 48
F-91405 Orsay (France)           Fax: (00 33) 1 69 15 60 19
--
PARI/GP Home Page: http://www.parigp-home.de/