From: Yongwei W. <wuy...@gm...> - 2007-09-27 08:47:01
|
Hi gurus, I noticed a change between Make 3.79 and 3.81. In Make 3.79 I was able to do the following: --------------------------------------------------------------------- all: debug debug: DEBUG DEBUG/test.exe DEBUG: mkdir DEBUG DEBUG/test.exe: ... .PHONY: all debug --------------------------------------------------------------------- It worked well in Make 3.79. However, with 3.81 it will complain: make: Circular debug <- debug dependency dropped. While I understand it makes some sense on Windows, I doubt whether there is a way to improve the situation. Otherwise, one would not be able to name the target "debug" while having a build directory called "DEBUG", "Debug", or "DeBuG" ;-). Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Keith M. <kei...@to...> - 2007-09-27 09:38:44
|
Hi Yongwei, Good to hear from you again! Wu Yongwei wrote: > I noticed a change between Make 3.79 and 3.81. In Make 3.79 I was > able to do the following: > > --------------------------------------------------------------------- > all: debug > > debug: DEBUG DEBUG/test.exe > > DEBUG: > mkdir DEBUG > > DEBUG/test.exe: > ... > > .PHONY: all debug > --------------------------------------------------------------------- > > It worked well in Make 3.79. However, with 3.81 it will complain: > > make: Circular debug <- debug dependency dropped. This exploits what I have long considered to be a misconfiguration of make-3.79 in MSYS; make-3.81 has `--enable-case-insensitive-file-system' turned on, whereas make-3.79 did not. > While I understand it makes some sense on Windows, I doubt whether > there is a way to improve the situation. Otherwise, one would not be > able to name the target "debug" while having a build directory called > "DEBUG", "Debug", or "DeBuG" ;-). Since Woe32 employs a case-insensitive file system, it seems somehow wrong to not enable correct support for this within make. Indeed, it may well cause more serious problems than the above, if you arbitrarily ignore this OS level feature -- an extensive system of Makefiles, which I had developed under DJGPP, fell apart big-time when I tried to port it to MSYS, in the days when only make-3.79 was available. If you are writing Makefiles which you wish to be portable to systems with fundamentally case-insensitive file systems, such as Woe32, then it is dangerous to rely on case-sensitive behaviour in the Makefile rules. If you want to use a directory named with any case-insensitive variation of `debug', then don't use `debug' as a phony target; instead, you could use `all-debug', or some such alternative name. Regards, Keith. |
From: Yongwei W. <wuy...@gm...> - 2007-09-27 14:17:42
|
On 27/09/2007, Keith MARSHALL <kei...@to...> wrote: > > Hi Yongwei, > > Good to hear from you again! :-) > Wu Yongwei wrote: > > I noticed a change between Make 3.79 and 3.81. In Make 3.79 I was > > able to do the following: > > > > --------------------------------------------------------------------- > > all: debug > > > > debug: DEBUG DEBUG/test.exe > > > > DEBUG: > > mkdir DEBUG > > > > DEBUG/test.exe: > > ... > > > > .PHONY: all debug > > --------------------------------------------------------------------- > > > > It worked well in Make 3.79. However, with 3.81 it will complain: > > > > make: Circular debug <- debug dependency dropped. Yes, I understand your points below. However, I think it may be useful to differentiate the case-sensitiveness of files/directories and targets (esp. phony targets). The message above looks wrong to me. I mean, it is perfectly OK to believe the directory/file "DeBUG" matches the build target "DEBUG", but it may be overkill to think the target "debug" is equivalent to the target "DEBUG". Just wild thoughts. I did not look at the code of make, so it may be not be easily doable. > This exploits what I have long considered to be a misconfiguration of > make-3.79 in MSYS; make-3.81 has `--enable-case-insensitive-file-system' > turned on, whereas make-3.79 did not. > > > While I understand it makes some sense on Windows, I doubt whether > > there is a way to improve the situation. Otherwise, one would not be > > able to name the target "debug" while having a build directory called > > "DEBUG", "Debug", or "DeBuG" ;-). > > Since Woe32 employs a case-insensitive file system, it seems somehow > wrong to not enable correct support for this within make. Indeed, it > may well cause more serious problems than the above, if you arbitrarily > ignore this OS level feature -- an extensive system of Makefiles, which > I had developed under DJGPP, fell apart big-time when I tried to port > it to MSYS, in the days when only make-3.79 was available. > > If you are writing Makefiles which you wish to be portable to systems > with fundamentally case-insensitive file systems, such as Woe32, then it > is dangerous to rely on case-sensitive behaviour in the Makefile rules. > If you want to use a directory named with any case-insensitive variation > of `debug', then don't use `debug' as a phony target; instead, you could > use `all-debug', or some such alternative name. This is the current way I am doing. I changed the directory name instead. I wish it were not necessary. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Keith M. <kei...@to...> - 2007-09-27 15:46:06
|
Wu Yongwei wrote, quoting me: >> Wu Yongwei wrote: >>> I noticed a change between Make 3.79 and 3.81. In Make 3.79 I was >>> able to do the following: >>> >>> --------------------------------------------------------------------- >>> all: debug >>> >>> debug: DEBUG DEBUG/test.exe >>> >>> DEBUG: >>> mkdir DEBUG >>> >>> DEBUG/test.exe: >>> ... >>> >>> .PHONY: all debug >>> --------------------------------------------------------------------- >>> >>> It worked well in Make 3.79. However, with 3.81 it will complain: >>> >>> make: Circular debug <- debug dependency dropped. > > Yes, I understand your points below. However, I think it may be > useful to differentiate the case-sensitiveness of files/directories > and targets (esp. phony targets). Remember that, in the general case, a make target represents an entity which will *physically* exist within the file system; in other words, a make target *is* a file name, or a directory name. Thus, when there is no case sensitivity within the file system, it makes no sense to expect any such distinction within the make rules. > The message above looks wrong to me. > > I mean, it is perfectly OK to believe the directory/file "DeBUG" > matches the build target "DEBUG", but it may be overkill to think the > target "debug" is equivalent to the target "DEBUG". Do remember that a make prerequisite is just another target, which must be realised first. The message refers to debug: DEBUG ... i.e. the target `debug' has a prerequisite, which is another target called `DEBUG'. On a case-sensitive file system, these are indisputably different file system entities; hence distinct targets. On a case-insensitive file system, they are indistinguishable, hence the `debug' target depends on itself -- a (direct and immediate) circular dependency -- so I can't see anything wrong with the message. > Just wild thoughts. I did not look at the code of make, so it may be > not be easily doable. If it were to be done, it would have to be by the upstream GNU maintainers. For mingw32-make, we are now using their code OOTB, without modification. Chuck may have applied some minor patches for the MSYS build -- he can say with more authority than I -- but what you are suggesting would seem to go right to the heart of the beast, for it would require a fundamental change in the conceptual meaning of a make target. >> If you are writing Makefiles which you wish to be portable to systems >> with fundamentally case-insensitive file systems, such as Woe32, then it >> is dangerous to rely on case-sensitive behaviour in the Makefile rules. >> If you want to use a directory named with any case-insensitive variation >> of `debug', then don't use `debug' as a phony target; instead, you could >> use `all-debug', or some such alternative name. > > This is the current way I am doing. I changed the directory name > instead. I wish it were not necessary. I fear there is no logical way around it. Declaring the target `PHONY' doesn't magically imbue it with any special property which distinguishes it in any way from other targets, in terms of their relationship to the file system; all it does is tell make that the target must always be remade, even if the designated file system entity already exists, and appears to be up to date. If you want a very hackish workaround, you could rename make.exe as (say) make81.exe, restore the old make-3.79 as make79.exe, and write a driver script, called make, using some custom command line option, or an environment variable trigger, to pass its remaining arguments to either make79, when you want the case-sensitive behaviour, or to make81, when you want case-insensivity, or need new features. (If you want to have new features, *and* case-sensitivity together, then you would need to build a custom MSYS image of make-3.81). Regards, Keith. |
From: David L. <yak...@ya...> - 2007-09-27 17:56:42
|
--- Keith MARSHALL <kei...@to...> escribió: > > > > > Wu Yongwei wrote, quoting me: > >> Wu Yongwei wrote: > >>> I noticed a change between Make 3.79 and 3.81. In Make 3.79 I was > >>> able to do the following: > >>> > >>> --------------------------------------------------------------------- > >>> all: debug > >>> > >>> debug: DEBUG DEBUG/test.exe > >>> > >>> DEBUG: > >>> mkdir DEBUG > >>> > >>> DEBUG/test.exe: > >>> ... > >>> > >>> .PHONY: all debug > >>> --------------------------------------------------------------------- > >>> > >>> It worked well in Make 3.79. However, with 3.81 it will complain: > >>> > >>> make: Circular debug <- debug dependency dropped. > > > > Yes, I understand your points below. However, I think it may be > > useful to differentiate the case-sensitiveness of files/directories > > and targets (esp. phony targets). > > Remember that, in the general case, a make target represents an entity > which will *physically* exist within the file system; in other words, a > make target *is* a file name, or a directory name. Thus, when there is > no case sensitivity within the file system, it makes no sense to expect > any such distinction within the make rules. > In general case, but not for phony targets, as is stated in the gnu make manual. Then it would be nice that phony targets were able to be case sensitive, as Wu was saying. Greetings, David. ____________________________________________________________________________________ Sé un Mejor Amante del Cine ¿Quieres saber cómo? ¡Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html |
From: Charles W. <cwi...@us...> - 2007-09-28 00:53:39
|
Keith MARSHALL wrote: > If it were to be done, it would have to be by the upstream GNU maintainers. > For mingw32-make, we are now using their code OOTB, without modification. > Chuck may have applied some minor patches for the MSYS build -- he can say > with more authority than I -- but what you are suggesting would seem to go > right to the heart of the beast, for it would require a fundamental change > in the conceptual meaning of a make target. The make-3.81 package I uploaded differs from stock GNU sources in the following ways: (1) I imported all of the existing changes in cygwin's make-3.81 distribution. These mostly have to do with (a) storing runtime-allocated strings in a hashed database -- I presume for efficiency reasons (b) --unix/--win32 options. Looking at the patch, I see that these are now "supported" only to tell the user "don't use these options; they aren't supported any more" so I guess we could do away with those if we want, and (c) a few improvements in error handling. (2) The 2006-08-18 Eli Zaretskii patch to restore handling DOS-style pathnames (3) A slight modification to make's own Makefile.am to support running its testsuite while building make outside of its sourcetree (4) I also ran 'reautoconf -f -v -i' on the make source code. That's it. While it *might* [1] be appropriate to enable .PHONY targets to be case-sensitive, even if --case-insensitive-file-system, I do /not/ believe it is appropriate to turn off that option when dealing with the win32 platform. With the exception of cygwin's "managed mounts", the underlying file system is never case sensitive -- case preserving, yes. Pretending otherwise -- and distributing a make.exe which believes that falsehood -- can only lead to trouble. [1] but probably not. see below. > I fear there is no logical way around it. Declaring the target `PHONY' > doesn't magically imbue it with any special property which distinguishes > it in any way from other targets, in terms of their relationship to the > file system; all it does is tell make that the target must always be > remade, even if the designated file system entity already exists, and > appears to be up to date. Well, except that because make knows that the target is PHONY, the only use it has for a pre-existing file that might match its target name is to check its timestamp to see if the PHONY target's (non-PHONY?) dependencies themselves need to be remade. So, if you had .PHONY: DEBUG DEBUG: foo a-command and the filesystem contained 'dEbUg' with a timestamp newer than foo -- well, target foo will get remade even if it is "newer" than the non-existant DEBUG target, before 'a-command' is executed. So, on a case-insensitive file system, even PHONY targets are impacted by the underlying file system. Lying to make, or building a make executable that lives in a fantasy world where case-insensitive file systems are somehow sensitive to case, is just asking for trouble. It amazes me that we've lived with an insane make.exe for all this time, and are so used to it that people are begging to be let back in to the funny farm. -- Chuck |
From: Yongwei W. <wuy...@gm...> - 2007-09-28 01:44:09
|
Hi Keith, David, Charles, Thanks for all the responses. I really appreciate them. I may live with the current status, but I feel puzzled by some of Charles' comments. On 28/09/2007, Charles Wilson <cwi...@us...> wrote: [snipped] > > I fear there is no logical way around it. Declaring the target `PHONY' > > doesn't magically imbue it with any special property which distinguishes > > it in any way from other targets, in terms of their relationship to the > > file system; all it does is tell make that the target must always be > > remade, even if the designated file system entity already exists, and > > appears to be up to date. > > Well, except that because make knows that the target is PHONY, the only > use it has for a pre-existing file that might match its target name is > to check its timestamp to see if the PHONY target's (non-PHONY?) > dependencies themselves need to be remade. > > So, if you had > .PHONY: DEBUG > > DEBUG: foo > a-command > > and the filesystem contained 'dEbUg' with a timestamp newer than foo -- > well, target foo will get remade even if it is "newer" than the > non-existant DEBUG target, before 'a-command' is executed. I do not understand this. On phony targets from the make info page: "When it is time to consider such a target, `make' will run its commands unconditionally, regardless of whether a file with that name exists or what its last modification time is." I can't get your points, and I can't see why foo will be remade in any case. > So, on a case-insensitive file system, even PHONY targets are impacted > by the underlying file system. So I have not seen this point proved yet. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Earnie B. <ea...@us...> - 2007-09-28 11:44:15
|
Quoting Charles Wilson <cwi...@us...>: > > While it *might* [1] be appropriate to enable .PHONY targets to be > case-sensitive, even if --case-insensitive-file-system, I do /not/ > believe it is appropriate to turn off that option when dealing with the > win32 platform. With the exception of cygwin's "managed mounts", the > underlying file system is never case sensitive -- case preserving, yes. > Pretending otherwise -- and distributing a make.exe which believes > that falsehood -- can only lead to trouble. > IMO, --case-insensitive-file-system should not be used for the MSYS build of make. The reason is that we are trying to allow the creature comforts of POSIX as much as possible for ``configure && make'' and this switch doesn't allow for the creature comfort. > > Lying to make, or building a make executable that lives in a fantasy > world where case-insensitive file systems are somehow sensitive to case, > is just asking for trouble. > > It amazes me that we've lived with an insane make.exe for all this time, > and are so used to it that people are begging to be let back in to the > funny farm. > Cygwin began the lie years ago. I can see why things are broken because of this --case-insensitive-file-system switch so I am not at all amazed. IMO, we need to continue the lie or at least allow for the lie at runtime with a runtime parameter. Earnie |
From: Keith M. <kei...@us...> - 2007-09-28 16:44:31
|
On Fri, 2007-09-28 at 07:44 -0400, Earnie Boyd wrote: > > Quoting Charles Wilson <cwi...@us...>: > > > > > While it *might* [1] be appropriate to enable .PHONY targets to be > > case-sensitive, even if --case-insensitive-file-system, I do /not/ > > believe it is appropriate to turn off that option when dealing with the > > win32 platform. With the exception of cygwin's "managed mounts", the > > underlying file system is never case sensitive -- case preserving, yes. > > Pretending otherwise -- and distributing a make.exe which believes > > that falsehood -- can only lead to trouble. > > > > IMO, --case-insensitive-file-system should not be used for the MSYS > build of make. The reason is that we are trying to allow the creature > comforts of POSIX as much as possible for ``configure && make'' and > this switch doesn't allow for the creature comfort. Well then, we have a fundamental difference of opinion, for I am in full agreement with Chuck on this. > > Lying to make, or building a make executable that lives in a fantasy > > world where case-insensitive file systems are somehow sensitive to case, > > is just asking for trouble. And boy, don't you get it! The MSYS build of make-3.79.1 is *broken*; I've discussed some of the issues in the past. You, (Earnie), offered some suggestions on how to work around those issues, (*none* of which worked BTW); my system of Makefiles, which had worked flawlessly on MS-DOS/Win95 with DJGPP, absolutely refused to work un Win2K with MSYS make-3.79.1; the cause of failure was *always* attributable to a mismatch between case in a Makefile rule, and case in the *real* target file name, where `case-insensitive-file-system' would have eliminated the problem, at a stroke. > > It amazes me that we've lived with an insane make.exe for all this time, > > and are so used to it that people are begging to be let back in to the > > funny farm. > > Cygwin began the lie years ago. I can see why things are broken > because of this --case-insensitive-file-system switch so I am not at > all amazed. I can't remember whether I found the same problem with Cygwin's make, or not, and I'm not able to investigate at the moment. I begged you to fix MSYS make, at the time, and you didn't; I solved my problem with a native build, with `case-insensitive-file-system' enabled. > IMO, we need to continue the lie or at least allow for the > lie at runtime with a runtime parameter. I'm not convinced that we need to perpetuate the lie, at all. If there is sufficient demand, we could offer a separate (broken) build, with `case-insensitive-file-system' disabled, (and with a distinctively different executable name). IMO, Chuck's recent make-3.81 build, with `case-insensitive-file-system' *enabled*, should be the default. Regards, Keith. |
From: Suresh G. <sgo...@ya...> - 2007-09-28 17:09:14
|
Regarding case sensitivity, cp behaves as expected but diff does not: $ mkdir a $ mkdir b $ cd a $ echo hello > foo $ cp foo ../b/FOO $ cd .. $ diff -sqr a b Only in b: FOO Only in a: foo $ cp -i a/foo b cp: overwrite `b/foo'? n $ diff --version diff - GNU diffutils version 2.7 $ which diff /bin/diff $ which cp /bin/cp |
From: Keith M. <kei...@us...> - 2007-09-28 16:44:16
|
On Fri, 2007-09-28 at 09:44 +0800, Yongwei Wu wrote: > > Well, except that because make knows that the target is PHONY, the > > only use it has for a pre-existing file that might match its target > > name is to check its timestamp to see if the PHONY target's > > (non-PHONY?) dependencies themselves need to be remade. > > > > So, if you had > > .PHONY: DEBUG > > > > DEBUG: foo > > a-command > > > > and the filesystem contained 'dEbUg' with a timestamp newer than > > foo -- well, target foo will get remade even if it is "newer" than > > the non-existant DEBUG target, before 'a-command' is executed. > > I do not understand this. No, I don't either, so I tried this (on Ubuntu 6.10, where there is no issue with case-sensitivity anyway): $ uname -a Linux ... 2.6.15-26-386 #1 PREEMPT Fri Sep 8 2006 i686 GNU/Linux $ cat Makefile .PHONY: all all: foo foo: touch foo clean: rm -f foo $ make clean rm -f foo $ make touch foo $ make make: Nothing to be done for `all'. Ok, nothing unexpected there; let's try: $ touch all so, we now have a real `all' corresponding to phony target, and it's newer than `foo', because it's already a couple of minutes since I made that. However, I still see: $ make make: Nothing to be done for `all'. so, Chuck's notion that the newer `all' file, corresponding to the phony target of the same name, (identically here), will cause `foo' to be remade doesn't seem to hold true; indeed it would appear to contradict: > On phony targets from the make info page: > > "When it is time to consider such a target, `make' will run its > commands unconditionally, regardless of whether a file with that name > exists or what its last modification time is." > > I can't get your points, and I can't see why foo will be remade in any > case. No, I don't believe that it will be. > > So, on a case-insensitive file system, even PHONY targets are > > impacted by the underlying file system. > > So I have not seen this point proved yet. Nope. I rather think I've just disproved this aspect of it. But then David Lucena wrote, quoting me: > > Remember that, in the general case, a make target represents an > > entity which will *physically* exist within the file system; in > > other words, a make target *is* a file name, or a directory name. > > Thus, when there is no case sensitivity within the file system, it > > makes no sense to expect any such distinction within the make rules. > > In general case, but not for phony targets, as is stated in the gnu > make manual. Then it would be nice that phony targets were able to be > case sensitive, as Wu was saying. Ok, we'll forgive him for his formal use of your family name, instead of your given name, as we prefer on this list, but let's explore my little example a bit further; look what happens here: $ make clean rm -f foo $ make touch foo So what? Nothing unexpected there either. But look at this: $ touch clean $ make clean make: `clean' is up to date. Huh? Not what we wanted, eh? Ok, you say; "`clean' isn't declared as a phony target; you can fix that by adding that declaration". Well, yes, but the special meaning of .PHONY is a GNU make feature; it is not universally supported. Look what happens with the same example, so modified, on a Solaris box: $ uname -a SunOS ... 5.5.1 Generic_103640-20 sun4m sparc SUNW,SPARCstation-5 $ cat Makefile .PHONY: all all: foo foo: touch foo .PHONY: clean clean: rm -f foo $ make clean rm -f foo $ make touch foo $ touch clean $ make clean `clean' is up to date. Not so clever, huh? The bottom line is, if you want to write portable code, (and who doesn't, given the choice?), then you've got to recognise the least common denominator of the target systems. That means that you've got to be prepared to accommodate the case-insensitive behaviour of some file systems, and *never* rely on case distinction alone, under any circumstances. You cannot ever rely on .PHONY either, to pull you out of the hole when you've stupidly ignored this, because that too is simply not portable. So, back to Chuck's closing comments: > Lying to make, or building a make executable that lives in a fantasy > world where case-insensitive file systems are somehow sensitive to > case, is just asking for trouble. I agree, 100%. > It amazes me that we've lived with an insane make.exe for all this > time, and are so used to it that people are begging to be let back in > to the funny farm. And I, for one, have no desire to return to that lunatic asylum. Regards, Keith. |
From: David L. <yak...@ya...> - 2007-09-28 17:01:54
|
--- Keith Marshall <kei...@us...> escribió: > > > So, on a case-insensitive file system, even PHONY targets are > > > impacted by the underlying file system. > > > > So I have not seen this point proved yet. > > Nope. I rather think I've just disproved this aspect of it. But then > David Lucena wrote, quoting me: > > > > Remember that, in the general case, a make target represents an > > > entity which will *physically* exist within the file system; in > > > other words, a make target *is* a file name, or a directory name. > > > Thus, when there is no case sensitivity within the file system, it > > > makes no sense to expect any such distinction within the make rules. > > > > In general case, but not for phony targets, as is stated in the gnu > > make manual. Then it would be nice that phony targets were able to be > > case sensitive, as Wu was saying. > > Ok, we'll forgive him for his formal use of your family name, instead of > your given name, as we prefer on this list, but let's explore my little > example a bit further; look what happens here: Sorry, but I don't understand this part. What did I do wrong? ____________________________________________________________________________________ Sé un Mejor Amante del Cine ¿Quieres saber cómo? ¡Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html |
From: Keith M. <kei...@us...> - 2007-09-28 17:28:18
|
On Fri, 2007-09-28 at 19:01 +0200, David Lucena wrote: > > Ok, we'll forgive him for his formal use of your family name, > > instead of your given name, as we prefer on this list, but let's > > explore my little example a bit further; look what happens here: > > Sorry, but I don't understand this part. What did I do wrong? Yongwei is Chinese; their culture places the family name first, and the given name, (equivalent to the Christian name of our Western cultures), *after* it, so Wu is his family name, or surname, and you addressing him as `Wu' is similar to me addressing you as `Lucena'; just a bit more formal than we are accustomed to here. Regards, Keith. |
From: Eric W. <ewe...@cs...> - 2007-09-28 18:58:23
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf > Of Keith Marshall > Sent: Friday, September 28, 2007 10:44 AM > To: MinGW Users List > Subject: Re: [Mingw-users] Case sensitiveness, Make 3.79, and > Make 3.81 > > IMO, Chuck's recent make-3.81 build, with > `case-insensitive-file-system' *enabled*, should be the default. It's got my vote, if anyone's counting. Stop the insanity! *ahem* |
From: Charles W. <cwi...@us...> - 2007-09-28 20:23:51
|
Keith Marshall wrote: > so, Chuck's notion that the newer `all' file, corresponding to the phony > target of the same name, (identically here), will cause `foo' to be > remade doesn't seem to hold true; indeed it would appear to contradict: Sorry -- it looks like I misanalyzed the code. I should have done what Keith did and just tested the proposition in actual practice. An ounce of experience beats a pound of theory, every time. [and on that point, see zlib example, below...] However, given the remainder of Keith's examples, I still /believe/ that while I was wrong on the specifics I was right on the generality: make -- even on MSYS *and* on cygwin [1] -- should not pretend the underlying filesystem is case-sensitive when it actually isn't. [1] cygwin: it is true that the make-3.81 distributed by cygwin pretends to be case sensitive. The only excuse for that, IMO, is the following: (a) most of the time, open-source projects are not so short-sighted as to rely on case sensitivity to distinguish files and targets -- so cygwin-make's insanity doesn't actually hurt anything. (b) in those rare cases where they do, and it is not feasible to patch the Makefile[.in|am] (and send that patch upstream), cygwin provides the "managed mount" feature to simulate case-sensitivity. If cygwin's make did not at least pretend to case-sensitivity, then the workaround for problematic packages mentioned in (b) would not be possible. The cygwin team made the decision that the potential for confusion in distributing a make that is insane (e.g. believes in non-truth) is outweighed by the advantages allowed when using managed mounts. As MSYS does not provide managed mounts, that rationale is unsupportable for the msys version of make. Regarding Earnie's post: > IMO, --case-insensitive-file-system should not be used for the MSYS > build of make. The reason is that we are trying to allow the creature > comforts of POSIX as much as possible for ``configure && make'' and > this switch doesn't allow for the creature comfort. It is not a creature comfort if you have two non-PHONY targets: DEBUG: touch DEBUG debug: touch debug that clobber each other. Actually, I've seen the old make cause problems with old zlib distributions (1.1.3?): zlib used to rely on case distinction between .s and .S files -- I believe one was "original" assembly code and the other was "post-processed" assembly code, but the details are fuzzy. The zlib folks eventually realized that case-dependency was not the Tao of Cross Platform, and changed their build process. Up to that point, I always had to patch the zlib makefile myself... BTW, this is not just a Windows problem. Many embedded systems use (case-insensitive, non-case-preserving) FAT filesystems even if they themselves have nothing to do with MSDOS or Windows. FAT is just a very inexpensive (in terms of disk space overhead AND code size), dirt-simple filesystem which makes it convenient for the relatively modest needs and space constraints of many embedded systems. True, you don't ordinarily USE that filesystem when building software -- such as libz.a -- for the embedded target, but still... -- Chuck |
From: Yongwei W. <wuy...@gm...> - 2007-09-29 05:26:26
|
On 28/09/2007, Keith Marshall <kei...@us...> wrote: > $ uname -a > SunOS ... 5.5.1 Generic_103640-20 sun4m sparc SUNW,SPARCstation-5 > > $ cat Makefile > .PHONY: all > all: foo > > foo: > touch foo > > .PHONY: clean > clean: > rm -f foo > > $ make clean > rm -f foo > > $ make > touch foo > > $ touch clean > > $ make clean > `clean' is up to date. > > Not so clever, huh? The bottom line is, if you want to write portable > code, (and who doesn't, given the choice?), then you've got to recognise > the least common denominator of the target systems. That means that > you've got to be prepared to accommodate the case-insensitive behaviour > of some file systems, and *never* rely on case distinction alone, under > any circumstances. You cannot ever rely on .PHONY either, to pull you > out of the hole when you've stupidly ignored this, because that too is > simply not portable. Is it the GNU Make? I doubt. I never intend to make my Makefiles to work on different flavours of Make. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Yongwei W. <wuy...@gm...> - 2007-09-29 05:44:56
|
On 29/09/2007, Charles Wilson <cwi...@us...> wrote: > Keith Marshall wrote: > > > so, Chuck's notion that the newer `all' file, corresponding to the phony > > target of the same name, (identically here), will cause `foo' to be > > remade doesn't seem to hold true; indeed it would appear to contradict: > > Sorry -- it looks like I misanalyzed the code. I should have done what > Keith did and just tested the proposition in actual practice. An ounce > of experience beats a pound of theory, every time. [and on that point, > see zlib example, below...] > > However, given the remainder of Keith's examples, I still /believe/ that > while I was wrong on the specifics I was right on the generality: make > -- even on MSYS *and* on cygwin [1] -- should not pretend the underlying > filesystem is case-sensitive when it actually isn't. *I* did not say it should (though I do not think it bad; see bottom of my message). However, please notice that your statement "even PHONY targets are impacted by the underlying file system" is not true. > [1] cygwin: it is true that the make-3.81 distributed by cygwin pretends > to be case sensitive. The only excuse for that, IMO, is the following: > > (a) most of the time, open-source projects are not so short-sighted as > to rely on case sensitivity to distinguish files and targets -- so > cygwin-make's insanity doesn't actually hurt anything. > > (b) in those rare cases where they do, and it is not feasible to patch > the Makefile[.in|am] (and send that patch upstream), cygwin provides the > "managed mount" feature to simulate case-sensitivity. Cygwin is intended to emulate Unix behaviour. When the Makefile contains rules like what I originally presented, which did not require the file system to be case-sensitive, it *should* work with any complaints. > If cygwin's make did not at least pretend to case-sensitivity, then the > workaround for problematic packages mentioned in (b) would not be > possible. The cygwin team made the decision that the potential for > confusion in distributing a make that is insane (e.g. believes in > non-truth) is outweighed by the advantages allowed when using managed > mounts. > > As MSYS does not provide managed mounts, that rationale is unsupportable > for the msys version of make. I can argue that MSYS is exactly like the Cygwin case. I may even further argue the native Win32 Make should work the same way as expected in my example, since, *ahem*, the Unix principle never prevents one from shooting on his feet. As a tool, its duty is to do its job as the *user* expects, when possible. Don't say we are on Windows. GNU is Unix! This said, I think making phony targets different from file targets is the most ideal way. Since I am not planning to spend the labour myself right now, I won't insist here it must be done. I am still ready to argue whether it is the best way :-). > Regarding Earnie's post: > > IMO, --case-insensitive-file-system should not be used for the MSYS > > build of make. The reason is that we are trying to allow the creature > > comforts of POSIX as much as possible for ``configure && make'' and > > this switch doesn't allow for the creature comfort. > > It is not a creature comfort if you have two non-PHONY targets: > > DEBUG: > touch DEBUG > > debug: > touch debug > > that clobber each other. Agreed on this part. However, whatever way Make behaves in this example, the user has to modify his make rules. Making Make case-insensitive does not bring the user real benefits! *Are we expecting the user to (be able to) write Debug when he wants DEBUG?* This looks to me the current --case-insensitive-file-system is doing. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Yongwei W. <wuy...@gm...> - 2007-09-29 05:51:28
|
On 29/09/2007, Suresh Govindachar <sgo...@ya...> wrote: > > Regarding case sensitivity, cp behaves as expected but diff does not: > > $ mkdir a > $ mkdir b > $ cd a > $ echo hello > foo > $ cp foo ../b/FOO > $ cd .. > $ diff -sqr a b > Only in b: FOO > Only in a: foo > $ cp -i a/foo b > cp: overwrite `b/foo'? n > > > $ diff --version > diff - GNU diffutils version 2.7 > $ which diff > /bin/diff > $ which cp > /bin/cp "cp" does not need to be case-insensitive to do the job. It is completely the OS stuff. One may argue that FOO and foo are still different files, and may be worth highlighting by "diff". This said, I think people simply never modified the code in this aspect. Anyway, MinGW does not distribute these tools, so it is a little off-topic. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Keith M. <kei...@us...> - 2007-09-29 07:50:34
|
On Sat, 2007-09-29 at 13:51 +0800, Yongwei Wu wrote: > One may argue that FOO and foo are still different files ... No, one may not; not when the file system is case insensitive, as it is with Woe32 -- they are *unequivocally* the same file! If diff thinks otherwise, then that is a bug in diff. And, since this started out as a discussion on case sensitivity in make... Yongwei, you once told me there is no point in disputing fact; yet here you are, doing just that. It is fact that Woe32's file system is case insensitive. It is fact that GNU make has a feature to support its use with such file systems. It is fact that, when that feature is enabled, its rule naming conventions become case insensitive for *all* targets. You must adapt your expectations and practise, to conform with fact; argument is futile. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2007-09-29 12:45:56
|
Quoting Keith Marshall <kei...@us...>: --8<-- > > And, since this started out as a discussion on case sensitivity in > make... > --8<-- > You must adapt your expectations and practise, to conform with fact; > argument is futile. > Fact: I want tools that pay attention to the case of its arguments and commands even in a case insensitive file system. Argument to this fact is futile. Fact: You want tools that do not pay attention to the case of its arguments and commands especially in a case insensitive file system. Argument to this fact is futile. Given these two facts we must agree to compromise. The best compromise I've seen offered in this thread was to include a runtime switch or environment setting to control its operation. I have strong opinions that tools that allow the user to misuse the case insensitive file system fact are broken. Therefore the tools so far have considered foo != FOO even though the file system thinks so. I can agree to the above compromise however because I can still therefore enforce my opinion while at the same time you can enforce your opinion. Earnie |
From: Keith M. <kei...@us...> - 2007-09-29 15:05:10
|
On Sat, 2007-09-29 at 08:45 -0400, Earnie Boyd wrote: > Fact: I want tools that pay attention to the case of its arguments and > commands even in a case insensitive file system. Argument to this > fact is futile. IMO, your logic is flawed. The file system *is* case insensitive; any tool which believes that it can change this fundamental reality, by *pretending* that it is otherwise, is broken. This isn't an argument against the fact. That you *want* the broken behaviour is your choice; you are welcome to collect as many broken pieces as you wish. > Fact: You want tools that do not pay attention to the case of its > arguments and commands especially in a case insensitive file system. > Argument to this fact is futile. No, this is not what I want, at all. What I want is tools which DTRT, whether the file system is case sensitive or not. I recognise that some file systems are case sensitive and some are not; I adapt my working practices to accommodate both. MSYS make-3.79.1 has never completely done TRT, simply because it has refused to understand that it has no choice but to recognise that it has got to work with a case insensitive file system; Chuck's build of make-3.81 has corrected that deficiency. > Given these two facts we must agree to compromise. Sure. Life is all about compromise; I don't have any problem here. > The best compromise I've seen offered in this thread was to include a > runtime switch or environment setting to control its operation. The best compromise is simply to provide two separate builds, one offering each behaviour, and you choose whichever you prefer. If you can't decide, you can always install both, with two distinct names for the executables, then use say `csmake' for your pseudo-case-sensitive version, or `cimake' for the case-insensitive. Why make it any more complex? If you really want a `--case-sensitivity=on|off' switch, a simple wrapper script can provide it -- and it can check for a default set via the environment. IMO however, that's just overkill. > I have strong opinions that tools that allow the user to misuse the > case insensitive file system fact are broken. Yet, you argue the case for providing the broken tool, in preference to the sane! > Therefore the tools so far have considered foo != FOO even though the > file system thinks so. The file system, by definition, *must* be correct! The tools which pretend otherwise are broken. > I can agree to the above compromise however because I can still > therefore enforce my opinion while at the same time you can enforce > your opinion. It isn't about enforcement; it is about choice. I can happily agree to this compromise because it allows you to have the behaviour you prefer, no matter how insane I consider your choice, while I too can have what I consider correct, even if you think I am crazy. Chuck, I haven't figured out how to cross-compile MSYS components on a GNU/Linux build machine; could you please prepare an alternative build with `--disable-case-insensitive-file-system', for the lunatics who wish to stay in the asylum? I'm open to suggestions as to what this should be called; I still believe that `--enable-case-insensitive-file-system' should remain the default deliverable, and this alternative optional. Regards, Keith. |
From: Charles W. <cwi...@us...> - 2007-09-29 16:23:49
|
Keith Marshall wrote: > Chuck, I haven't figured out how to cross-compile MSYS components on a > GNU/Linux build machine; could you please prepare an alternative build > with `--disable-case-insensitive-file-system', for the lunatics who wish > to stay in the asylum? I'm open to suggestions as to what this should > be called; I still believe that `--enable-case-insensitive-file-system' > should remain the default deliverable, and this alternative optional. Done. Added to "Snapshot|MSYS" as "csmake-3.81-MSYS-1.0.11-1". This package contains the following two files: /usr/bin/csmake.exe usr/share/man/man1/csmake.1 ====================================================== csmake(1) csmake man page csmake(1) NAME csmake DESCRIPTION csmake is a case-sensitive version of GNU make. While the win32 file systems encountered when using MSYS software are invariably case-INsen- sitive, some users prefer a GNU `make' that itself is case-sensitive -- hence this version of make is made available. The default `make' provided by MSYS is case-INsensitive, as befits the case-INsensitive nature of the underlying filesystem. 29 Sep 2007 MSYS csmake(1) ====================================================== While I was there, I removed the make-3.81*snapshot version. BTW, GNU make's configure.in is messed up with respect to case-insensitive-filesystem. If you say: --enable-case-insensitive-file-system --disable-case-insensitive-file-system --enable-case-insensitive-file-system=no you get the same result every time: '#define HAVE_CASE_INSENSITIVE_FS 1' The only way to ctually get a case-sensitive make is to NOT mention case-insensitive-file-system in ANY way, when configuring. Odd, huh? -- Chuck |
From: Suresh G. <sgo...@ya...> - 2007-09-29 16:29:48
|
Keith Marshall wrote: > On Sat, 2007-09-29 at 08:45 -0400, Earnie Boyd wrote: > >> Fact: I want tools that pay attention to the case of its >> arguments and commands even in a case insensitive file system. >> Argument to this fact is futile. > > IMO, your logic is flawed. The file system *is* case > insensitive; any tool which believes that it can change this > fundamental reality, by *pretending* that it is otherwise, is > broken. This isn't an argument against the fact. That you > *want* the broken behaviour is your choice; you are welcome to > collect as many broken pieces as you wish. One doesn't judge metaphysical facts such as gravity or a mountain -- these are neither right nor wrong, they just are. In contrast, man-made facts such as buildings and opinions can be right or wrong and should be judged. Keith is arguing that Ernie's desire is in a context (of case insensitive filesystem) that does not warrant such a desire. >> Fact: You want tools that do not pay attention to the case of >> its arguments and commands especially in a case insensitive >> file system. Argument to this fact is futile. > > No, this is not what I want, at all. What I want is tools which > DTRT, whether the file system is case sensitive or not. Good -- here Keith argues that his opinion is not arbitrary but is based on some fundamental principle (DTRT). > I recognise that some file systems are case sensitive and some > are not; I adapt my working practices to accommodate both. MSYS > make-3.79.1 has never completely done TRT, simply because it has > refused to understand that it has no choice but to recognise > that it has got to work with a case insensitive file system; > Chuck's build of make-3.81 has corrected that deficiency. > >> Given these two facts we must agree to compromise. > > Sure. Life is all about compromise; I don't have any problem > here. > >> The best compromise I've seen offered in this thread was to >> include a runtime switch or environment setting to control its >> operation. Below, Keith properly recognizes that a runtime switch/setting will not resolve the disagreement -- a runtime switch/setting will just move the disagreement to what should be the default behavior. > The best compromise is simply to provide two separate builds, > one offering each behaviour, and you choose whichever you > prefer. If you can't decide, you can always install both, with > two distinct names for the executables, then use say `csmake' > for your pseudo-case-sensitive version, or `cimake' for the > case-insensitive. Why make it any more complex? If you really > want a `--case-sensitivity=on|off' switch, a simple wrapper > script can provide it -- and it can check for a default set via > the environment. IMO however, that's just overkill. > >> I have strong opinions that tools that allow the user to misuse >> the case insensitive file system fact are broken. > > Yet, you argue the case for providing the broken tool, in > preference to the sane! So: Earnie has "strong opinions that tools that allow the user to misuse the case insensitive file system fact are broken" and yet he wants a make that misuses the case insensitive file system (by pretending that the file system is not case insensitive). >> Therefore the tools so far have considered foo != FOO even >> though the file system thinks so. > > The file system, by definition, *must* be correct! The tools > which pretend otherwise are broken. > >> I can agree to the above compromise however because I can still >> therefore enforce my opinion while at the same time you can >> enforce your opinion. > > It isn't about enforcement; it is about choice. I can happily > agree to this compromise because it allows you to have the > behaviour you prefer, no matter how insane I consider your > choice, while I too can have what I consider correct, even if > you think I am crazy. My understanding of the purpose of MinGW is that it is for porting applications such as vim, cdrtools, rsync, ctags, global, gnuplot, perl etc. to OSes such as windows while using the native libraries of the target OSes -- with the resulting application working just like any other application for that OS. (The purpose of MinGW is _not_ to build MSYS applications -- in fact, MinGW can be used without MSYS; the purpose of MinGW is not to team up with MSYS and become some type of VMWare.) Doesn't the purpose of MinGW clearly dictate that make be case insensitive? Consider the example Keith gave in a recent post: KM> No, I don't expect people to write their makefiles in such KM> an inconsistent manner. However, I *do* expect: KM> KM> $ cat Makefile KM> : KM> %.txt: %.app KM> tcsmake $<,$@,libforth.txt\; KM> : KM> KM> $ make totheat.txt KM> KM> to work, when totheat.app exists on disk, (even though it KM> may have come from an original legacy MS-DOS system, its KM> real name on disk is actually TOTHEAT.APP, and to compound KM> the confusion Win95-Explorer showed it as Totheat.app). > Chuck, I haven't figured out how to cross-compile MSYS > components on a GNU/Linux build machine; could you please > prepare an alternative build with > `--disable-case-insensitive-file-system', for the lunatics who > wish to stay in the asylum? I'm open to suggestions as to what > this should be called; I still believe that > `--enable-case-insensitive-file-system' should remain the > default deliverable, and this alternative optional. There needs to be a decision for the following too: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1804659&group_id=2435 --Suresh |
From: Earnie B. <ea...@us...> - 2007-09-29 18:18:48
|
Quoting Keith Marshall <kei...@us...>: > On Sat, 2007-09-29 at 08:45 -0400, Earnie Boyd wrote: >> Fact: I want tools that pay attention to the case of its arguments and >> commands even in a case insensitive file system. Argument to this >> fact is futile. > > IMO, your logic is flawed. The file system *is* case insensitive; any > tool which believes that it can change this fundamental reality, by > *pretending* that it is otherwise, is broken. This isn't an argument > against the fact. That you *want* the broken behaviour is your choice; > you are welcome to collect as many broken pieces as you wish. > The Makefile creator [TMC] presents the tool with commands that look for files on the disk. TMC expects that the file names in a case preserving, case insensitive file system to be found exactly as stated. If TMC wants to search for files regardless of case the TMC can create target and dependency patterns that search in case insensitive ways. >> Fact: You want tools that do not pay attention to the case of its >> arguments and commands especially in a case insensitive file system. >> Argument to this fact is futile. > > No, this is not what I want, at all. What I want is tools which DTRT, > whether the file system is case sensitive or not. I recognise that some > file systems are case sensitive and some are not; I adapt my working > practices to accommodate both. MSYS make-3.79.1 has never completely > done TRT, simply because it has refused to understand that it has no > choice but to recognise that it has got to work with a case insensitive > file system; Chuck's build of make-3.81 has corrected that deficiency. > So now with case insensitive targets and dependencies enforced regardless, TMC has no opportunity to make certain that his files will remain case preserved as he desires. But you have your desire to take makefiles written for DOS 8.3 and have the work out of the box. >> Given these two facts we must agree to compromise. > > Sure. Life is all about compromise; I don't have any problem here. > >> The best compromise I've seen offered in this thread was to include a >> runtime switch or environment setting to control its operation. > > The best compromise is simply to provide two separate builds, one > offering each behaviour, and you choose whichever you prefer. If you That works too. >> I have strong opinions that tools that allow the user to misuse the >> case insensitive file system fact are broken. > > Yet, you argue the case for providing the broken tool, in preference to > the sane! > SSY >> Therefore the tools so far have considered foo != FOO even though the >> file system thinks so. > > The file system, by definition, *must* be correct! The tools which > pretend otherwise are broken. > SSY >> I can agree to the above compromise however because I can still >> therefore enforce my opinion while at the same time you can enforce >> your opinion. > > It isn't about enforcement; it is about choice. I can happily agree to > this compromise because it allows you to have the behaviour you prefer, > no matter how insane I consider your choice, while I too can have what I > consider correct, even if you think I am crazy. > I don't think you're crazy; I think you have strong opinions that are different from mine. We are both correct and it comes down to which version is correct for the moment. Earnie P.S.: SSY == So say you. |
From: Suresh G. <sgo...@ya...> - 2007-09-29 21:03:50
|
I would be interested if those who are concerned that a case insensitive make will somehow create problems actually tried out the case insensitive make with files such as foo and fOO inside the same directory and visible to dir and reported any real problems: N:\Cell>dir f* Volume in drive N is sgovinda Volume Serial Number is 0A87-2061 Directory of N:\Cell 09/29/2007 01:24 PM 6 fOO 09/29/2007 01:24 PM 6 foo 2 File(s) 12 bytes 0 Dir(s) 262,542,581,760 bytes free N:\Cell> --Suresh |