Thread

1. Re: [HACKERS] Proposed autoconf change: rip out search for 'install'

   Tom Lane <tgl@sss.pgh.pa.us> — 1998-12-08T01:26:23Z

   The Hermit Hacker <scrappy@hub.org> writes:
   >>>> I propose taking out configure's search for an install program and
   >>>> just letting it select install-sh always.  Anyone who really wanted
   >>>> to use their local install could still override that decision by
   >>>> changing Makefile.global.
   
   >> I have no problem with that.
   
   > 	I do...I don't like it when we assume that we're right and the
   > person installing the software is wrong...usnig AC_PROG_INSTALL should be
   > sufficient...
   
   Well, not to put too fine a point on it, Chris' complaint was that the
   software failed to do the Right Thing even though he had a peculiar
   PATH.  And certainly we do not have any installation instruction that
   cautions you against having an incompatible "install" in your path.
   (I'd not want to try to write an instruction like that, either, because
   I don't know which ones aren't compatible.)  So I'm not convinced by
   Marc's argument that the configure program should assume the user knows
   what he's doing in this respect.
   
   The minimum-change, safest way to address the issue is to take out
   configure.in's search for an install and always use install-sh
   unless the user specifically overrides that.  Using AC_PROG_INSTALL
   looks to me like it introduces more risk; there's a possibility that
   it will settle on an install that isn't really compatible, which is
   the same problem we've got now.  On the other hand, there's a lot to
   be said for using standardized solutions, and AC_PROG_INSTALL is
   presumably pretty well tested...
   
   			regards, tom lane
   
   

2. Re: [HACKERS] Proposed autoconf change: rip out search for 'install'

   Brook Milligan <brook@trillium.nmsu.edu> — 1998-12-08T20:53:24Z

      The minimum-change, safest way to address the issue is to take out
      configure.in's search for an install and always use install-sh
      unless the user specifically overrides that.  Using AC_PROG_INSTALL
      looks to me like it introduces more risk; there's a possibility that
      it will settle on an install that isn't really compatible, which is
      the same problem we've got now.  On the other hand, there's a lot to
      be said for using standardized solutions, and AC_PROG_INSTALL is
      presumably pretty well tested...
   
   Why not just go with AC_PROG_INSTALL since it gets tested by all the
   other gnu software installations anyway.  If there are special cases
   that it doesn't grok we can always put it inside a conditional based
   on a --with-install=/your/favorite/install/program configure option.
   I doubt we really will need that, though.
   
   Cheers,
   Brook