I'm still trying to sort this out. Some concerns and questions: I don't like the new MatchFilename, because it triggers on *all* platforms that #define HAVE_DIRENT_H. Anyone, doesn't that trigger on straight Linux systems too (all I know is that it's part of the Single UNIX Specification)? I don't like it because it implements a woefully inefficient algorithm: it cycles through the entire directory looking for a case-sensitive match. But there can be hundreds of .py files in a directory, and on average it will need to look at half of them, while if this triggers on straight Linux there's no need to look at *any* of them there. I also don't like it because it apparently triggers on Cygwin too but the code that calls it doesn't cater to that Cygwin possibly *should* be defining ALTSEP as well as SEP. Would rather dump MatchFilename and rewrite in terms of the old check_case (which should run much quicker, and already comes in several appropriate platform-aware versions -- and I clearly minimize the chance of breakage if I stick to that time-tested code). Steven, there is a "#ifdef macintosh" version of check_case already. Will that or won't that work correctly on your variant of Mac? If not, would you please supply a version that does (along with the #ifdef'ery needed to recognize your Mac variant)? Jason, I *assume* that the existing "#if defined(MS_WIN32) || defined(__CYGWIN__)" version of check_case works already for you. Scream if that's wrong. Steven and Jack, does getenv() work on both your flavors of Mac? I want to make PYTHONCASEOK work for you too.
On Tue, 27 Feb 2001, Tim Peters wrote:
I don't like the new MatchFilename, because it triggers on *all* platforms that #define HAVE_DIRENT_H.
I mentioned this when I originally submitted the patch. The intent was that it be *able* to compile on any unix-like platform -- in particular, I was thinking LinuxPPC was the other case I could think of where someone might want to use a HFS+ filesystem - but that Darwin/MacOSX was likely to be the only system in which that was the default.
Anyone, doesn't that trigger on straight Linux systems too (all I know is that it's part of the Single UNIX Specification)?
Yes. Barry added the _DIRENT_HAVE_D_NAMELINE to handle a difference in the linux dirent structs. ( I'm not sure if he caught my initial statement of intent either, but then the discussion veered into whether the patch should have been accepted at all, and then into the discussion of a general solution... ) I'm not happy with the ineffeciency either, but, as I noted, I didn't expect that it would be enabled by default elsewhere when I submitted it. ( And my goal for OSX was just to have a version that builds and doesn't crash much, so searching for a more effecient solution was going to be the next project. )
Would rather dump MatchFilename and rewrite in terms of the old check_case (which should run much quicker, and already comes in several appropriate platform-aware versions -- and I clearly minimize the chance of breakage if I stick to that time-tested code).
The reason I started from scratch, you might recall, was that before I understood that the Windows semantics was intended to be different, I tried adding a Mac version of check_case, and it didn't do what I wanted. But that wasn't a problem with any of the existing check_case functions, but was due to how check_case was used.
Steven, there is a "#ifdef macintosh" version of check_case already. Will that or won't that work correctly on your variant of Mac? If not, would you please supply a version that does (along with the #ifdef'ery needed to recognize your Mac variant)?
One problem is that I'm aiming for a version that would work on both the open source Darwin distribution ( which is mach + BSD + some Apple extensions: Objective-C, CoreFoundation, Frameworks, ... but not most of the macosx Carbon and Cocoa libraries. ) and the full MacOSX. Thus the reason for a unix only implementation -- the info may be more easily available via MacOS FSSpec's but that's not available on vanilla Darwin. ( And I can't, for the life of me, thing of an effecient unix implementation -- UNIX file system API's + HFS+ filesystem semantics may be an unfortunate mixture! ) In other words: I can rename the current version to check_case and fix the args to match. (Although, I recall that the args to check_case were rather more awkward to handle, but I'll have to look again. ) It also probably shouldn't be "#ifdef macintosh" either, but that's a thread in itself!
Steven and Jack, does getenv() work on both your flavors of Mac? I want to make PYTHONCASEOK work for you too.
getenv() works on OSX (it's the BSD unix implementation). ( I *think* that Jack has the MacPython get the variables from Pythoprefs file settings. ) -- Steve Majewski
[Steven D. Majewski]
... The intent was that it be *able* to compile on any unix-like platform -- in particular, I was thinking LinuxPPC was the other case I could think of where someone might want to use a HFS+ filesystem - but that Darwin/MacOSX was likely to be the only system in which that was the default.
I don't care about LinuxPPC right now. When someone steps up to champion that platform, they can deal with it then. What I am interested in is supporting the platforms we *do* have warm bodies looking at, and not regressing on any of them. I'm surprised nobody on Linux already screamed.
Anyone, doesn't that trigger on straight Linux systems too (all I know is that it's part of the Single UNIX Specification)?
Yes. Barry added the _DIRENT_HAVE_D_NAMELINE to handle a difference in the linux dirent structs. ( I'm not sure if he caught my initial statement of intent either, but then the discussion veered into whether the patch should have been accepted at all, and then into the discussion of a general solution... )
I'm not happy with the ineffeciency either, but, as I noted, I didn't expect that it would be enabled by default elsewhere when I submitted it.
I expect it's enabled everywhere the #ifdef's in the patch enabled it <wink/frown>. But I don't care about the past either, I want to straighten it out *now*.
( And my goal for OSX was just to have a version that builds and doesn't crash much, so searching for a more effecient solution was going to be the next project. )
Then this is the right time. Play along by pretending that OSX is the special case that it is <0.9 wink>.
... The reason I started from scratch, you might recall, was that before I understood that the Windows semantics was intended to be different, I tried adding a Mac version of check_case, and it didn't do what I wanted. But that wasn't a problem with any of the existing check_case functions, but was due to how check_case was used.
check_case will be used differently now.
... One problem is that I'm aiming for a version that would work on both the open source Darwin distribution ( which is mach + BSD + some Apple extensions: Objective-C, CoreFoundation, Frameworks, ... but not most of the macosx Carbon and Cocoa libraries. ) and the full MacOSX. Thus the reason for a unix only implementation -- the info may be more easily available via MacOS FSSpec's but that's not available on vanilla Darwin. ( And I can't, for the life of me, thing of an effecient unix implementation -- UNIX file system API's + HFS+ filesystem semantics may be an unfortunate mixture! )
Please just solve the problem for the platforms you're actually running on -- case-insensitive filesystems are not "Unix only" in any meaningful sense of that phrase, and each not-really-Unix platform is likely to have its own stupid gimmicks for worming around this problem anyway. For example, Cygwin defers to the Windows API. Great! That solves the problem there. Generalization is premature.
In other words: I can rename the current version to check_case and fix the args to match. (Although, I recall that the args to check_case were rather more awkward to handle, but I'll have to look again. )
Good! I'm not going to wait for that, though. I desperately need a nap, but when I get up I'll check in changes that should be sufficient for the Windows and Cygwin parts of this, without regressing on other platforms. We'll then have to figure out whatever #ifdef'ery is needed for your platform(s).
getenv() works on OSX (it's the BSD unix implementation).
So it's *kind* of like Unix after all <wink>.
( I *think* that Jack has the MacPython get the variables from Pythoprefs file settings. )
Haven't heard from him, but getenv() is used freely in the Python codebase elsewhere, so I figure he's got *some* way to fake it. So I'm not worried about that anymore (until Jack screams about it).
On Tue, 27 Feb 2001, Tim Peters wrote:
Please just solve the problem for the platforms you're actually running on -- case-insensitive filesystems are not "Unix only" in any meaningful sense of that phrase, and each not-really-Unix platform is likely to have its own stupid gimmicks for worming around this problem anyway. For example, Cygwin defers to the Windows API. Great! That solves the problem there. Generalization is premature.
This isn't an attempt at abstract theorizing: I'm running Darwin with and without MacOSX on top, as well as MkLinux, LinuxPPC, and of course, various versions of "Classic" MacOS on various machines. I would gladly drop the others for MacOSX, but OSX won't run on all of the older machines. I'm hoping those machines will get replaced before I actually have to support all of those flavors, so I'm not trying to bend over backwards to be portable, but I'm also trying not to shoot myself in the foot by being overly un-general! It's not, for me, being any more premature than you wondering if the VMS users will scream at the changes. ( Although, in both cases, I think it's reasonable to say: "I thought about it -- now here's what we're going to do anyway!" I suspect that folks running Darwin on Intel are using UFS and don't want the overhead either, but I'm not even trying to generalize to them yet! )
In other words: I can rename the current version to check_case and fix the args to match. (Although, I recall that the args to check_case were rather more awkward to handle, but I'll have to look again. )
Good! I'm not going to wait for that, though. I desperately need a nap, but when I get up I'll check in changes that should be sufficient for the Windows and Cygwin parts of this, without regressing on other platforms. We'll then have to figure out whatever #ifdef'ery is needed for your platform(s).
__MACH__ is predefined, meaning mach system calls are supported, and __APPLE__ is predefined -- I think it means it's Apple's compiler. So: #if defined(__MACH__) && defined(__APPLE__) ought to uniquely identify Darwin, at least until Apple does another OS. ( Maybe it would be cleaner to have config add -DDarwin switches -- or if you want to get general -D$MACHDEP -- except that I don't think all the values of MACHDEP will parse as symbols. ) -- Steve Majewski
Here's the checkin comment for rev 2.163 of import.c: """ Implement PEP 235: Import on Case-Insensitive Platforms. http://python.sourceforge.net/peps/pep-0235.html Renamed check_case to case_ok. Substantial code rearrangement to get this stuff in one place in the file. Innermost loop of find_module() now much simpler and #ifdef-free, and I want to keep it that way (it's bad enough that the innermost loop is itself still in an #ifdef!). Windows semantics tested and are fine. Jason, Cygwin *should* be fine if and only if what you did for check_case() before still "works". Jack, the semantics on your flavor of Mac have definitely changed (see the PEP), and need to be tested. The intent is that your flavor of Mac now work the same as everything else in the "lower left" box, including respecting PYTHONCASEOK. There is a non-zero chance that I already changed the "#ifdef macintosh" code correctly to achieve that. Steven, sorry, you did the most work here so far but you got screwed the worst. Happy to work with you on repairing it, but I don't understand anything about all your Mac variants and don't have time to learn before the beta. We need to add another branch (or two, three, ...?) inside case_ok for you. But we should not need to change anything else. """ Someone please check Linux etc too, although everything that doesn't match one of these #ifdef's: #if defined(MS_WIN32) || defined(__CYGWIN__) #elif defined(DJGPP) #elif defined(macintosh) *should* act as if the platform filesystem were case-sensitive (i.e., that if fopen() succeeds, the case must match already and so there's no need for any more work to check that). Jason, if Cygwin is broken, please coordinate with Steven since you two appear to have similar problems then. [Steven]
__MACH__ is predefined, meaning mach system calls are supported, and __APPLE__ is predefined -- I think it means it's Apple's compiler. So:
#if defined(__MACH__) && defined(__APPLE__)
ought to uniquely identify Darwin, at least until Apple does another OS.
( Maybe it would be cleaner to have config add -DDarwin switches -- or if you want to get general -D$MACHDEP -- except that I don't think all the values of MACHDEP will parse as symbols. )
This is up to you. I'm sorry to have broken your old code, but Barry should not have accepted it to begin with <wink>. Speaking of which, [Barry]
SDM> Yes. Barry added the _DIRENT_HAVE_D_NAMELINE to handle a SDM> difference in the linux dirent structs.
Actually, my Linux distro's dirent.h has almost the same test on _DIRENT_HAVE_D_NAMLEN (sic) -- which looking again now at import.c it's obvious I misspelled it!
Tim, if you clean this code up and decide to continue to use the d_namlen slot, please fix the macro test.
For now, I didn't change anything in the MatchFilename function, but put the entire thing in an "#if 0" block with an "XXX" comment, to make it easy for Steven and/or Jason to get at that source if one or both decide their platforms still need something like that. If they do, I'll double-check that this #define is spelled correctly when they check in their changes; else I'll delete that block before the release. Aren't release crunches great? Afraid they're infectious <0.5 wink>.
check_case will be used differently now.
[Steven]
If check_case will be used differently, then why not just use "#ifdef CHECK_IMPORT_CASE" as the switch?
Sorry, I don't understand what you have in mind. In my mind, CHECK_IMPORT_CASE goes away, since we're attempting to get the same semantics on all platforms, and a yes/no #define doesn't carry enough info to accomplish that.
"SDM" == Steven D Majewski <sdm7g@virginia.edu> writes:
SDM> Yes. Barry added the _DIRENT_HAVE_D_NAMELINE to handle a SDM> difference in the linux dirent structs. Actually, my Linux distro's dirent.h has almost the same test on _DIRENT_HAVE_D_NAMLEN (sic) -- which looking again now at import.c it's obvious I misspelled it! Tim, if you clean this code up and decide to continue to use the d_namlen slot, please fix the macro test. -Barry
Why don't we handle this the same way as, say, PyOS_CheckStack()? I.e. if USE_CHECK_IMPORT_CASE is defined it is necessary to check the case of the imported file (i.e. it's not defined on vanilla unix, defined on most other platforms) and if it is defined we call PyOS_CheckCase(filename, modulename). All these routines can be in different files, for all I care, similar to the dynload_*.c files. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
[Jack Jansen]
Why don't we handle this the same way as, say, PyOS_CheckStack()?
I.e. if USE_CHECK_IMPORT_CASE is defined it is necessary to check the case of the imported file (i.e. it's not defined on vanilla unix, defined on most other platforms) and if it is defined we call PyOS_CheckCase(filename, modulename). All these routines can be in different files, for all I care, similar to the dynload_*.c files.
A. I want the code in the CVS tree. That some of your Mac code is not in the CVS tree creates problems for everyone (we can never guess whether we're breaking your code because we have no idea what your code is). B. PyOS_CheckCase() is not of general use. It's only of interest inside import.c, so it's better to live there as a static function. C. I very much enjoyed getting rid of the obfuscating #ifdef CHECK_IMPORT_CASE blocks in import.c! This code is hard enough to follow without distributing preprocessor tricks all over the place. Now they live only inside the body of case_ok(), where they're truly needed. That is, case_ok() is a perfectly sensible cross-platfrom abstraction, and *calling* code doesn't need to be bothered with how it's implemented-- or even whether it's needed --on various platfroms. On Linux, case_ok() reduces to the one-liner "return 1;", and I don't mind paying a function call in return for the increase in clarity inside find_module(). D. The schedule says we release the beta tomorrow <0.6 wink>.
Tim, On Tue, Feb 27, 2001 at 02:27:12PM -0500, Tim Peters wrote:
Jason, I *assume* that the existing "#if defined(MS_WIN32) || defined(__CYGWIN__)" version of check_case works already for you. Scream if that's wrong.
I guess it depends on what you mean by "works." When I submitted my patch to enable case-sensitive imports for Cygwin, I mistakenly thought that I was solving import problems such as "import TERMIOS, termios". Unfortunately, I was only enabling the (old) Win32 "Case mismatch for module name foo" code for Cygwin too. Subsequently, there have been changes to Cygwin gcc that may make it difficult (i.e., require non-standard -I options) to find Win32 header files like "windows.h". So from an ease of building point of view, it would be better to stick with POSIX calls and avoid direct Win32 ones. Unfortunately, from an efficiency point of view, it sounds like this is unavoidable. I would like to test your patch with both Cygwin gcc 2.95.2-6 (i.e., Win32 friendly) and 2.95.2-7 (i.e., Unix bigot). Please let me know when it's ready. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
[Tim]
Jason, I *assume* that the existing "#if defined(MS_WIN32) || defined(__CYGWIN__)" version of check_case works already for you. Scream if that's wrong.
[Jason]
I guess it depends on what you mean by "works."
I meant that independent of errors you don't want to see, and independent of the allcaps8x3 silliness, check_case returns 1 if there's a case-sensitive match and 0 if not.
When I submitted my patch to enable case-sensitive imports for Cygwin, I mistakenly thought that I was solving import problems such as "import TERMIOS, termios". Unfortunately, I was only enabling the (old) Win32 "Case mismatch for module name foo" code for Cygwin too.
Then if you succeeded in enabling that, "it works" in the sense I meant. My intent is to stop the errors, take away the allcaps8x3 stuff, and change the *calling* code to just keep going when check_case returns 0.
Subsequently, there have been changes to Cygwin gcc that may make it difficult (i.e., require non-standard -I options) to find Win32 header files like "windows.h". So from an ease of building point of view, it would be better to stick with POSIX calls and avoid direct Win32 ones. Unfortunately, from an efficiency point of view, it sounds like this is unavoidable.
I would like to test your patch with both Cygwin gcc 2.95.2-6 (i.e., Win32 friendly) and 2.95.2-7 (i.e., Unix bigot). Please let me know when it's ready.
Not terribly long after I get to stop writing email <0.9 wink>. But since the only platform I can test here is plain Windows, and Cygwin and sundry Mac variations appear to be moving targets, once it works on Windows I'm just going to check it in. You and Steven will then have to figure out what you need to do on your platforms. OK by me if you two recreate the HAVE_DIRENT_H stuff, but (a) not if Linux takes that path too; and, (b) if Cygwin ends up using that, please get rid of the Cygwin-specific tricks in the plain Windows case (this module is already one of the hardest to maintain, and having random pieces of #ifdef'ed code in it that will never be used hurts).
Tim, On Tue, Feb 27, 2001 at 11:29:33PM -0500, Tim Peters wrote:
Not terribly long after I get to stop writing email <0.9 wink>. But since the only platform I can test here is plain Windows, and Cygwin and sundry Mac variations appear to be moving targets, once it works on Windows I'm just going to check it in. You and Steven will then have to figure out what you need to do on your platforms.
I tested your changes on Cygwin and they work correctly. Thanks very much. Unfortunately, my concerns about building due to your implementation using direct Win32 APIs were realized. This delayed my response. The current Python CVS stills builds OOTB (with the exception of termios) with the current Cygwin gcc (i.e., 2.95.2-6). However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will require one to configure with: CC='gcc -mwin32' configure ... and the following minor patch be accepted: http://sourceforge.net/tracker/index.php?func=detail&aid=404928&group_id=5470&atid=305470 Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
and the following minor patch be accepted:
http://sourceforge.net/tracker/index.php?func=detail&aid=404928&group_id=5470&atid=305470
That patch seems fine -- except that I'd like /F to have a quick look since it changes _sre.c. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Jason]
I tested your changes on Cygwin and they work correctly. Thanks very much.
Good! I guess that just leaves poor Steven hanging (although I've got ~200 emails I haven't gotten to yet, so maybe he's already pulled himself up).
Unfortunately, my concerns about building due to your implementation using direct Win32 APIs were realized. This delayed my response.
The current Python CVS stills builds OOTB (with the exception of termios) with the current Cygwin gcc (i.e., 2.95.2-6). However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will require one to configure with:
CC='gcc -mwin32' configure ...
and the following minor patch be accepted:
http://sourceforge.net/tracker/index.php?func=detail&aid=404928&gro up_id=5470&atid=305470
I checked that patch in already, about 15 minutes after you uploaded it. Is this service, or what?! <wink> [Guido]
That patch seems fine -- except that I'd like /F to have a quick look since it changes _sre.c.
Too late and no need. What Jason did to _sre.c is *undo* some Cygwin special-casing; /F will like that. It's trivial anyway. Jason, about this: However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will require one to configure with: CC='gcc -mwin32' configure ... How can we make that info *useful* to people? The target audience for the Cygwin port probably doesn't search Python-Dev or the Python patches database. So it would be good if you thought about uploading an informational patch to README and Misc/NEWS briefly telling Cygwin folks what they need to know. If you do, I'll look for it and check it in.
Tim, On Wed, Feb 28, 2001 at 12:36:45PM -0500, Tim Peters wrote:
I checked that patch in already, about 15 minutes after you uploaded it. Is this service, or what?! <wink>
Yes! Thanks again.
[Guido]
That patch seems fine -- except that I'd like /F to have a quick look since it changes _sre.c.
Too late and no need. What Jason did to _sre.c is *undo* some Cygwin special-casing;
Not really -- I was trying to get rid of WIN32 #ifdefs. My solution was to attempt to reuse the DL_EXPORT macro. Now I realize that I should have done the following instead: #if defined(WIN32) || defined(__CYGWIN__) __declspec(dllexport) #endif
/F will like that.
Apparently not.
It's trivial anyway.
I thought so too.
Jason, about this:
However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will require one to configure with:
CC='gcc -mwin32' configure ...
How can we make that info *useful* to people?
I have posted to the Cygwin mailing list and C.L.P regarding my original 2.0 patches. I have also continue to post to Cygwin regarding 2.1a1 and 2.1a2. I intended to do likewise for 2.1b1, etc.
The target audience for the Cygwin port probably doesn't search Python-Dev or the Python patches database.
Agreed -- the above was only offered to the curious Python-Dev person and not for archival purposes.
So it would be good if you thought about uploading an informational patch to README and Misc/NEWS briefly telling Cygwin folks what they need to know. If you do, I'll look for it and check it in.
I will submit a patch to README to add a Cygwin section to "Platform specific notes". Unfortunately, I don't think that I can squeeze it in by 2.1b1. If not, then I will submit it for the next release (2.1b2 or 2.1 final). I also don't mind waiting for the Cygwin gcc stuff to settle down too. I know...excuses, excuses... Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
[Jason Tishler]
... Not really -- I was trying to get rid of WIN32 #ifdefs. My solution was to attempt to reuse the DL_EXPORT macro. Now I realize that I should have done the following instead:
#if defined(WIN32) || defined(__CYGWIN__) __declspec(dllexport) #endif
Na, you did good! If /F wants to bark at someone, he should bark at me, because I reviewed the patch carefully before checking it in and it's the same thing I would have done. MarkH and I have long-delayed plans to change these macro schemes to make some sense, and the existing DL_EXPORT uses-- no matter how useless now --will be handy to look for when we change the appropriate ones to, e.g., DL_MODULE_ENTRY_POINT macros (that always expand to the correct platform-specific decl gimmicks). _sre.c was the oddball here.
... I will submit a patch to README to add a Cygwin section to "Platform specific notes". Unfortunately, I don't think that I can squeeze it in by 2.1b1. If not, then I will submit it for the next release (2.1b2 or 2.1 final). I also don't mind waiting for the Cygwin gcc stuff to settle down too. I know...excuses, excuses...
That's fine. You know the Cygwin audience better than I do -- as I've proved beyond reasonable doubt several times <wink>. And thank you for your Cygwin work -- someday I hope to use Cygwin for more than just running "patch" on this box <sigh> ...
Tim, On Wed, Feb 28, 2001 at 05:21:02PM -0500, Tim Peters wrote:
And thank you for your Cygwin work --
Your welcome -- I appreciate the willingness of the core Python team to consider Cygwin related patches.
someday I hope to use Cygwin for more than just running "patch" on this box <sigh> ...
Be careful! First, you may use grep occasionally. Next, you may find yourself writing shell scripts. Before you know it, you have crossed over to the Unix side. You have been warned! :,) Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
On Wed, Feb 28, 2001 at 09:44:47PM -0500, Jason Tishler wrote: [ Tim Peters ]
someday I hope to use Cygwin for more than just running "patch" on this box <sigh> ...
Be careful! First, you may use grep occasionally. Next, you may find yourself writing shell scripts. Before you know it, you have crossed over to the Unix side. You have been warned! :,)
Well, Tim used to be a true Jedi Knight, but was won over by the dark side. His name keeps popping up in decidedly unixlike tools, like Emacs' 'python' mode. It is certain that his defection brought balance to the force (or at least to Python) but we'd still like to rescue him before he is forced to sacrifice himself to save Python. ;) Lets-just-call-him-anatim-ly y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Tim, On Wed, Feb 28, 2001 at 03:17:28PM -0500, Jason Tishler wrote:
On Wed, Feb 28, 2001 at 12:36:45PM -0500, Tim Peters wrote:
Jason, about this:
However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will require one to configure with:
CC='gcc -mwin32' configure ...
How can we make that info *useful* to people?
I have posted to the Cygwin mailing list and C.L.P regarding my original 2.0 patches. I have also continue to post to Cygwin regarding 2.1a1 and 2.1a2. I intended to do likewise for 2.1b1, etc.
The target audience for the Cygwin port probably doesn't search Python-Dev or the Python patches database.
Agreed -- the above was only offered to the curious Python-Dev person and not for archival purposes.
So it would be good if you thought about uploading an informational patch to README and Misc/NEWS briefly telling Cygwin folks what they need to know. If you do, I'll look for it and check it in.
I will submit a patch to README to add a Cygwin section to "Platform specific notes". Unfortunately, I don't think that I can squeeze it in by 2.1b1. If not, then I will submit it for the next release (2.1b2 or 2.1 final). I also don't mind waiting for the Cygwin gcc stuff to settle down too. I know...excuses, excuses...
As promised: http://sourceforge.net/tracker/index.php?func=detail&aid=413750&group_id=5470&atid=305470 Note that the following goofiness: CC='gcc -mwin32' configure ... is no longer needed. Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
participants (7)
-
barry＠digicool.com -
Guido van Rossum -
Jack Jansen -
Jason Tishler -
Steven D. Majewski -
Thomas Wouters -
Tim Peters