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

[Julien Fischer]

On Sat, 9 Jun 2018, Mark Brown wrote:

> Hi Julien,
>
> On Wed, Jun 6, 2018 at 9:12 PM, Julien Fischer <jfischer at opturion.com> wrote:
>>
>> On Wed, 6 Jun 2018, Zoltan Somogyi wrote:
>>
>>>>
>>>> IIRC, we only use that copy of getopt for systems that don't provide it.
>>>
>>>
>>> I believe you are right. I am not sure, but I *think* I added that copy of
>>> getopt
>>> to the runtime for that purpose when I was providing scaffolding code for
>>> projects to my students in whatever subject I was teaching at the time.
>>> The scaffolding was the uninteresting part of the project's code, which
>>> the students thus did not have to spend time to write. They thus did not
>>> write it in umpteen weird and wonderful ways, which saved *me* time
>>> when marking the projects.
>>>
>>> The department's machines always had GNU tools installed on them and
>>> thus had getopt, but some students worked on projects at home (or at their
>>> own workplace, if parttime), and some of *their* systems did not have
>>> getopt.
>>> So I included a copy of GNU getopt with the scaffolding code, and made it
>>> a modified copy with renamed functions and global variables in the
>>> interface,
>>> so that it wouldn't clash with the standard copy of getopt if it *was*
>>> installed
>>> on a computer a student was using.
>>>
>>> That was twenty years ago. Now, we should just assume that the system
>>> provides
>>> getopt, and delete our copy. Unless someone knows of a current
>>> Unix/Linux/BSD/???
>>> system that still lives in the dark ages?
>>
>>
>> I suspect the only user may be the MSVC port; my Windows machine is at
>> work, so I can't check until tomorrow.  *If* we do need to include it
>> then we can replace the GNU implementation with the NetBSD one.
>
> Have you had a chance to look into this?

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.)

Julien.