Re: [lmi] Cygwin build failure

[Greg Chicares]

[addressing one thing at a time]

On 2019-04-30 16:53, Vadim Zeitlin wrote:
> On Tue, 30 Apr 2019 15:43:47 +0000 Greg Chicares <address@hidden> wrote:
[...]
>  it's the innocently-looking 9afb0922 from 2019-04-14
> which renamed "scratch" directories -- but while renaming them, it also
> made the "ad_hoc" directory (BTW, I think "scratch" was a more descriptive
> name, I wonder why did it have to be changed) a subdirectory of $prefix,
> which resulted in the observed problem.

The commit message explains:

    Renamed 'scratch' to 'ad_hoc' because 'scratch' is too easily confused
    with 'stash'.

I understand that your mind works differently and you're immune to this
stash-scratch confusion, but for me it's very troublesome. After seeing
it again, I find it difficult to kill a zombie process that keeps going
"stitch"..."strep"..."strop"..."stretch"..."strip"...and of course:
  https://en.wikipedia.org/wiki/Stroop_effect

And I didn't want the old ./st^Hcratch showing up as a subdirectory
of /opt/lmi/src/lmi whenever I made certain targets. I decided that
using /tmp/ would make it too impermanent, in case we want to remake
some costly target with a small modification, so putting it in some
directory that would be removed only when we wanted to wipe out any
already-built binary files would be best. At least that seemed like
a good idea for 'install_wx.sh':
  build_dir="$prefix"/../wx-ad_hoc/lmi-gcc-$gcc_version
although for 'install_mingw' a good case could be made for using
/tmp/ instead, especially because that transient directory is
unconditionally removed as the last step:

all: $(file_list)
        $(CP) --archive $(ad_hoc_dir)/mingw32 $(prefix)
        $(RM) --force --recursive $(ad_hoc_dir)

> GC> Bonus question: what does
> GC>   $(MKDIR) --parents $(prefix)
> GC>   $(RM) --force --recursive $(prefix)
> GC> in that makefile do? I'm not sure, but I suppose mkdir is used
> GC> in an attempt to make the rm command safer.

That was indeed the reason. Searching with:

$git log -G'\$\(RM\) --force --recursive \$\(prefix\)' --patch
$git log -G'\$\(RM\) --force --recursive \$\(destination\)' --patch

finds this explanation:

-# It specifies the install directory explicitly because it seems
-# dangerous to write 'rm $(prefix)': someone might assign an
-# infelicitous value to that variable.
-# TODO ?? Yet
-#      @$(RM) --force --recursive $(prefix)
-# is written above.

The line referred to above was later removed (after a renaming)
with this explanation:

-# TODO ?? expunge: can't possibly be nonempty
-#      @$(RM) --force --recursive $(destination)

so I'll remove the corresponding rm line in this file.

> GC> If this is a good
> GC> idiom, then how should we document it so that I can understand it?
> GC> Otherwise, what should we replace it with?
> 
>  This makefile is just very confusing in general as it tests for clearly
> impossible things, e.g. it checks for ad_hoc_dir existence after ensuring
> that its parent directory does _not_ exist which is useless unless you're
> trying to protect against some race condition but if you are, then it's
> still useless, of course, because the directory might be created just after
> this check. And creating the directory before erasing it seems to fall into
> the same utility category.
> 
>  But I guess that the former might be a leftover from the time when
> ad_hoc_dir (n??e scratch_dir) wasn't a subdirectory of the prefix directory.
> For the latter I just don't have any explanation at all.

Yet we could do
  make prefix=/opt/lmi/whatever ad_hoc_dir=/tmp/something -f install_mingw.make
in which case the parentage is broken.