Re: [DotGNU]Dotgnu written in C#?

[DrDiettrich]

Rhys Weatherley wrote:
> Try getting an application written by a Windows or Mac programmer to compile
> on *anything* except the original platform, even if they aren't using the
> GUI.  Porting from Unix to Windows/Mac is difficult.  Porting in the opposite
> direction is impossible.

Let me take the date tool as an example. I see no reason why such a tool
could not be compiled on any platform, without modifications. The build
process may be different, but that's the task of the development system
of the platform, not of the tool. The code can retrieve all required
information by standard (ANSI/POSIX/GNU...) calls, which of course must
and can be implemented once for every platform.

In the next step the UI dependencies also should be separated from the
working stuff, so that the kernel code of every tool can be used in any
environment, be it as a stand alone program or only as a set of
procedures in another program.

> I'm sorry to see that you've had problems getting GNU code to compile.  It is
> important to remember that "make it work for GNU first, Unix next, and other
> platforms later" is one of the standard GNU coding guidelines.

A reasonable decision, but what's the definition of "GNU" in the above
context?

Perhaps we are talking primarily about an inappropriate or even
inexistent definition of a GNU environment, which could be much more
simpler and platform independent itself?

> I will note that before the introduction of automake/autoconf, this was a
> *lot* worse.  What we have now in the Free Software community is heaven
> compared to before.  There is always room for improvement of course and if
> you manage to come up with a way, then a lot of people will be very happy.

This really is a topic where I would like to spend some time. It looks
to me as if GNUish people are somewhat helpless in downsizing, and
instead prefer to invent additional tools over and over again, only to
cure symptoms instead of the real disease.

> Portability is hard, and it isn't just a dependency or tools issue.  It's
> primarily an API issue - if you can't rely upon the API's being the same,
> then it is hard to make the code portable.  No matter what scheme is devised
> to describe the API differences, it will eventually tend towards spaghetti.
> The set of exceptions to the rules is too great.

That's why I think that "describing the differences" simply is the wrong
way to go. Better were "defining an GNU API", which then can be
implemented on every platform, and which eliminates every platform
dependencies in the source code.

> One of the goals of pnetC is to address this by creating a uniform Posix-like
> API on all CLI-compatible platforms.  That will resolve a lot of portability
> problems.  But at the end of the day, it is the programmer that has to write
> portable code - the tools cannot do it for him/her.

The tools could prevent the programmer from writing NON-portable code,
by flagging all non-ANSI or non-CLI or non-GNU constructs in the source
code. Add information about the proper API to be used instead to every
message, and any platform dependent code will turn out as being created
willingly by a dumb or malevolent programmer.

Writing platform independent code only requires the existence of a
platform independent API. GNU failed to both define a GNU platform and
API, and that's the only reason why GNUish code in fact is not freely
portable. Provided that you have no more precise description for the GNU
platform and API, that environment is made up from all the tools around
the build process. This obviously is an unusable definition, which is
extended with every new tool or revision, since everybody might want to
use such new extensions in the build process of his program.

If we don't restrict the build process of DotGNU programs to a minimum
set of related tools, then the same mess with platform specific build
procedures will occur in DotGNU projects, too, sooner or later. That's
why I feel an urgent need for a definition of an platform independent
standard build process.

DoDi