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