* Robert Collins wrote on Sun, Sep 27, 2009 at 11:40:31PM CEST:
> The landscape has changed though, and I suspect that if we gather stats
> about this we'll see that install-sh is dead weight for most packages
> nearly all of the time.
The statistics are that <15K of code text is nearly negligible
On Sun, 27 Sep 2009, Ty Tower wrote:
I have avrdude 5.5 installed on my machine running Mandriva 2009
I have been trying to install 5.8 and get this error below which seems to be
the ylwrap script but it is too complex for
me to sort
Can someone tell me if this is a bug or my error
...
Wrong
I have avrdude 5.5 installed on my machine running Mandriva 2009
I have been trying to install 5.8 and get this error below which seems to be
the ylwrap script but it is too complex for me to sort
Can someone tell me if this is a bug or my error
Thanks
[tyto...@localhost avrdude-5.8]$ make
ma
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 develope
On Mon, 28 Sep 2009, Robert Collins wrote:
Maybe the landscape has changed for you, but not necessarily for
everyone. Installing "coreutils" could be quite a burden and the
tools might conflict with the OS-provided equivalents.
I'm not a strong enough believer in the Copenhagen school to thin
On Sun, 2009-09-27 at 18:59 -0500, Bob Friesenhahn wrote:
> On Mon, 28 Sep 2009, Robert Collins wrote:
> >
> > The landscape has changed though, and I suspect that if we gather stats
> > about this we'll see that install-sh is dead weight for most packages
> > nearly all of the time.
>
> Maybe the
On Mon, 28 Sep 2009, Robert Collins wrote:
The landscape has changed though, and I suspect that if we gather stats
about this we'll see that install-sh is dead weight for most packages
nearly all of the time.
Maybe the landscape has changed for you, but not necessarily for
everyone. Installi
Hello Ralf,
On 9/27/09, Ralf Wildenhues wrote:
> Hi David,
>
> * David Bruce wrote on Sat, Sep 26, 2009 at 04:51:01AM CEST:
>> My project is not creating valid tarballs with "make dist", and "make
>> distcheck" fails at the VPATH build stage.
>
> Please post your Makefile.am files in toplevel and
On Sun, 2009-09-27 at 16:00 -0500, Bob Friesenhahn wrote:
> On Sun, 27 Sep 2009, Robert Collins wrote:
> >
> > I suggest dropping install-sh completely except for the coreutils
> > package. coreutils is very portable, so its not unreasonable to require
> > that it is installed to locally build and
On Sun, 27 Sep 2009, Robert Collins wrote:
I suggest dropping install-sh completely except for the coreutils
package. coreutils is very portable, so its not unreasonable to require
that it is installed to locally build and install other packages.
coreutils of course cannot depend on itself being
* Ralf Wildenhues wrote on Sun, Sep 27, 2009 at 11:01:07AM CEST:
> It is possible to use different names than Makefile.am for the automake
> input files, with a caveat: in recursion rules, automake outputs plain
> `$(MAKE)' only, without -f. That still allows the following: for the
> transition ti
* Robert Collins wrote on Sun, Sep 27, 2009 at 01:13:48PM CEST:
> Ralf Wildenhues wrote:
> What would be the best way? Do you think this might cause other
> >>> problems?
> >> I suggest dropping install-sh completely except for the coreutils
> >> package.
> >
> > Expecting GNU coreutils to be in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
What would be the best way? Do you think this might cause other
>>> problems?
>> I suggest dropping install-sh completely except for the coreutils
>> package.
>
> Expecting GNU coreutils to be installed on each system is unrea
Hello Andy,
* Andy Tai wrote on Sat, Sep 26, 2009 at 08:13:06PM CEST:
> Hi, I wonder if there is a way to place the GNU autotools files in a source
> tree in a subdirectory from the source files, such as
>
> if I have sources files
>
> source1.c source2.c
>
> and there may be a Makefile in this
* Robert Collins wrote on Sun, Sep 27, 2009 at 10:37:01AM CEST:
> Brian Gough wrote:
> > - AC_PROG_INSTALL could confirm that the install program it finds
> > works in the way it will be used in "make install" and give an
> > error otherwise.
>
> Perhaps it already does for the system in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Gough wrote:
> Hi,
>
> I'd like to hear thoughts about the best way to detect a broken install-sh.
..
> Maybe it would be good to have a check for problems with install-sh.
I think that is a waste of cycles for every project except Automake :).
Hi Brian, Russ,
* Russ Allbery wrote on Sun, Sep 27, 2009 at 09:10:52AM CEST:
> Brian Gough writes:
>
> > Maybe it would be good to have a check for problems with install-sh.
> > I can see a couple of ways this could be done:
>
> > - make distcheck could (i) use install-sh and (ii) independent
Hi David,
* David Bruce wrote on Sat, Sep 26, 2009 at 04:51:01AM CEST:
> My project is not creating valid tarballs with "make dist", and "make
> distcheck" fails at the VPATH build stage.
Please post your Makefile.am files in toplevel and src. We might also
need to see your configure.ac file.
T
My project is not creating valid tarballs with "make dist", and "make
distcheck" fails at the VPATH build stage.
1. My project has all the *.c source files in a src directory under
trunk. I normally always do vpath builds, and the svn src directory
contains no object files. In the tarball, howe
Ralf Wildenhues writes:
> True. However, I remember at least once seeing packages where the
> author intentionally replaced the install-sh script for some reason.
> I don't want to call that unsupported outright, because after all, the
> script might just be buggy. I think we can expect the rep
Brian Gough writes:
> Maybe it would be good to have a check for problems with install-sh.
> I can see a couple of ways this could be done:
> - make distcheck could (i) use install-sh and (ii) independently
> check that all files which are supposed to be installed actually
> do get ins
Hi,
I'd like to hear thoughts about the best way to detect a broken install-sh.
I have accidentally made a release of a GNU package with a very old
copy of install-sh from 1996!! [1]. This install-sh has completely
broken behavior when used with recent versions of automake -- it only
installs on
22 matches
Mail list logo
