Hossein wrote:
Hi. I just started to port latest python 2.7.2 to another platform (don't think you're eager to know... well it's CASIO ClassPad). And I faced a "minor" problem... It hasn't got stat or fstat or anything. (It supports a very limited set of c std lib). As pyport.c suggested, i defined both DONT_HAVE_STAT and DONT_HAVE_FSTAT, but problems only began. It failed to compile most of import.c, particularly because it fell into the wrong `#if !defined(PYOS_Something)' blocks. Sometimes it just fell into an #else part which assumed stat are available. So although HAVE_STAT is meant to control file operations, most of the source code aren't implement to use it. You see how "minor" the problem was? So now I need advice from developers. Is there a fix for it? What a question... definitely no replacement to stat. It's 99% definite that I can't compile further without touching the source code. I have to #define my own PYOS_whatever and handle files in my own way. In that case where should my special file handling cases go? I saw some marshal.c code which seemed it wants to abstract away platform's file handling from source code; but from what I understood it can't be made to use alternate file handling methods. If there is anything I should do (maybe show you my handmade pyconfig.h?) tell me.
See http://bugs.python.org/issue12082. Currently neither Python 2.x nor 3.x can be compiled without stat() or fstat(). Python 2.7 almost compiles, but Python 3 depends heavily on them. The problem boils down to the fact that you cannot really check whether a filesystem entry is a directory without calling stat() or fstat(). My personal opinion is that support for DONT_HAVE_STAT and DONT_HAVE_FSTAT defines should be dropped because they don't work, and would only be useful in a very limited set of cases.
[My first post in a mailing list... Should I say] Best Regards, n> Hossein [in here?]
Yeah, why not? :) Regards, Petri