Julien Lecomte wrote, quoting me:
>>> I just also thought of the fact that I have
>>> "MAKEFLAGS=--no-print-directory" by default on my systems; thus
>>> maybe that's why it was less clear to me.
>> I don't understand; why would that impact on the diagnostics resulting
>> from a failed attempt to run MSVC's lib command?
> With less verbose from make, out of the common messages tend to stand
> out; so I took the warning message as an error one.
> If the message had been drowned in "entering/leaving directory..."
> lines, I probably wouldn't have noticed it, or it wouldn't have been the
> last output from the make command and I wouldn't have thought much of
Ah, I see. I've formulated what I think is a fairly elegant way around
this, although I'd like to refine it a bit this weekend, before I commit.
What I propose is:--
1) Add an `--enable-msvc-implib' option to configure; give it a default
which is equivalent to `--disable-msvc-implib'.
2) Move the warning out of the Makefile, into configure; display it only
if the user specifies `--enable-msvc-implib' and `lib' isn't present.
3) Suppress the invocation of the rule to build the MSVC import lib, in
the generated Makefile, if `lib' isn't present, or if the user doesn't
This way, you will not see any MSVC related warnings from `make', ever
for this project, and the warning will be displayed at configure time,
only if you explicitly request building of an MSVC import library when
you do not have the appropriate tools installed.
As always with compromise, there is a disadvantage. In this case, users
who do want to build the MSVC import lib must request it specifically. I
think that's the right default behaviour, for a MinGW provided download,
but I could easily change it around, if there's an overwhelming demand
from you, the users, to have MSVC import libs built by default. The
price for that would be a warning message at configure time, when `lib'
isn't present, unless `--disable-msvc-implib' is explicitly specified.
So, if you care, please let me know which of these default behaviours you
would prefer. Unless you tell me otherwise, I'll commit on the basis I've
>> I don't understand what you mean by a `MinGW shell'. Do you mean
>> MSYS shell, used for native applications development with MinGW, as
>> opposed to the special shell environment required to compile MSYS
>> itself; i.e. the msysDVLPR environment?
> By 'MinGW shell', I mean an typical MSYS shell with MSYSTEM=MINGW32. I
> guess it's a misnomer.
Ok, thanks. That clarifies it. I guess the best way to differentiate
these two MSYS shell environments is to state, as you have done here,
what the MSYSTEM setting is, or what the `uname -s' output is.
>>> at least that's how it works with 'automake' ;>
>> It's how it works if I make config.h a prerequisite for all of the
>> project's object files. I don't need to use automake, to establish
>> that dependency, and as you may remember, I utterly loathe and detest
>> that particular autotool; throw away comments like this aren't going
>> to change my opinion of it.
> I do remember, thus the smiley in my comment.
Yeah, I'd guessed as much. FWIW, that dependency is now in CVS.