new Library Infrastructure spec.
alastair at reid-consulting-uk.ltd.uk
Mon Jun 7 12:46:31 EDT 2004
On Monday 07 June 2004 16:44, Arie Peterson wrote:
> OK. As I understand it, Marcus creates a Setup.lhs that merely passes its
> arguments to a makefile. All the relevant information is contained in that
> Is that makefile supposed to be platform independent? (And with platform
> independent I mean really independent, so no emulation (Cygwin, for
> example) is needed.)
As I understand it, the idea is that the makefile is as portable or
non-portable as Marcus felt like making it.
Once the code has been packaged up and made available, someone (Marcus or a
fan of Marcus's code) _might_ do any of the following:
- Nothing more.
In this case, the code integrates nicely with the rest of the packaging
system on some platforms and is unavailable on others.
Not ideal but better than nothing and it might be that the code
isn't very portable anyway.
- Make the makefile more portable.
Anyone who has maintained a system of any complexity will know that
porting (code, makefiles, configure scripts, etc.) can be an
enormous amount of work. So, it would be nice if this gets done but
if the code only ever runs/builds/installs on FreeBSD systems which have
libfoo version 2.97a (not 2.97b, please) installed, then Marcus and
his pals have still gained from using the packaging system because it can
interoperate with other packages.
- Replace the makefile with something more portable like an hsmake file,
maybe using Malcolm Wallace's cpphs and other portable tools, maybe
writing a simple Haskell (or Perl, python, etc.) script to replace
some key part of the makefile.
Hopefully, this makes the installation process more portable so,
again, some gain is made. We're still not using the simple
installation system, we're still not fully portable but the code
is more widely usable and it can interoperate with other packages.
- Realize that the simple installation system has all the features needed
to replace the Makefile. (Or extend the simple installation system
to achieve this goal.)
This is obviously simplest since it is portable, easier to port, etc.
but it is ok if some packages can't reach this point.
My point is that you don't have to be using the simple installation system to
get benefit and to interoperate with packages which do use the simple system.
This is very much a strength of the proposal since any single system powerful
enough to do everything we want of it is likely to be complex, hard to port,
etc. Better to have a solution that does 95% of the problem well and which
can interoperate with whatever is used for the other 5%.
More information about the Libraries