Re: proposal to fork the build-tools projects

[Bruce Korb]

Pavel Roskin wrote:

> For example, there are two libraries, A and B, and only one can be used.
> There are at least (not counting --with-A=/path/to/A) 2 possibilities for
> each library (present and absent) and 3 possibilities for each option,
> (--with-A, -without-A, no option), which makes 36 combinations.  There are
> no ready macros to implement user-friendly logic, i.e. printing something
> like "you don't want to use A, but I cannot find B".

Actually, you need CPPFLAGS and LDFLAGS for each library,
which may or may not be derivable from --with-A=/path/to.
So, my ``withlib'' macro generator constructs *three* macros
per library, each having three states.  Yummy stuff.
But, unless I'm missing something, this is not the proposal.

> If you are going to make a fork, add a well-behaving shell to the
> requirements and leave out everything else.  I know a project with
> configure script longer than 500k.  Uncompressed sources of ash with
> function support are smaller than that.

Mine is 400K -- and it is a console program.  Plus, I have two
of the silly things in my distribution, yielding a 740K total.

Anyway, a base package would be a well-behaving shell, a C compiler
and make.  Tom seems resistent on a backfill library of headers and
library functions, though it would seem to be that assuming the
library + headers for all packages above "base" would make configury
simpler:

  backfill-config || exit 1

Heck, make that the default behavior for configure  :-)