Re: [lmi] Copying compiler run-time files in the makefiles

[Vadim Zeitlin]

On Tue, 28 Jun 2022 00:23:15 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 6/27/22 20:45, Vadim Zeitlin wrote:
GC> [...]
GC> > I am not sure I
GC> > understand why should build_dir depend on $(gpl_files)
GC> 
GC> $(build_dir) is a prerequisite for everything:
GC> 
GC> % :: $(build_dir) ; @:

 Ah, I've missed this, sorry. But it's still not totally clear to me how
does this work because, quoting GNU make manual[1]:

        One choice is to mark the match-anything rule as terminal by
        defining it with a double colon. When a rule is terminal, it does
        not apply unless its prerequisites actually exist. Prerequisites
        that could be made with other implicit rules are not good enough.
        In other words, no further chaining is allowed beyond a terminal
        rule. 

Doesn't this mean that $(build_dir) must already exist for this to work?

[1]: https://www.gnu.org/software/make/manual/make.html#Match_002dAnything-Rules

GC> and, therefore, so is anything it depends upon. Thus, without a copy of
GC> the GPL, you can't do anything. It's like a passe sanitaire.

 Touché.


GC> I'll try to specify the desired behavior here, in case you can see a
GC> better way to accomplish it. To run any msw binary, the compiler runtime
GC> libraries must be on $WINEPATH; specifically, $localbindir must contain
GC> copies of them.

 Sorry but I have to point that the implication indicated by the use of
semicolon here is not correct. You could also just add the directory
containing the files to WINEPATH, which is what I typically do and which
seems both simpler and more robust to me.

 Of course, you still need to include these DLLs in the binary distribution
of lmi, but this is something different.


On Tue, 28 Jun 2022 11:32:58 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> Other ideas that I considered and rejected:
GC> 
GC>  - Make the 'include' directives more promiscuous, so that 'GNUmakefile'
GC>    sees everything in 'compiler*.make'. It's already hard enough to
GC>    hide information in makefiles, but abandoning the attempt is wrong.
GC> 
GC>  - Move the installation of $(compiler_runtime_files) into 'workhorse.make'
GC>    (cloning the 'install:' target already present there to create a new
GC>    'install_compiler_runtime_files:'). Then, in 'GNUmakefile', change the
GC>    prerequisite-of-everything $(build_dir) target's recipe to invoke
GC>    "$(MAKE) install_compiler_runtime_files". I tried it; hilarity ensued,
GC>    because of infinite regression. (GNU make tries hard to avoid that,
GC>    but I tried harder to make '$(build_dir):' a prerequisite of everything,
GC>    including itself.)
GC> 
GC>  - Revert commit 19c09468c8. My untested conjecture is that then
GC>      make raze
GC>      make unit_tests
GC>    would fail, because this:
GC>      make install
GC>    would be necessary to install the compiler runtime files.

 FWIW I do agree with rejecting these ideas.

GC> AFAICS, the strategy now in HEAD is optimal despite its ugliness.

 It's fine, I guess, but it still seems unnecessarily complicated compared
to just setting WINEPATH to me.

GC> Let me mention the reasons for a couple of particulars:
GC>  - The 'install' command uses a shell for-loop, because
GC>    $(compiler_runtime_files) might be empty, and I see no
GC>    better way to deal with that possibility.

 The old (removed in the above-mentioned 19c09468c8) idea of simply using

        @[ -z "$(compiler_runtime_files)" ] || cp ...

seems better to me because it's both more clear (i.e. you can see at a
glance that the possibility of compiler_runtime_files being empty has been
considered and handled, instead of wondering whether it's normal for it to
be empty) and uses one cp command instead of N calls to it. But it's hardly
critically important, of course.

 Thanks again for fixing this,
VZ

pgpFvR6ue8F9L.pgp
Description: PGP signature