Re: [DotGNU]Dotgnu written in C#?

[Fergus Henderson]

On 07-Aug-2003, DrDiettrich <address@hidden> wrote:
> 
> I found serious problems with GNU/FSF software, which I would like to
> discuss now. [long discussion of portability issues]
...
> In the case of C-ish projects
> a unique set of header files can be used to compile GNU projects. As
> with the libraries, one or at least very few platform specific header
> files can be created once for every platform and compiler. Instead of
> checking for the availability of some features (alloca, bmove...) and
> according modifications to the source code (#if...), only the definition
> of the required feature is required which then can be implemented in the
> library or (typically) in a simple macro #define in the standard header
> files.

That is the approach that people used to use *before* autoconf came along.
This approach was abandoned because it sucked.

Here's what the autotools book <http://sources.redhat.com/autobook/> says:

 | The Cygnus `configure' script and the original GCC `configure' script
 | both had to be updated for each new Unix variant they supported. This
 | meant that packages which used them were continually out of date as new
 | Unix variants appeared. It was not hard for the developer to add support
 | for a new system variant; however, it was not something which package
 | users could easily do themselves. 
 | 
 | The same was true of Imake as it was commonly used. While it was
 | possible for a user to build and configure Imake for a particular
 | system, it was not commonly done. In practice, packages such as the X
 | window system which use Imake are shipped with configuration information
 | detailed for specific Unix variants. 
 | 
 | Because Metaconfig and Autoconf used feature tests, the scripts they
 | generated were often able to work correctly on new Unix variants without
 | modification. This made them more flexible and easier to work with over
 | time, and led to the wide adoption of Autoconf. 

> This is why I vote for a (new?) Integrated Development Environment,
> which replaces the current config-make-install chain, and most
> pertaining tools. This environment comes pre-configured for every
> system, and/or can be configured by the user. The author of a free
> software project only has to tell that IDE /what/ must be done, and has
> to leave it to the IDE and/or user /how/ this will be done.

What happens if the software needs to do something which neither the IDE
nor the user know how to do?

How would you deal with e.g. checking whether the C compiler has a bug that
prevents the simultaneous use of structure assignment and global register
variables?  Is this IDE supposed to somehow know in advance about every
such possible compiler bug that packages will need to work around?
Neither the user nor the IDE are going to know anything about such problems.
Feature tests are a much better way of dealing with issues like this.

-- 
Fergus Henderson <address@hidden>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.