new Library Infrastructure spec.

[Alastair Reid]

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
> makefile.
> 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%.

--
Alastair Reid