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

[Wendy Boutin]

Greg Chicares wrote:
> 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.

I think it's about ready for MinGW mailing list comments. I added a
new file to cvs for just the MinGW installation, although since then,
I've improved the inline documentation for 'wget' and removed a few
extra tool definitions that aren't needed. I'll commit that change
Monday morning.

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

[snip]

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

Actually, that "usual way" produced a zero byte file for me, and adding
'--stdout' sent my machine into an uncontrollable series of beeps. However,
I learned 'tar' has a '--gzip' option, which tells 'tar' to read or write
archives through 'gzip'; I couldn't get that to work though.

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

I think I remedied the problem by simply copying the archive to
'$(mingw_dir)' before extracting anything.

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

I'm a little unclear on this part. I've defined those directories
as you suggest, but I think they're still needed here in order to
keep the target self-contained. Is that what you were saying to do?

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

I purposely avoided overwriting /MinGW/, but I think I've made it fail
at a more appropriate time. Previously, everything was downloaded and
extracted before the target checked for /MinGW/'. Now, it checks for
the directory first.

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

Actually, I thought it was helpful to echo *why* in this way:
@$(ECHO) "Preserving your existing MinGW installation is strongly 
recommended."
Or are you just saying I'd be making too much of an obvious statement?

> 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

That directory is certainly different from /MinGW/, and I think its
okay to have an existing 'mingw_current/', but not /MinGW/.

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

I don't necessarily believe in that yet. The archives can't be looked
for in a directory that shouldn't exist yet, but if they're kept in
/tmp/, they're fair game for deletion as you suggest below.

Let's say the archives are kept in /tmp/ and you want to upgrade only
one of them. Since the other archives already exist, nothing will be
done to them (i.e., they don't get extracted again), but what if one
of those should be installed *after* the one you're trying to upgrade?
A broken installation could occur. Even worse, I think a new '/MinGW/'
will be made and it'll only contain the one upgraded archive because
we know nothing was done for the archives that already exist.

Refreshing the installation is more difficult than I anticipated, but
I was hoping the MinGW community may have a few suggestions about that.
I think they could benefit from this work before I got through that part.

> 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)/$@ .

Well, if 'mingw_dir' exists already, the target is going to fail
because I made it that way. So looking for the files in that
directory doesn't seem right, although I do believe the original
archive should be kept in 'mingw_dir' to make it easy to tell
which archives were used for that installation.

I think all archives for this target should be downloaded each time
a new installation or upgrade is wanted. That seems like a good
safeguard for preventing a broken installation, especially since
the order in which the files are extracted can make a difference.