Re: What if Guile changed its license to be LGPL?

[Thien-Thi Nguyen]

   From: Neil Jerram <address@hidden>
   Date: 05 Jun 2002 16:45:47 +0100

   - a consistent approach to factoring non-core functionality out of
     core libguile

   - a consistent approach to linking in such optional functionality and
     handling any runtime licence implications that result

   - a consistent approach to coping with the non-existence of optical
     functionality

all these are part of build methodology.  see below for 1.4.x ROADMAP
(under $w/build/dist-files locally) -- critique welcome.

   - consistent usage of `features' and/or `cond-expand' to permit
     programs to discover what optional functionality is present.

how do these interact w/ each other?  are there weird corner cases?

thi


_________________________________________________________
This file explains the general direction of Guile.



1.4.x Goals

        - No breakage for current usage.
        - Build methodology evolved into architecture/implementation.
        - Build methodology documented and exported.
        - Scheme compilation to native code supported by build methodology.

        By the end of 1.4.x, we want to be able to use guile maximally
        from a "scheme world" point of view, reaching out from that
        centrality to the hardware and everything in between, and do so
        w/o forgetting how we did things before.

        The key task here is to understand what the hell we're doing.
        Then we put a name on it, put in place general machinery to
        handle that case and any historic cases, and lastly re-work
        these methodologies into scripts w/ parameters specific to Guile
        and documentation explaining how to specialize the scripts.
        Scripts then go under "guile-tools".