
Hi everyone, Alastair's recent checkin gave Hugs98 access to a great many of the modules provided by fptools/hslibs, which is great. What about adding these derived modules to hugs98/lib in the CVS repository? I know very well there are downsides to replication, but having a CVS tree that's self-contained does have its merits. As is, you need to do a sep. checkout (but see below) & have to be on a UNIX box to generate the Hugs versions of the hslibs/ modules. Thoughts? --sigbjorn btw, you can now get at the contents of hugs98/ and fptools/hslibs in one go via the virtual CVS module 'hugs98dev' -- fptools/hslibs is checked out as hugs98/hslibs/hslibs (anyone well trained in CVS 'modules' setups is welcome to have a go at changing this to hugs98/hslibs ;-) ).

"Sigbjorn" == Sigbjorn Finne
writes:
Hi everyone, Alastair's recent checkin gave Hugs98 access to a great many of the modules provided by fptools/hslibs, which is great. What about adding these derived modules to hugs98/lib in the CVS repository?
I know very well there are downsides to replication, but having a CVS tree that's self-contained does have its merits.
I lean against this because: 1) It will encourage divergence to happen again. The only way I know to avoid this is to run off a single set of (ifdefd) sources - and even that isn't perfect. 2) Johan's recent checkin of the hierarchial module names should put us very, very close to being able to use the new library repository. (SimonM has the Prelude and the lang stuff pushed over to the new repo and working with ghc (not committed yet, I think). If his batteries last, I'm sure he'll have all the other libs done by the time he steps off the plane tomorrow. If I'd realised he was this close, I'd have held off on my commit.) I find the "single repository" argument unconvincing. (One could also argue that not having to run cpp, sh, perl or whatever my script depends on is important - I totally buy that argument for Hugs releases but not for anyone using cvs.) There may be some merit in insulating ourselves against any breakage that may be introduced in the main library. But Andy Gill suggested a simpler way of doing that based on nightly (or more frequent) testing and a "last working/stable version" tag which is automatically advanced by the testing mechanism. (We also hope that social pressure will keep the rate of breakage significantly lower than in, for example, the GHC module - mere technical approaches can only go so far.) -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
participants (2)
-
Alastair David Reid
-
Sigbjorn Finne