Re: coreutils rm - win32 native port

[Bob Proulx]

Eric Blake wrote:
> Aviad Lahav wrote:
> > - 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#Compatibility
> http://www.gnu.org/prep/maintain/maintain.html#Ethical-and-Philosophical-Consideration

The GNU project exists to create a completely free operating system.
There are many non-free operating systems.  Most are quite
incompatible with standard free systems.  It just does not make sense
to put a lot of effort supporting the closed source proprietary
systems when the goal is to create a completely free system.  This has
even been written down as a rule for GNU maintainers.  Here is what
the GNU standards say on this topic:

  
http://www.gnu.org/prep/standards/html_node/System-Portability.html#System-Portability

  The primary purpose of GNU software is to run on top of the GNU
  kernel, compiled with the GNU C compiler, on various types of cpu.
  So the kinds of portability that are absolutely necessary are quite
  limited.  But it is important to support Linux-based GNU systems,
  since they are the form of GNU that is popular.
  ...
  As for systems that are not like Unix, such as MSDOS, Windows, VMS,
  MVS, and older Macintosh systems, supporting them is often a lot of
  work.  When that is the case, it is better to spend your time adding
  features that will be useful on GNU and GNU/Linux, rather than on
  supporting other incompatible systems.

> > I think native win32 support should be an objective of the
> > project;

The scary part that I heard in the original message was:

    remove.c was almost completely re-written using the native WIN32
    API.  It now compiles with MSVC 2005 and works well.

That almost certainly sounds bad for the code for use on GNU and
Unix-like systems.  Don't you agree?  Since the primary purpose of GNU
software is to run on the GNU operating system this is taking the code
in the wrong direction.  It does not improve the maintainability and
(by the probable use of #ifdefs) would decrease it.

The amount and how much is all part of the judgement call as to
whether it is acceptable or not to put in and support or not.  Small
amounts of diversion are often acceptable but huge differences would
tend to be too much difference.  When I hear "almost completely
re-written using the native WIN32 API" that sounds like too much
difference and sounds detrimental to use of the code on GNU systems.

If that is not correct then please follow up with additional information.

> > if not, the situation I described before won't be solved: win32
> > users will have endless choices of non-standard,
> > not-entirely-working ports.

Please put yourself in our position.  How should an advocate of free
software developing projects for the GNU operating system be expected
to respond to a request to tie software to a non-free, non-standard,
system when doing so is disadvantageous to the native free GNU system?

This definitely puts us in an uncomfortable situation.  We would like
to please everybody but obviously that is not possible.  In the end we
just have to say we are very sorry but priority must be given to the
native goals of the project.

Bob