[lmi] Thoughts on 'setup.make' wrt MinGW installation

[Greg Chicares]

Why not extract the MinGW stuff, polish it up, and post it to the
MinGW mailing list? I imagine you'd get some useful comments. And
they really could use an robust installer that lacks surprising
features and is easily customizable.

On 2005-8-24 13:50 UTC, I sent this to the mingw mailing list

|   [ -e foo.tar.bz2 ] || wget --non-verbose 
ftp://ftp.sf.net/whatever/foo.tar.bz2
|   $(ECHO) "[hex stuff]  foo.tar.bz2" | $(MD5SUM) --check
|   [ -e foo.tar ] || $(BZIP2) --decompress --keep foo.tar.bz2
|   $(TAR) --extract --file=foo.tar

and it was received well enough.

Let me offer some comments first. Actually, let's go through
the relevant parts of the makefile line by line.

| # TODO ?? Downloaded files should be validated before extracting.
| %.tar.bz2:
|       [ -e $@ ] || $(WGET) --non-verbose $(sf_mirror)/mingw/$@
|       $(BZIP2) --decompress --keep --force $@
|       $(TAR) --extract --file=$*.tar
|
| %.tar.gz:
|       [ -e $@ ] || $(WGET) --non-verbose $(sf_mirror)/mingw/$@
|       $(GZIP) --decompress --force $@
|       $(TAR) --extract --file=$*.tar

Factoring this out was a very good idea. In the most normal case,
the file named in the target is the result we're interested in,
but in this case, we want to update that file if necessary, then
produce side effects from it. That's OK, IMO, but it might be
better to document it because it is unusual: e.g.,

  # Download archives if they're out of date, then extract them.

The usual C paradigm--listing all the files you're ultimately
interested in--would be silly here, of course.

Factoring these things out also provides an answer to the likely
question "Why not use a script instead of a makefile?". What I
posted was just a script. When you start needing subroutines,
though, the script becomes nontrivial; an author's greater
familiarity with makefiles is a good enough reason to use one.

Now, actually, Paul's Second Rule of Makefiles is sort of violated
because gzip lacks a '--keep' option: the target file really is
updated, but it's destroyed and doesn't exist after the commands
are run. See this message:

http://groups.google.com/group/linux.debian.bugs.dist/msg/a20180e3f95906a1
| Quite frequently I want to compress or uncompress a file, but also keep
| the original file.  The usual way is "gzip < file > file.gz"

I'd have thought '--stdout' would be required for that "usual way",
but, one way or another, it probably helps address the problem.

It's nice to keep the original files. It's strange to test for
their existence on the first line, then destroy them in a later
command. Let's avoid that.

| # This provides the minimum requirements for building lmi with this compiler.

That comment wouldn't be wanted for a MinGW mailing-list
discussion, of course.

| .PHONY: mingw_current
| mingw_current:
|       $(MKDIR) --parents /tmp/$@
|       $(MAKE) \
|         -C /tmp/$@ \
|         -f $(src_dir)/setup.make \
|           mingw_dir='$(mingw_dir)' \
|             src_dir='$(src_dir)' \
|         install_mingw_current_from_tmp_dir

As part of a unified lmi makefile system, $(mingw_dir) and
$(src_dir) make sense. For a discussion with MinGW people, I
think you'd need to define them toward the top of the file.

| .PHONY: install_mingw_current_from_tmp_dir
| install_mingw_current_from_tmp_dir: $(mingw_requirements)
|       $(RM) --recursive *.tar

OK, clean up the intermediate '.tar' files: they're just clutter.
You couldn't get to the first command here if their contents
hadn't already been extracted. I'm just stating what anyone can
see; there's no need to document this.

|       $(MKDIR) --parents $(mingw_dir)
|       -$(CP) --force --parents --preserve --recursive * $(mingw_dir)

Unconditionally overwriting /MinGW/ seems like a bad idea. It's
not unlikely that a user had an old installation there. They
certainly would if they'd used an earlier verison of this
makefile. And overwriting it without first removing whatever's
already there could actually give a broken installation.
However, I suspect that you've prevented this by not allowing
the $(MKDIR) command to fail (it has no '-' prefix).

If I've understood that correctly, then everything's OK. Some
might suggest adding a line like:
        @[ -d $@ ] && echo $(mingw_dir) already exists.
but I think that's a waste of time. Anyone who has any business
running this can figure out the message that's already emitted
without your doing anything extra:

  \usr\bin\mkdir.EXE: cannot make directory `mingw_current/': File exists

and writing anything clearer is a lot of work. This might be
a topic for a FAQ someday.

If the downloaded archives are preserved, then you've already
got a way to 'refresh' the MinGW installation, without your
needing to do any extra work.

BTW, why use $(CP) here, and then $(RM) downstream--why not
just use $(MV) instead of those two steps? It sure would be
nice, as discussed above, to leave the downloaded files in
place, though; there's got to be a way to filter those out.
Wait--I've got it--use make's $(filter-out) function. Then
you'd keep the directory in /tmp/, and could delete this
command:

| # TODO ?? Keep this command blocked during testing to allow comparison
| # with sibling target.
| #     $(RM) --recursive *

But now I'm wondering whether /tmp/mingw/ is the place to
leave the downloaded files: anything in /tmp/ is fair game
for deletion. Instead, why not $(MV) everything in the
last command above, including the archives? Then start the
archive targets with something like [untested]:
        [ -e $(mingw_dir)/$@ ] && $(CP) $(mingw_dir)/$@ .