2008/5/1 Keith Marshall <keithmarshall@...>:
> On Thursday 01 May 2008 08:26, Yongwei Wu wrote:
> > Portable to what? AFAIK, there are two `standards' for Make: the GNU
> > standard, and the POSIX standard. Also, if one checks big projects,
> > one will often see separate makefiles for different flavours of make,
> > because advanced features of make are never portable. I do not see
> > your point.
> The entire ethos of the autotools is to focus on creating scripts and
> makefiles which are as portable as practicably possible, to the widest
> possible spectrum of hosts, without reliance on *any* particular
> flavour of shell or make. Using case sensitive only distinctions in
> makefile rules violates this ethos, even with GNU make, for if you
> build it with the --enable-case-insensitive-file-system option, (which
> AFAIK, and correctly IMO, is the way the GNU make folks themselves
> recommend for use on Win32).
This is not my topic, since I do not use and do not like autotools.
However, do you have real examples that people use *GNU* autotools
with *non-GNU* make?
When I talked about `separate makefiles', I meant something like the
57 .mak files in STLport-4.6.2.
> This present discussion arose out of a problem in building autoconf,
> which uses an automake generated Makefile; it relies on being able to
> discriminate `install' and `INSTALL' as independent targets, which is
> impossible even for GNU make, when it is configured for a case
> insensitive file system. IMO, this violates the automake ethos, and is
> therefore a reportable bug; I fully intend to report it as such, when I
> have verified it for myself.
> > In fact, the current behaviour of MinGW Make 3.81 definitely breaks
> > makefiles designed for POSIX/UNIX/Linux systems, where cases matter.
> It doesn't, if the authors of those makefiles take appropriate care to
> avoid the pitfall of independent targets, which can be distinguished
> only with regard to case in their names; that's an easy objective to
Not if they did not think about it at all. I did not intend to
persuade you--unlikely to succeed, in my opinion--I just want to point
out that there are different ways of trade-off.
> Yongwei, I have a great deal of respect for both your opinion, and for
> Earnie's, but in this case you both seem to be blinkered by the not so
> very useful case preserving feature of the Win32 file system. Case
> preserving != case insensitive, and when you try to pretend otherwise,
> you break a case which is very much more difficult, if not actually
> impossible to fix, just to support an easily avoided usage, (IMO a
> *broken* usage), which isn't ever *really* necessary. Sorry, but I
> just don't see any rationale in that choice.
Again, I want to say I did not intend to persuade you. I just wanted
to express my opinions. In fact, I have the similar feelings about
you. The case-sensitiveness discussion of make is the only case I
remember about your being a little `unreasonable'. I guess it was
because we experienced different bites from it. If my memory serves
me correct, you were biten once by the case-insensitive file system;
and I was biten by the new case-insensitive make behaviour. MinGW
make 3.79 (again, not MSYS, which seems to be your impression) worked
very well for me.
And I use make for a slightly different purpose from you. I work
mostly on Windows, and when I use GCC, it is mostly for free software.
The current official version of make cannot prevent me from making a
mistake in case (if what happend to you once happend to me)--I would
rather check for errors myself than have other people complain that
the source tarball does not work on their systems. I am sure many
other people use GCC in a similar way.
> Sure, you have your reasons for wanting this feature, and even though I
> don't agree with you, I respect your right to a different choice; I
> support that right by providing csmake, and you are free to replace
> make with this, if you so prefer, but it remains my contention that the
> existing configuration of the distributed make-3.81 is the correct
> choice for general use.
How about a vote?
> Additionally, while the existing make-3.81 release of mingw32-make is
> entirely consistent with the current MSYS make-3.81, and we don't offer
> a corresponding mingw32-csmake, there is nothing to stop you building
> that for yourself; it builds OOTB, from current GNU sources, without
This is what I use. However, it only adds to my burden, since I do
not want my Makefile to work only for myself. I now often test with
different versions of make now.
> Right. I said I didn't want to reopen the old argument, yet here I am
> discussing it again. My opinion on the matter remains unchanged, so
> there really doesn't seem to be much more to be said. As I've said, I
> fully respect your right to hold a different opinion, and both cases
> are, IMO, adequately catered for. Let us simply agree to differ.
It is the third time I say I did not intend to persuade you. The only
point I want to add is that the official behaviour should be decided
by the MinGW community how they use MinGW tools, but not by
individuals like you and me.