Re: proposal to fork the build-tools projects

[Andreas Buening]

Dean Povey wrote:
>

[snip]

> >Maybe I am the one now who is totally not getting it, but:
> >
> >How could you distribute a binary to run on all the different kinds of
> >systems? I use Cygwin and MinGW. Am I going to be excluded from Open
> >Source packages because the package maintainer decided not to provide
> >such a binary? I don't follow the logic here. Are you saying that the
> >package maintainer will compile a binary "./configure" using h[er|is]
> >"build tools"? Or are you saying each end user will first unroll the
> >tarball and then build a binary "./configure" (the latter being the only
> >way that seems to make sense). Then you still have the problem of the C
> >library. I assume if the latter, that there will be a canonical download
> >location (+ mirrors) for precompiled libraries (on my platform(s), that
> >means Windoze DLLs)?
> 
> The easiest way would be for ./configure to find the C compiler and build
> a simple utility binary from source, then use that for the rest of the
> configuration.

You know that Standard C does not know anything about directories,
file descriptors, pipes, neither it can start child processes
(the system() call is just a joke) or handle signals? Not to
mention that it's not clear what a "C compiler" means. K&R is also
some kind of C "Standard".

Such a configure binary based on a "Standard C" cannot do much,
and if you want to use some Posix/SysV/BSD extensions you need
another preconfigure program to find out what your libc supports.
Then you'd better use autoconf from the beginning.

Even more, to my knowledge for systems like Cygwin, MinGW and EMX
the configure time depends only on the number of fork() calls.
I guess, it doesn't matter whether you have a shell script or a binary.
If both have the same number of fork() calls they need the same time
to run.


bye,
Andreas