From: Keith M. <kei...@to...> - 2007-05-03 11:03:57
|
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 it. 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 specify `--enable-msvc-implib'. 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 outlined above. >> 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. Regards, Keith. |