[m-rev.] for review: derive getopt.m and getopt_io.m from same template

[Zoltan Somogyi]

2020-09-18 17:08 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
> I suggest defining the following variable somewhere in this Mmakefile
> 
>    SED=sed
> 
> and using the variable in these rules insteaed of hardcoding it as sed.
> (That gives us the option of choosing which sed to use on systems where
> the default sed may not be the one to use.)

Done. And thanks for the two big catches below.
 
> I would expect to see one of the clean targets being modified to clean up
> $(GENERATED_SOURCES), realclean_local?

I changed away from building getopt.n and getopt_io.m automatically
every time getopt_template changes, because ...
 
>  Has this change been tested when building with --use-mmc-make?

... I don't want to teach --use-mmc-make about this dependency.
Instead, the attached template3 diff builds getopt.m and getopt_io.m
before generating the dependencies. (If you get an error about
these files being missing, "mmake depend" in the library will fix it.)
The accidentally-committed initial diff already builds them when making the tar file.

> Has a source distribution based on it been built and does that source
> distribution successfully install?

Yes to the first part, though only after you asked this question :-(
The second part should not be needed, since getopt.m and getopt_io.m
are in the tarball (I checked), but it is in progress on my laptop now.

I did the cleanups to compiler/notes when I went there in search of
documentation about how to build the source distribution.
I didn't find anything relevant.

I did remember tools/test_mercury, but that script was last updated in 2013,
and I have strong doubts as to whether it still works, since it contains
the hard-coded names of machines that haven't existed for years :-(

I did find build_srcdist, updated its style (see attached diff), but found it
quite hard to use, partly because of the lack of documentation, but partly
also because its job seems to be unnecessarily error prone. For example,
doing "build_srcdist ... > errs" will delete the errs file before you can
look at it.

What would be wrong with changing things so that build_srcdist

- takes three arguments:

  - the name of a directory containing a checked-out git workspace,
  - the name of a temporary directory such as /tmp or /var/tmp, and
  - something that specifies name of the final .tar.gz file, either directly,
    or by specifying a version name.

- build_srcdist would then *copy* the named workspace to the tmp directory,
  do its work *there*, *without* affecting the original workspace,
  and then delete the copied workspace after it built the tar file,
  unless a debugging flag asked for it to be retained for inspection.

I think it would take less work to make a version of build_srcdist that did that
than to fully document the existing build_srcdist script, claws and all.

If you think the idea is sound, I could change build_srcdist along the above
lines, though you would have to do the final commit, since you would
need to adjust the code invoking build_srcdist first.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.template3
Type: application/octet-stream
Size: 424 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20200919/bb809213/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.template3
Type: application/octet-stream
Size: 1595 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20200919/bb809213/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.buildsrc
Type: application/octet-stream
Size: 4808 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20200919/bb809213/attachment-0002.obj>