Re: how to detect broken install-sh?

[Robert Collins]

On Sun, 2009-09-27 at 20:38 -0500, Bob Friesenhahn wrote:

> > Thats the key number - the amount of benefit that install-sh gives you.
> 
> This violates a core principle of GNU in that "benefits" should be for 
> the benefit of the recipients of the software rather than for the for 
> the developers of it.  GNU is a communistic/Marxist type model rather 
> than a capitalistic model.  In the old days, the benefits were for the 
> developers and the users had to muddle through a difficult procedure 
> for every package that they installed.

I meant the benefit to the community, or even to the folk that end up
needing install-sh. I think portability is a great thing, but I also
think repeatedly solving the same problem isn't: particular when bug
fixes exist :). Anyhow, we're way off the original topic here, and I've
achieved my goal - to put my toe in the water about this sort of
change ;).

> To be sure, I will be quite supportive of a build framework if it is 
> based on a small package which is easily installed, and the build no 
> longer needs to be cobbled together with a mismash of Unix utilities. 
> Of course this build environment needs to be self-contained, well 
> supported, and would probably take five or seven years to fully 
> develop.  There have been a number of independent attempts in this 
> direction but it seems that none has come close to the popularity of 
> autotools.

All the ones I've seen have been 90% (or less) solutions and have often
[but not always] decided to replace Make with something less powerful :
a mistake IMO. I'm fairly sure I know what it would take to do a 100%
solution, but its daunting ;). I'm thinking of cmake, waf, scons,
primarily here, with cook, bake and others coming in as less well known
stabs in the same direction.

-Rob

signature.asc
Description: This is a digitally signed message part