From: Keith M. <kei...@us...> - 2007-09-30 07:11:20
|
On Sun, 2007-09-30 at 09:22 +0800, Yongwei Wu wrote: > > 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. When you pull quotations out of context, you arrive at incorrect conclusions. I said this, two or three paragraphs later, in the post you are quoting. The operative words are "on its own". Regards, Keith. |
From: Earnie B. <ea...@us...> - 2007-09-30 04:52:23
|
Quoting Keith Marshall <kei...@us...>: > 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. > No argument. > On such a file system, the `case preserving' property has no intrinsic > value on its own, other than purely cosmetic. > The intrinsic value has to do with portability and insurance that the file patterns I state work in case sensitive file systems as well as case insensitive file systems when I create the system on the case preserving, case insensitive file system. > 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. > How can you be sure that your case sensitive file system works if you've not tested your patterns with tools that preserve case? It is one thing to create and test on the case sensitive file system and then move to case insensitive, it is quite the other to create on the case insensitive and move to the case sensitive. > 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. > And when I take those to my case insensitive system and move them back I want to make sure that I don't destroy something in the configuration. If the pattern rules are case sensitive, it DTRT and I am happy. If the pattern rules are case insensitive I don't know if it DTRT and I may be very unhappy. > 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. > That's cool, really, so does most every one else. I am still not seeing why breaking the case sensitive pattern checking helps. >> 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. > I don't remember what I proposed. >> 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). > But the pattern rules do care regardless of the file system and one can create grief no matter the file system. >> 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. > Because I am convinced it is the pattern that need to govern what happens and not a change to the tool to make the patterns insensitive. If we were talking non case preserving then it would be a different story. So if you change ``%.txt: %.app'' from a previous example to ``%.txt: %.[Aa][Pp][Pp]'' it should do what you want and find myfile.app or file MYFILE.APP or other combinations. >> 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. > Sensibility in one moment isn't as sensible in another. Having both is good at least we can now choose based on the moment of sensibility. :p Earnie |
From: Keith M. <kei...@us...> - 2007-09-30 07:18:47
|
On Sun, 2007-09-30 at 00:52 -0400, Earnie Boyd wrote: > So if you change ``%.txt: %.app'' from a previous example to > ``%.txt: %.[Aa][Pp][Pp]'' it should do what you want and find > myfile.app or file MYFILE.APP or other combinations. That's one of the "solutions" you proposed, long time ago, when this problem first arose for me; IT DOESN'T WORK! Regards, Keith. |
From: Keith M. <kei...@us...> - 2007-09-30 14:11:00
|
On Sun, 2007-09-30 at 00:52 -0400, Earnie Boyd wrote: > That's cool, really, so does most every one else. I am still not > seeing why breaking the case sensitive pattern checking helps. Can we please dispense with the sarcasm, and discuss this objectively? To summarise: I want build tools which DTRT, on whichever platform I happen to be working at any time. I believe we are all agreed that this is an incontrovertible requirement. You want build tools which DTRT, but you also require them to provide consistency checking, for the case where you initiate development on the less restrictive platform, and subsequently move to a more restrictive. That's fine; I've no problem with that. You believe that these two objectives can be met with a single tool. You believe that your composite tool will DTRT, in any circumstances; I *know*, from bitter past experience, that it will not. You seem to consider the consistency checking feature to be *more* important than DTRT. This is the bit I have a problem with; any tool which which doesn't DTRT is worthless to me. I attach less importance to the consistency checking feature, because I build initially on a platform which enforces consistency from the outset. However, I appreciate that the consistency checking feature is important to you, and I believe I understand why. I consider that DTRT is the more important requirement. Consistency checking is also important, but must be secondary. If both requirements can be satisfied with a single tool, well and good. If that cannot be achieved, (and my experience convinces me that it cannot, without a radical redesign of GNU make), then we need two tools. This, we now have: `make' is the primary build tool, properly configured to work for the case insensitive native file system; `csmake' is the consistency checker, to confirm portability to a case sensitive foreign platform. As has already been noted, similar treatment is needed for `diff'; there may be others, as yet unidentified. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2007-09-30 18:32:00
|
Quoting Keith Marshall <kei...@us...>: > > I want build tools which DTRT, on whichever platform I happen to be > working at any time. I believe we are all agreed that this is an > incontrovertible requirement. > > You want build tools which DTRT, but you also require them to provide > consistency checking, for the case where you initiate development on the > less restrictive platform, and subsequently move to a more restrictive. > That's fine; I've no problem with that. > > You believe that these two objectives can be met with a single tool. > It may be naive to think so but yes. > You believe that your composite tool will DTRT, in any circumstances; I > *know*, from bitter past experience, that it will not. > Perhaps the issue was more the tool that was originally developed with. Had case sensitive pattern checking be in place the makefiles would have been written in upper case to begin with. It didn't help that I didn't properly instruct you in convert the makefile either. > You seem to consider the consistency checking feature to be *more* > important than DTRT. This is the bit I have a problem with; any tool > which which doesn't DTRT is worthless to me. > No, I consider case sensitive pattern matching TRT. > I attach less importance to the consistency checking feature, because I > build initially on a platform which enforces consistency from the > outset. However, I appreciate that the consistency checking feature is > important to you, and I believe I understand why. > > I consider that DTRT is the more important requirement. Consistency > checking is also important, but must be secondary. > And I believe case sensitive pattern matching TRT. > If both requirements can be satisfied with a single tool, well and good. > If that cannot be achieved, (and my experience convinces me that it > cannot, without a radical redesign of GNU make), then we need two tools. > This, we now have: `make' is the primary build tool, properly configured > to work for the case insensitive native file system; `csmake' is the > consistency checker, to confirm portability to a case sensitive foreign > platform. > %.txt: %.app echo $@ $< %.txt: %.APP echo $@ $< If you have a few lines of commands you can create a function. mycommands = \ echo $@; \ echo $<; %.txt: %.app $(mycommands) %.txt: $.APP $(mycommands) Unfortunately, the pattern rules do not adjust to wildcarding as I had expected but it can still be accomplished. > As has already been noted, similar treatment is needed for `diff'; there > may be others, as yet unidentified. And I put notes in the open ticket. Earnie |
From: Earnie B. <ea...@us...> - 2007-09-30 16:43:42
|
Quoting Keith Marshall <kei...@us...>: > On Sun, 2007-09-30 at 00:52 -0400, Earnie Boyd wrote: >> So if you change ``%.txt: %.app'' from a previous example to >> ``%.txt: %.[Aa][Pp][Pp]'' it should do what you want and find >> myfile.app or file MYFILE.APP or other combinations. > > That's one of the "solutions" you proposed, long time ago, when this > problem first arose for me; IT DOESN'T WORK! > The correct way to write it is: %.txt: $(wildcard %.[Aa][Pp][Pp]) ... and then it works. Earnie |
From: Earnie B. <ea...@us...> - 2007-09-30 19:11:14
|
Quoting Earnie Boyd <ea...@us...>: > > > Quoting Keith Marshall <kei...@us...>: > >> On Sun, 2007-09-30 at 00:52 -0400, Earnie Boyd wrote: >>> So if you change ``%.txt: %.app'' from a previous example to >>> ``%.txt: %.[Aa][Pp][Pp]'' it should do what you want and find >>> myfile.app or file MYFILE.APP or other combinations. >> >> That's one of the "solutions" you proposed, long time ago, when this >> problem first arose for me; IT DOESN'T WORK! >> > > The correct way to write it is: > > %.txt: $(wildcard %.[Aa][Pp][Pp]) > ... > > and then it works. > I take it back. This doesn't work as expected. The only method I found that works correctly is: mycommands = \ command 1; \ command 2; \ command ...; %.txt: %.app $(mycommands) %.txt: %.APP $(mycommands) I realized that this is not case sensitive by any means. I see Keith's need for the case insensitive pattern but I still don't think making the tool case insensitive in all cases is the correct thing. Earnie |