First Bob, then Eric :)
> http://www.gnu.org/prep/standards/html_node/System-Portability.html#System-P ortability This policy explains why not initiate non-gnu-os porting (for which I have a good answer: I need it) - but not why to *reject* them. > remove.c was almost completely re-written using the native WIN32 > API. It now compiles with MSVC 2005 and works well. The reality is quite the opposite of what you've said: have you looked in remove.c ? It's full of sun's proprietary functions: openat() and similar; emulating them is a terrible performance hit (200+% more system calls is my estimation) and a headache. Had it been written with only opendir() and unlink(), it wouldn't have had to be re-written. Another thing is the code complexity in remove.c - I didn't quite understand why is it so big and complicated; but this is probably just me.. I really could have re-written it using opendir() and unlink() - but win32 was my main concern here. ( Here, opendir() and unlink() would serve a nice example of a near-portable API: it provides access to the underlying implementation using a DIR* opaque structure; yet it uses proprietary "dirent" for file information. ) > -----Original Message----- > From: Eric Blake [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 15, 2007 06:51 > To: Aviad Lahav > Cc: bug-coreutils@gnu.org > Subject: RE: coreutils rm - win32 native port > > > - I tried Mingw's MSYS now; it suffers from the problems similar to > > cygwin's: needs to be installed and needs a DLL. > > MSYS is a collection of mingw apps along with a shell; it encompasses > several features including file name munging, above what a simple > mingw application normally does. Using mingw does not require > using MSYS. But complaints about MSYS or mingw are better > directed at their mailing list, rather than here. > > > > > - Why shouldn't coreutils accept native win32 ports? > > Because the GNU Coding Standards do not require bending backwards > to support proprietary systems. It is counterproductive to our > philosophy > to add #ifdefs all over the portable code just for one non-free > platform > that does not believe in following standards. > > http://www.gnu.org/prep/standards/html_node/Compatibility.html#Compatib > ility > http://www.gnu.org/prep/maintain/maintain.html#Ethical-and- > Philosophical-Consideration > > > GNU make does. > > Only because someone volunteers to maintain it. So, if I volunteer to maintain win32 support, would coreutils accept the changes? > > > I think > > native win32 support should be an objective of the project; > > And you are entitled to that opinion. However, Jim, as the primary > maintainer, is of the contrary opinion that upstream coreutils is > easier > to maintain if it sticks to non-proprietary, portable APIs, and I agree > with him. > First, I tend to agree with GNU's approach here. Second, I think there's a confusion here: Posix/unix-like API is indeed non-proprietary, but it's *not portable* by no means; a portable API means it abstracts away any underlying OS objects using undefined structs and opaque void* types. for instance (a) it assumes a user/group identifier is always a uid_t/gid_t (integral type), (b) no support for arbitrary-file-system per-file information, such as hidden/system attribute on win32 or file version on VMS, hence there's no way of copying it from file to file (cp -p is hurt here). (c) It assumes the underlying FS has inodes; I guess cp's hardlink detection breaks when a linux machine mounts an NTFS. (d) as a design principle, it not only lacks extensibility mechanism, it explicitly precludes them. This is more of an anti-portability approach. I think a truly portable (and therefore extensible) OS API is a real need of the GNU community. A well-designed API could make lives much easier for everybody - users and maintainers. > > if not, the > > situation I described before won't be solved: win32 users will have > endless > > choices of non-standard, not-entirely-working ports. > > That all depends on your definition of non-working. In my opinion, > the cygwin port of coreutils works just fine (but I am a bit biased, > as I maintain the cygwin port). > I don't think you're the responsible for cygwin's non-working stuff. Such problems are inherent to cygwin as it supplies a posix API - which is not portable, as I said above. Cp -p could never preserve hidden file attributes using a posix emulation layer - to mention one burning example. > -- > Eric Blake _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils