autoconf not hard-link safe

autoconf (more precisely autom4te AFAICT) isn't hardlink safe.. That is, if I have a two or three source trees hardlinked together (to save space) with only differing source files not linked, running autoconf leaves configure (and possibly other files) still hardlinked. This means that editing con

Re: autoconf not hard-link safe

Robert Collins <[EMAIL PROTECTED]> writes: > autoconf (more precisely autom4te AFAICT) isn't hardlink safe.. > > That is, if I have a two or three source trees hardlinked together (to > save space) with only differing source files not linked, running > autoconf leaves configure (and possibly othe

Re: autoconf not hard-link safe

On Wed, 2003-12-17 at 16:34, Paul Eggert wrote: > Robert Collins <[EMAIL PROTECTED]> writes: > > > autoconf (more precisely autom4te AFAICT) isn't hardlink safe.. > > > > That is, if I have a two or three source trees hardlinked together (to > > save space) with only differing source files not li

Re: autoconf not hard-link safe

Robert Collins <[EMAIL PROTECTED]> writes: > > Most POSIX utilities are required to leave output files > > hard-linked, so there's good precedent for Autoconf's behavior. Even > > if we altered Autoconf, that still leaves the sh, cp, etc. as tools > > that won't break the hard links. > > Autoco

Re: autoconf not hard-link safe

On Thu, 2003-12-18 at 05:05, Paul Eggert wrote: > Robert Collins <[EMAIL PROTECTED]> writes: > > As far as I can see, this is a bug in 'patch', as 'patch' currently > violates POSIX in this respect. > > says

Re: autoconf not hard-link safe

Robert Collins <[EMAIL PROTECTED]> writes: > > > It needn't be the default, but it certainly should be an option, > > > > Yes, it would be reasonable to add it as an option. > > Is this something an autoconf developer would be inclined to > scratch? I don't think it'd be high priority, no. (Ha