[m-dev.] [m-users.] Closed source Mercury projects on Windows

[Julien Fischer]

On Sun, 10 Jun 2018, Julien Fischer wrote:

> I have now.  The situation with getopt is more complicated than I
> originally thought.  We have two uses for the C getopt code.  These are:
>
> 1. Option processing for the programs in the util directory.  Here, we
> look at the setting of the autoconf variable GETOPT_H_AVAILABLE, and if
> the system has getopt available we use that with the util programs and
> if not, then we use the copy in runtime/GETOPT.  For MSVC, we always
> have to do that latter since the MS system libraries don't provide
> getopt.   (Pretty much everything else provides either the GNU or NetBSD
> versions of getopt.)
>
> 2. Processing of the contents of the MERCURY_OPTIONS variable in the
> runtime.  This is done by using runtime/mercury_getopt*.[ch].  In turn
> those files are produced from the ones in runtime/GETOPT using the
> script runtime/process_getopt.  In short, the runtime *always* uses this
> version of getopt and never uses the system version if present.  (I
> could not find anything in the runtime that even checked the autoconf
> variables for getopt.)
>
> Use case (1) is not problematic, the programs in the util directory are
> GPL licensed anyway.  (We do need to provide a version of getopt with
> Mercury for use with the MSVC port.)
>
> Use case (2) is problematic, since the FSF is the copyright holder of
> the and they haven't agreed to license it under new terms.  I think we
> can resolve this situation by replacing the existing
> runtime/mercury_getopt*.[ch] with adapted from one of the BSD getopt
> implementations.  (While there, apparently, some differences between
> them and the GNU one, I don't think they will be an issue; the
> processing required for MERCURY_OPTIONS is that sophisticated anyway.)

Actually, we have three uses since the code in the trace directory
also makes use of the version in runtime/mercury_getopt.

Julien.