From: Suresh G. <sgo...@ya...> - 2007-09-29 21:20:35
|
[Sorry, should have elaborated:] 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: [elaboration: System is Windows XP Pro laptop. Drive N is samba mounted drive. I created foo and fOO on linux; below is how Windows' dir command sees foo and fOO; doesn't matter whether or not contents of foo and fOO are same or different:] 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 |
From: David L. <yak...@ya...> - 2007-09-30 08:12:20
|
--- Keith Marshall <kei...@us...> escribió: > 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. > > 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. > > > Regards, > Keith. > What does DTRT and TRT stands for? And on the other hand, I want to put other fact. Fact: I want tools for Woe32 in order to build a build system for building an application that pretends to be multiplattform, at leas Unix and Woe32. Regarding the behavior of latest make, can I make this possible, if, for example, I adopt that all the files I am willing to generate will be lower case? I know I need some patches to tell the makefile if I am in windows or linux, but don't want to have bugs about file system case sensitiveness. I already made a function to make all paths POSIX like, (without ':' in the path among other things) to prevent the message of "multiple targets", but don't want to mess much more. Thanks. 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: Keith M. <kei...@us...> - 2007-09-30 13:33:14
|
On Sun, 2007-09-30 at 10:12 +0200, David Lucena wrote: > What does DTRT and TRT stands for? [Do] the Right Thing. > And on the other hand, I want to put other fact. > > Fact: I want tools for Woe32 in order to build a build system for > building an application that pretends to be multiplattform, at leas > Unix and Woe32. Regardingthe behavior of latest make, can I make this > possible, if, for example, I adopt that all the files I am willing to > generate will be lower case? Yes. Provided you maintain *consistency* of case, between the actual names of the files, and your references to those files throughout your build system infrastructure, you will attain this goal. I develop on GNU/Linux, where the the case-sensitive nature of the native file system enforces that consistency, right from the outset, (because my trial builds will fail, if I get it wrong). When I move my package to a Woe32 host, the `make' which properly understands the case-insensitive nature of the file system, is *guaranteed* to just work, because it doesn't care about the case of the file names; it will even work if I did introduce an inconsistency. What I do need to take care with, is that I avoid exploiting the case sensitive nature of the Linux file system, within the build *procedure*, for that will not then work, when I move to Woe32. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2007-09-30 17:05:44
|
Quoting Keith Marshall <kei...@us...>: > > I develop on GNU/Linux, where the the case-sensitive nature of the > native file system enforces that consistency, right from the outset, > (because my trial builds will fail, if I get it wrong). > And with case sensitive pattern matching my trial builds will also fail if I get it wrong on windows. > When I move my package to a Woe32 host, the `make' which properly > understands the case-insensitive nature of the file system, is > *guaranteed* to just work, because it doesn't care about the case of the > file names; it will even work if I did introduce an inconsistency. > And if you did introduce an inconsistency and then take it back to the case sensitive file system it wouldn't work. This isn't the right thing to do as you know my opinion to be. > What I do need to take care with, is that I avoid exploiting the case > sensitive nature of the Linux file system, within the build *procedure*, > for that will not then work, when I move to Woe32. > And you also need to take care not to exploit the case insensitiveness of the windows file system. Case sensitive pattern matching helps to avoid this. Earnie |
From: Tuomo L. <dj...@ik...> - 2007-09-30 21:57:23
|
David Lucena wrote: > What does DTRT and TRT stands for? http://www.acronymfinder.com/ -- Tuomo ... It has been said that the great scientific disciplines are examples of giants standing on the shoulders of other giants. It has also been said that the software industry is an example of midgets standing on the toes of other midgets. -- Alan Cooper |
From: Tor L. <tm...@ik...> - 2007-09-30 13:56:59
|
> 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. One thing that should be remembered when discussing whether various tools should or should not recognize that file names spelled with case differences refer to the same file or not, is that NTFS case insensitivity handling is actually very hard to get exactly right in user code. Each NTFS volume has its own case mapping table, an "invisible" system file called $Upcase that is a table mapping each Unicode code point in the BMP (i.e. the first 64k characters) to another. See for instance http://www.ntfs.com/ntfs-system-files.htm So to really find out whether two names refer to the same file or not, one would have to look up the characters of the names in the case mapping table for the NTFS volume in question. Or, alternatively, in case the file/files are known to already exist, find out the MFT index ("inode number") for both names and see if it is the same. Unfortunately both reading the $Upcase file and looking up the MFT index require quite some magic and probably capabilities normal processes don't have. Sure, for ASCII only case differences like FOO vs. foo, this is probably unnecessary. Such names can always be assumed equivalent, unless somebody has on purpose made some weird modifications to the case mapping table on a NTFS volume. But for file names in general that may contain non-ASCII characters, the exact contents of the $Upcase table will reflect whether two names are equivalent or not. And, this is fun, the contents of the $Upcase table depends on what Windows version was used to create (format) the NTFS volume in question! See for instance http://blogs.msdn.com/michkap/archive/2005/01/16/353873.aspx . --tml |
From: Keith M. <kei...@us...> - 2007-09-29 07:28:46
|
On Sat, 2007-09-29 at 13:26 +0800, Yongwei Wu wrote: > > 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. No, of course it isn't; it is the *standard* make provided by Sun Microsystems, as a component of their *standard* operating system. *I* want *my* software to be portable; that means relying *only* on standard behaviour, not on GNU extended behaviour. > I never intend to make my Makefiles to work on different flavours of > Make. Well, that's just being short-sighted; perhaps one day, you will come to regret that. Regards, Keith. |
From: Yongwei W. <wuy...@gm...> - 2007-09-29 07:58:10
|
On 29/09/2007, Keith Marshall <kei...@us...> wrote: > On Sat, 2007-09-29 at 13:26 +0800, Yongwei Wu wrote: > > > 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. > > No, of course it isn't; it is the *standard* make provided by Sun > Microsystems, as a component of their *standard* operating system. *I* > want *my* software to be portable; that means relying *only* on standard > behaviour, not on GNU extended behaviour. If you want it, that is OK. I only intend my programs to run on Linux and Windows. I have no idea about the tools people use on Solaris at all: how can I care about it? I want my program to be portable too, but there is a balance. I never want to respect a platform that does not support a decent C++ compiler, for example.--Luckily this kind of platforms hardly exist now, thanks to the GNU toolchain. > > I never intend to make my Makefiles to work on different flavours of > > Make. > > Well, that's just being short-sighted; perhaps one day, you will come to > regret that. I doubt so. GNU Make is so universally available. And unless you test on another platform or restrict the functionality severely or have comprehensive documentation, as well as spending a lot of time, you cannot really be sure of the cross-platform-ness. I do not want to rid myself the rights to use if(n)eq, $(wildcard), $(patsubst), etc., which are not in every make. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Keith M. <kei...@us...> - 2007-09-29 07:32:34
|
On Sat, 2007-09-29 at 13:44 +0800, Yongwei Wu wrote: > Don't say we are on Windows. GNU is Unix! Ahem. GNU is *Not* 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 :-). It isn't my responsibility to prevent users from their own stupidity; neither am I required to facilitate it! Regards, Keith. |
From: Yongwei W. <wuy...@gm...> - 2007-09-29 08:03:33
|
On 29/09/2007, Keith Marshall <kei...@us...> wrote: > On Sat, 2007-09-29 at 13:44 +0800, Yongwei Wu wrote: > > Don't say we are on Windows. GNU is Unix! > > Ahem. GNU is *Not* UNIX. Google for "GNU is Unix" :-). Seriously, RMS loves Unix, except its proprietariness. The whole purpose of GNU is to create a free "clone" of UNIX. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Keith M. <kei...@us...> - 2007-09-29 10:11:29
|
On Sat, 2007-09-29 at 16:03 +0800, Yongwei Wu wrote: > > Ahem. GNU is *Not* UNIX. > > Google for "GNU is Unix" :-). > > Seriously, RMS loves Unix, except its proprietariness. The whole > purpose of GNU is to create a free "clone" of UNIX. I know what the purpose of GNU is; my quip was a tongue-in-cheek reminder of what the GNU acronym stands for. But seriously, GNU *is* *not* UNIX; it is a system of tools modelled on those commonly found in UNIX. On its own, it lacks a kernel which would make it a complete non-proprietary clone of UNIX. Distribute it with Linux, and it does become a UNIX clone; place it on top of Woe32, as we do with MSYS, and it becomes something else -- it is *not* UNIX, by any stretch of the imagination. Regards, Keith. |
From: Yongwei W. <wuy...@gm...> - 2007-09-29 08:09:27
|
On 29/09/2007, Keith Marshall <kei...@us...> wrote: > 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. Please do not forget Windows is case-preserving. Granted that it may not make a big difference to many people, it still can indicate a problem if the case changes. I, for the record, care about cases, and will not distribute files with the wrong case. One reason for that is exactly portability, as you emphasized in another thread. Assume a file should be named helloworld.c, but mistaken as helloworld.C, which will make a difference when you copy it to Unix/Linux/Solaris! Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Keith M. <kei...@us...> - 2007-09-29 09:59:43
|
On Sat, 2007-09-29 at 16:09 +0800, Yongwei Wu wrote: > Please do not forget Windows is case-preserving. case-preserving != case-insensitive Ignoring that reality leads to the sort of anomalous behaviour you have reported. Your problems are of your own making. The solution has been presented. EOD. Regards, Keith. |
From: Keith M. <kei...@us...> - 2007-09-29 10:35:37
|
On Sat, 2007-09-29 at 10:59 +0100, Keith Marshall wrote: > case-preserving != case-insensitive Oops! Of course, what I really meant is: case-preserving != case-sensitive Regards, Keith. |
From: Yongwei W. <wuy...@gm...> - 2007-09-29 11:39:54
|
On 29/09/2007, Keith Marshall <kei...@us...> wrote: > > 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 :-). > > It isn't my responsibility to prevent users from their own stupidity; > neither am I required to facilitate it! I do not object to this statement :-). The idea to take care of the speciality of case-insensitive file systems is good, but the current implementation of --case-insensitive-file-system is seriously flawed. I'll elaborate right away. Let's have a simplistic Makefile first: all: test.exe test.exe: test.c gcc -o $@ $< 1) --case-insensitive-file-system, as it is, is not useful. I can rename test.exe to TEST.EXE, or test.c to Test.c, and both Make 3.79 and 3.81 will work perfectly. The OS has already taken care of the case-insensitiveness of the file system. 2) --case-insensitive-file-system, as it is, is even harmful. In my first post, I already showed that it prevents some otherwise completely valid Makefile rules, even for use on a case-insensitive file system. In addition, it now allows the programmer to write "TEST.exe" when it first appears, and "test.exe" later. I doubt any serious programmers want such a "(mis)feature", which will also cause portability issues. On the other hand, Make 3.79 will reject this case as: make: *** No rule to make target `TEST.exe', needed by `all'. Stop. I'll propose an alternative as follows: 1) Add a run-time option --warn-case-different-targets to warn the user when two or more non-phony targets differ only in case. 2) Add a build-time option --warn-case-different-targets-by-default to switch the above option on by default (for case-insensitive platforms). 3) (Optionally) make --case-insensitive-file-system equivalent to --warn-case-different-targets-by-default. This will now make sense not only on Win32 targets (including Cygwin and MSYS!), but also on Unix platforms, where developers caring about portability issues can use the run-time option. Comments? Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Keith M. <kei...@us...> - 2007-09-29 13:46:12
|
On Sat, 2007-09-29 at 19:39 +0800, Yongwei Wu wrote: > On 29/09/2007, Keith Marshall <kei...@us...> wrote: > > > 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 :-). > > > > It isn't my responsibility to prevent users from their own stupidity; > > neither am I required to facilitate it! > > I do not object to this statement :-). Except, perhaps that it wasn't well expressed; I started to write something else, but changed my mind in mid-sentence. "It isn't my responsibility to prevent users from /indulging/ /in/ their own stupidity". > The idea to take care of the > speciality of case-insensitive file systems is good, but the current > implementation of --case-insensitive-file-system is seriously flawed. > I'll elaborate right away. Perhaps it is your expectations which are flawed; I simply don't see any problem. In any event, you are barking up the wrong tree -- indeed, you are barking in the wrong forest! > Let's have a simplistic Makefile first: > > all: test.exe > > test.exe: test.c > gcc -o $@ $< > > > 1) --case-insensitive-file-system, as it is, is not useful. > > I can rename test.exe to TEST.EXE, or test.c to Test.c, and both Make > 3.79 and 3.81 will work perfectly. The OS has already taken care of > the case-insensitiveness of the file system. > > 2) --case-insensitive-file-system, as it is, is even harmful. > > In my first post, I already showed that it prevents some otherwise > completely valid Makefile rules, even for use on a case-insensitive > file system. In your first post, you presented a case which becomes invalid, when you apply the rules pertaining to case insensitive file systems. > In addition, it now allows the programmer to write "TEST.exe" when it > first appears, and "test.exe" later. I doubt any serious programmers > want such a "(mis)feature", which will also cause portability issues. > On the other hand, Make 3.79 will reject this case as: > > make: *** No rule to make target `TEST.exe', needed by `all'. Stop. And this is precisely why it is *wrong* to configure *without* `--enable-case-insensitive-file-system', when that is exactly what you have to contend with. Furthermore, IIRC this case occurs in practice, even when the programmer has been completely consistent within the Makefile, if a pattern rule says `%.exe: %.c', and the source file, on disk, is named `TEST.C', (as it will do if, for example, it has come from a legacy MS-DOS application). > I'll propose an alternative as follows: Propose all you like; it will fall on deaf ears here, for we do not maintain GNU make. > 1) Add a run-time option --warn-case-different-targets to warn the > user when two or more non-phony targets differ only in case. > > 2) Add a build-time option --warn-case-different-targets-by-default to > switch the above option on by default (for case-insensitive > platforms). > > 3) (Optionally) make --case-insensitive-file-system equivalent to > --warn-case-different-targets-by-default. > > This will now make sense not only on Win32 targets (including Cygwin > and MSYS!), but also on Unix platforms, where developers caring about > portability issues can use the run-time option. > > Comments? If you believe this may be useful, then you should take it to the make_w32 mailing list, and argue your case with Paul Smith and Eli Zaretskii. Regards, Keith. |
From: Yongwei W. <wuy...@gm...> - 2007-09-29 14:32:59
|
On 29/09/2007, Keith Marshall <kei...@us...> wrote: > On Sat, 2007-09-29 at 19:39 +0800, Yongwei Wu wrote: > > The idea to take care of the > > speciality of case-insensitive file systems is good, but the current > > implementation of --case-insensitive-file-system is seriously flawed. > > I'll elaborate right away. > > Perhaps it is your expectations which are flawed; I simply don't see any > problem. In any event, you are barking up the wrong tree -- indeed, you > are barking in the wrong forest! I want to present a case, and persuade people here, where I am more familiar with. The MinGW people are the users that are most affected. If you all disagree, it does not make sense for me to go to another forest. Let's focus on facts. > > Let's have a simplistic Makefile first: > > > > all: test.exe > > > > test.exe: test.c > > gcc -o $@ $< > > > > > > 1) --case-insensitive-file-system, as it is, is not useful. > > > > I can rename test.exe to TEST.EXE, or test.c to Test.c, and both Make > > 3.79 and 3.81 will work perfectly. The OS has already taken care of > > the case-insensitiveness of the file system. You did not present any real benefit of --case-insensitive-file-system. This is my BIGGEST point. It beats people in an unexpected way, while providing no benefit I can see. > > 2) --case-insensitive-file-system, as it is, is even harmful. > > > > In my first post, I already showed that it prevents some otherwise > > completely valid Makefile rules, even for use on a case-insensitive > > file system. > > In your first post, you presented a case which becomes invalid, when you > apply the rules pertaining to case insensitive file systems. It is self-consistent, though different from your expectation. Earnie presented basically the same idea in another thread. > > In addition, it now allows the programmer to write "TEST.exe" when it > > first appears, and "test.exe" later. I doubt any serious programmers > > want such a "(mis)feature", which will also cause portability issues. > > On the other hand, Make 3.79 will reject this case as: > > > > make: *** No rule to make target `TEST.exe', needed by `all'. Stop. > > And this is precisely why it is *wrong* to configure *without* > `--enable-case-insensitive-file-system', when that is exactly what you > have to contend with. Furthermore, IIRC this case occurs in practice, > even when the programmer has been completely consistent within the > Makefile, if a pattern rule says `%.exe: %.c', and the source file, on > disk, is named `TEST.C', (as it will do if, for example, it has come > from a legacy MS-DOS application). As I presented in case 1), it still works *without* --enable-case-insensitive-file-system. It even works when one uses wildcards like $(wildcard *.c). The only failure case I can imagine is something like $(wildcard c_src/*) and have .C (not .c) files there. It is not cross-platform per se, anyway. Do you really expect people should write a Makefile like the following and it actually *works*? all: TEST.exe test.exe: test.c gcc -o $@ $< > > I'll propose an alternative as follows: > > Propose all you like; it will fall on deaf ears here, for we do not > maintain GNU make. > > > 1) Add a run-time option --warn-case-different-targets to warn the > > user when two or more non-phony targets differ only in case. > > > > 2) Add a build-time option --warn-case-different-targets-by-default to > > switch the above option on by default (for case-insensitive > > platforms). > > > > 3) (Optionally) make --case-insensitive-file-system equivalent to > > --warn-case-different-targets-by-default. > > > > This will now make sense not only on Win32 targets (including Cygwin > > and MSYS!), but also on Unix platforms, where developers caring about > > portability issues can use the run-time option. > > > > Comments? > > If you believe this may be useful, then you should take it to the > make_w32 mailing list, and argue your case with Paul Smith and Eli > Zaretskii. I need your comments and see whether I have flaws in reasoning. Apparently I have not persuaded you yet, and I am still waiting to see points that can really persuade *me*. The major point is to provide some really useful information, not something foolish like: make: Circular debug <- debug dependency dropped. I saw what it meant only after tried to make a minimal case. In my original big Makefile I was completely lost by the new Make behaviour. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Yongwei W. <wuy...@gm...> - 2007-09-29 15:15:05
|
On 29/09/2007, Yongwei Wu <wuy...@gm...> wrote: > As I presented in case 1), it still works *without* > --enable-case-insensitive-file-system. It even works when one uses > wildcards like $(wildcard *.c). I *do* have a flaw here. Make 3.81 can find TEST.C, but 3.79 can't. It is not strong enough to change my mind completely, but it *is* my fault. Sorry for not making a test earlier. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Keith M. <kei...@us...> - 2007-09-29 15:44:12
|
On Sat, 2007-09-29 at 22:32 +0800, Yongwei Wu wrote: > You did not present any real benefit of > --case-insensitive-file-system. This is my BIGGEST point. It beats > people in an unexpected way, while providing no benefit I can see. It provides a very real benefit -- it allows make to work correctly on any platform where the file system is case insensitive. Without it, make does not DTRT, on such systems. It does not "beat people in an unexpected way"; it overrules *your* flawed presumption that you can somehow force case sensitive behaviour, in spite of the fundamental reality that the file system is case insensitive. Adapt your thinking to fit the reality, and you will not be surprised in this way. > Do you really expect people should write a Makefile like the > following and it actually *works*? > > all: TEST.exe > > test.exe: test.c > gcc -o $@ $< No, I don't expect people to write their makefiles in such an inconsistent manner. However, I *do* expect: $ cat Makefile : %.txt: %.app tcsmake $<,$@,libforth.txt\; : $ make totheat.txt to work, when totheat.app exists on disk, (even though it may have come from an original legacy MS-DOS system, its real name on disk is actually TOTHEAT.APP, and to compound the confusion Win95-Explorer showed it as Totheat.app). > I want to present a case, and persuade people here, where I am more > familiar with. The MinGW people are the users that are most affected. > If you all disagree, it does not make sense for me to go to another > forest. Well, I have no interest in forking GNU Make. If you want to change it, you must take your case upstream. I wasted several weeks trying to circumvent a problem with MSYS make-3.79.1, which was solely caused by failure to recognise the case insensitive nature of the file system, and building the tool *without* `--enable-case-insensitive-file-system', (which was the ultimate solution to the problem). I have no interest in discussing this further. I'm willing to compromise, and offer an alternative build of make-3.81. I mean it this time; for me, this is EOD -- end of discussion. Regards, Keith. |
From: Yongwei W. <wuy...@gm...> - 2007-09-30 01:20:16
|
Hi Keith, Thanks for your message. I understand that you do not want to continue the discussion, but I wish you could spend some time on my points, which are *NOT in basic conflict* with your interests. On 29/09/2007, Keith Marshall <kei...@us...> wrote: > On Sat, 2007-09-29 at 22:32 +0800, Yongwei Wu wrote: > > You did not present any real benefit of > > --case-insensitive-file-system. This is my BIGGEST point. It beats > > people in an unexpected way, while providing no benefit I can see. > > It provides a very real benefit -- it allows make to work correctly on > any platform where the file system is case insensitive. Without it, > make does not DTRT, on such systems. > > It does not "beat people in an unexpected way"; it overrules *your* > flawed presumption that you can somehow force case sensitive behaviour, > in spite of the fundamental reality that the file system is case > insensitive. Adapt your thinking to fit the reality, and you will not > be surprised in this way. We are not in basic conflict. Only that I do not think my presumption is flawed. I never presume the file system is case-sensitive. I presume the *name of targets* can be case-sensitive. My point is that making *all* targets case-insensitive on a case-insensitive platform is overkill. It is a portability disaster, when people are not prepared for this (people *are* prepared that files name should not differ only in case in most cases). > > Do you really expect people should write a Makefile like the > > following and it actually *works*? > > > > all: TEST.exe > > > > test.exe: test.c > > gcc -o $@ $< > > No, I don't expect people to write their makefiles in such an > inconsistent manner. However, I *do* expect: > > $ cat Makefile > : > %.txt: %.app > tcsmake $<,$@,libforth.txt\; > : > > $ make totheat.txt > > to work, when totheat.app exists on disk, (even though it may have come > from an original legacy MS-DOS system, its real name on disk is actually > TOTHEAT.APP, and to compound the confusion Win95-Explorer showed it as > Totheat.app). This, like my wildcard example, is a valid case. I tested the case "test.exe: test.c", but not "%.exe: %.c": my fault. Having two different builds of Make, as you proposed in another message, is one solution. But this is not what I like. I'd like to respect both the case-insensitiveness of the file system, and the case-sensitiveness of build targets. They are not in conflict, since nowadays any sane programmers that have *any* ideas about portability will not try to create two targets whose names differ only in case. Even you admit that my ugly Makefile above should not work. My "ideal" solution will make sense even in the world of Cygwin and MSYS, unlike the current --case-insensitive-file-system option. My earlier proposal is not good enough, thanks to your comments. > Well, I have no interest in forking GNU Make. If you want to change it, > you must take your case upstream. I never suggested forking. I am really thinking to bring this up, after I have a more sound proposal. > I wasted several weeks trying to circumvent a problem with MSYS > make-3.79.1, which was solely caused by failure to recognise the > case insensitive nature of the file system, and building the tool > *without* `--enable-case-insensitive-file-system', (which was the > ultimate solution to the problem). I am sorry to hear that. This helped me understand why you have such strong opinions on this matter. We are not on any corporate agenda. We are here because we have our personal itches. It is case for you, and is also the case for me (or anybody else). We just suffered in different ways. > I have no interest in discussing this further. I'm willing to > compromise, and offer an alternative build of make-3.81. I mean it this > time; for me, this is EOD -- end of discussion. I wish not. I need your comments and criticism maybe. :-) -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Keith M. <kei...@us...> - 2007-09-29 21:32:37
|
On Sat, 2007-09-29 at 14:18 -0400, Earnie Boyd wrote: > 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. *I* am the Makefile creator, right? In that capacity, I *know* that, on a case insensitive file system, I *cannot* have two distinct files in a single directory, having names which are the same, except for differing capitalisation of the name; on such a system `./foo == ./FOO' is an incontrovertible truth. On such a file system, the `case preserving' property has no intrinsic value on its own, other than purely cosmetic. On such a file system, I *can* have two distinct files, similar in name but differing in capitalisation of that name, *provided* I place them in different directories. That's likely to confuse *me*, so generally I will avoid it. When I design a package hierarchy, I know that the case insensitive file system is the more limiting case; therefore I design for that, and it will just work, on a case sensitive file system, *provided* the case of the file names is preserved across the two file systems. This is where the `case preserving' property does have value; in synchronising file names between instances of the same file set, on file systems of differing case sensitivity. On the case sensitive file system, I know that my tools *must* refer to files, *exactly* as I've named them, so I take care that my scripts, makefiles and configuration files all respect this. That's necessary for the case-sensitive file system case; it is not *necessary* for the case-insensitive file system case, but it just works there anyway, so here my more restrictive case is the case-sensitive file system, and I ensure that my package respects this. Conversely, I avoid any build system `tricks', which rely on case distinction in the build commands, for I know that they are unlikely to work on the case-insensitive file system. Here the case-insensitive file system is the more restrictive; what works there should also just work on the case-sensitive system, so I design accordingly. The result is a portable package, which is agnostic to case distinction in file systems. > If TMC wants to search for files regardless of case the TMC can > create target and dependency patterns that search in case insensitive > ways. And, as we've already seen, that isn't easy. Not one of the ideas you yourself proposed, when I originally experienced the problem I mentioned earlier, actually worked. > 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 the file system doesn't care; *why* should he? By trying to impose unrealistic, (and unrealisable, because the file system will not permit it anyway), behaviour, he is only creating grief for himself, for zero gain, (that I can see). > I don't think you're crazy; I think you have strong opinions that are > different from mine. For the record, I don't think you are crazy either; I respect your right to your own opinion, whether or not we agree. On this particular topic, I'm just having a very hard time understanding why you are so convinced that it should even be an issue. > We are both correct and it comes down to which version is correct for > the moment. It isn't a matter of being right or wrong. It's a matter of what seems most sensible. Each member of the MinGW community will make their own decision on that; I've asked Chuck to give them the freedom to choose whichever behaviour they prefer -- he has done so. Regards, Keith. |
From: Suresh G. <sgo...@ya...> - 2007-09-29 22:37:53
|
Keith Marshall wrote: > ... on a case insensitive file system, I *cannot* have two > distinct files in a single directory, having names which are the > same, except for differing capitalisation of the name; on such a > system `./foo == ./FOO' is an incontrovertible truth. I wish that were true, but not so -- details below. It turns out one can argue that both make and csmake are "broken": As seen from Linux: ------------------ Cell>more f* mkfl :::::::::::::: foo.c :::::::::::::: #include <stdio.h> #include <strings.h> main() { printf("Hello from foo.c\n"); } :::::::::::::: fOO.c :::::::::::::: #include <stdio.h> #include <strings.h> main() { printf("Hello from fOO.c\n"); } :::::::::::::: mkfl :::::::::::::: CC = cc all: foo.exe fOO.exe foo.exe: foo.c $(CC) -o foo.exe $< fOO.exe: fOO.c $(CC) -o fOO.exe $< make and run as expected: ------------------------ Cell>make -f mkfl cc -o foo.exe foo.c cc -o fOO.exe fOO.c Cell>foo.exe Hello from foo.c Cell>fOO.exe Hello from fOO.c View from samba-mount to N on Windows XP laptop: ----------------------------------------------- Remove exe files; change cc in mkfl to gcc. N:\Cell>dir f* mkfl Volume in drive N is sgovinda Volume Serial Number is 0A87-2061 Directory of N:\Cell 09/29/2007 03:17 PM 85 fOO.c 09/29/2007 03:04 PM 85 foo.c Directory of N:\Cell 09/29/2007 03:23 PM 111 mkfl 3 File(s) 281 bytes 0 Dir(s) 262,542,540,800 bytes free N:\Cell> Work in MSYS-bash shell: ----------------------- /n/Cell$ ls f* mkfl fOO.c foo.c mkfl /n/Cell$ make -f mkfl mkfl:10: warning: overriding commands for target `foo.exe' mkfl:7: warning: ignoring old commands for target `foo.exe' gcc -o fOO.exe foo.c /n/Cell$ ls *exe fOO.exe* # problem: missing foo.exe /n/Cell$ *exe Hello from foo.c # problem: should be fOO.c /n/Cell$ rm *exe /n/Cell$ ls *exe ls: *exe: No such file or directory /n/Cell$ csmake -f mkfl gcc -o foo.exe foo.c /n/Cell$ ls *exe foo.exe* # problem: missing fOO.exe /n/Cell$ *exe Hello from foo.c /n/Cell$ So both make and csmake have problems when confronted with the above set-up. Moral: 1) Whoever creates such a set-up has earned and deserves all ensuing the problems. 2) Given todays networking of computers, it always likely that any file-system will end up being viewed from within an OS that seeks to be case-insensitive for file-names. So it is best to be case insensitive while creating one's own files. --Suresh |
From: Michael G. <mg...@ti...> - 2007-09-30 06:27:14
|
[problem illustrating example snipped] > So both make and csmake have problems when confronted with > the above set-up. =20 >=20 > Moral: 1) Whoever creates such a set-up has earned and deserves > all ensuing the problems. I wholeheartedly agree with that. The whole situaton results from a setup which requires taking care of portability in the first place. Ignoring (IMO basic) potential problems comes at a price. ["Doctor, it hurts when I take this club hit my head!" "Well then I suggest you just stop doing it"] > 2) Given todays networking of computers, it always likely > that any file-system will end up being viewed from > within an OS that seeks to be case-insensitive for > file-names. So it is best to be case insensitive > while creating one's own files.=20 I fully agree with this advice as well. It's not a problem arising from the OS, it comes from the FS. E.g. writing to a CDROM from a CS FS (which is a common situation on e.g. Linux) provides exactly that problem. I fail to understand where the real world problem that this thread discusses comes from. From what I've read so far it seems to me an exercise in intellectual acrobatics. Note I'm not denying there may be issues with case when mixing FS. I only fail to understand their practical relevance (as in make is not the only tool exposing problems of the setup). Apart from the context of FS ignoring case is something we [as in humans] are quite used to. What actually is the difference between a hammer, a Hammer, a HAMMER, a hAMMER and a hAmMeR ? Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@ti... GPG-keys available on request or at public keyserver |
From: Keith M. <kei...@us...> - 2007-09-30 07:07:57
|
On Sat, 2007-09-29 at 15:37 -0700, Suresh Govindachar wrote: > > ... on a case insensitive file system, I *cannot* have two > > distinct files in a single directory, having names which are the > > same, except for differing capitalisation of the name; on such a > > system `./foo == ./FOO' is an incontrovertible truth. > > I wish that were true, but not so -- details below. It turns out > one can argue that both make and csmake are "broken": Sorry. I realised afterwards that I could have been rather more explicit. It is implicit that, "on a case insensitive file system ... `./foo == ./FOO' is an incontrovertible truth" refers to two files WHICH LIVE ON THE CASE INSENSITIVE FILE SYSTEM. Your case is different. You have a CASE SENSITIVE file system, where `./foo == ./FOO' is an incontrovertible falsehood. When you remotely mount that file system on a host where the native file system is case insensitive, the case sensitive rules still apply for the remote mount. What is really required, is tools which can recognise the heterogeneous nature of network file systems, and act according to the rules which apply for individual mount points. At present, we don't have that, and package maintainers must work within the constraints of the more restrictive case. If all package maintainers did that, we would not need to have this discussion. In some imagined Utopia, this sort of think might work. We don't live in Utopia, and we must adapt to reality. It is easier to adapt package design to fit reality, than to make today's tools behave in a Utopian manner. Regards, Keith. |
From: Yongwei W. <wuy...@gm...> - 2007-09-30 01:22:27
|
A short comment on one of your points. On 30/09/2007, Keith Marshall <kei...@us...> wrote: > On Sat, 2007-09-29 at 14:18 -0400, Earnie Boyd wrote: > > 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. > > *I* am the Makefile creator, right? In that capacity, I *know* that, on > a case insensitive file system, I *cannot* have two distinct files in a > single directory, having names which are the same, except for differing > capitalisation of the name; on such a system `./foo == ./FOO' is an > incontrovertible truth. > > On such a file system, the `case preserving' property has no intrinsic > value on its own, other than purely cosmetic. Not cosmetic, if you want to package the files later and distribute to a different platform. Yes, this is portability, which I know you value too. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |