Re: how to detect broken install-sh?

[Ralf Wildenhues]

* 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 for most
packages, and getting more and more negligible in terms of disk space
availability every day.

Both disk space and compute power are still growing rapidly.  As long
as the set of workarounds for system bugs and limitations grows less
quickly, and they are mostly orthogonal and do not require too much
maintenance work on the developer part, the marginal cost of keeping
some workaround is negligible.

So unless the number of problem reports that developers have with
install-sh grows dramatically, I see no reason to drop it.

You're much better off arguing that packages update to Autoconf 2.64,
in many cases the configure script will shrink by more than 15K over
the one generated by 2.63 (and it'll be a bit faster, too).

Cheers,
Ralf

Re: AVRDUDE-5.8

[Daniel Herring]

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 bug tracker.  Someone here might know, but you should try the 
mailing lists and bugs tracker listed at the top of


http://savannah.nongnu.org/projects/avrdude/


- Daniel

AVRDUDE-5.8

[Ty Tower]

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
make  all-recursive
make[1]: Entering directory `/home/tytower/Download/avrdude-5.8'
make[2]: Entering directory `/home/tytower/Download/avrdude-5.8'
/bin/sh ./ylwrap lexer.l .c lexer.c -- :
make[2]: *** [lexer.c] Error 1
make[2]: Leaving directory `/home/tytower/Download/avrdude-5.8'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/tytower/Download/avrdude-5.8'
make: *** [all] Error 2
[tyto...@localhost avrdude-5.8]$




  
__
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/

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

Re: how to detect broken install-sh?

[Bob Friesenhahn]

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 think that
I'm in a different universe. I'll agree that the distribution of OSs is
different for each open source project. But - data needed - for either
of us to reason effectively on this. As far as conflicting, there are
multiple well established places to install things that won't
conflict: /opt /usr/local ~/local - plus you can just make one up and
put it in your path.


There are really only two approaches which work.  One is the 
"portable" approach taken now.  The other is to require installation 
of a full GNU toolset and radically simplify Autoconf, Automake, and 
Libtool so they only need to work with this toolset.  Installing 
coreutils is a substantial step toward installing a full GNU toolset.



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.


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.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: how to detect broken install-sh?

[Robert Collins]

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 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 think that
I'm in a different universe. I'll agree that the distribution of OSs is
different for each open source project. But - data needed - for either
of us to reason effectively on this. As far as conflicting, there are
multiple well established places to install things that won't
conflict: /opt /usr/local ~/local - plus you can just make one up and
put it in your path.

> > Its true that it is not a lot of dead weight, but at some point we
> > should be raising the bar - ever so slightly - on what we bundle into
> > the tarball. At one point we never required a Make implementation that
> > does includes, now we do [for dependency tracking] - and sure we degrade
> > well.
> 
> The make implementation that does includes is only for developers of 
> the package.  It is not necessary to have a fancy make to build the 
> software.

It is if you want dependency tracking [and yes, one time builds
shouldn't need that, unless they ship with an unsettled graph]. As a
fraction, amongst your users, who do all of the following:
 - build their own binaries
 - do so with /no/ modifications to the code
 - on a platform with no suitable install program

Thats the key number - the amount of benefit that install-sh gives you.

> > All I'm suggesting is that the time has come to let folk on the small
> > proportion of machines without a sufficiently useful install, build it -
> > exactly as they have to build any other dependency they are lacking.
> 
> What other dependency might they be lacking?  My own package is quite 
> large but all of the dependencies are optional.

Lets start at the ridiculous and propose that they are missing a C
compiler.

-Rob


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

Re: how to detect broken install-sh?

[Bob Friesenhahn]

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.  Installing "coreutils" could be quite a burden and the 
tools might conflict with the OS-provided equivalents.



Its true that it is not a lot of dead weight, but at some point we
should be raising the bar - ever so slightly - on what we bundle into
the tarball. At one point we never required a Make implementation that
does includes, now we do [for dependency tracking] - and sure we degrade
well.


The make implementation that does includes is only for developers of 
the package.  It is not necessary to have a fancy make to build the 
software.



All I'm suggesting is that the time has come to let folk on the small
proportion of machines without a sufficiently useful install, build it -
exactly as they have to build any other dependency they are lacking.


What other dependency might they be lacking?  My own package is quite 
large but all of the dependencies are optional.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: "make dist" and "make distcheck" trouble

[David Bruce]

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 src.  We might also
> need to see your configure.ac file.

Thanks so much - here are the files, pasted inline.  (I'm assuming the
mailing list would prefer not to have file attachments).  Again,
thanks for any help.  I assure you that I have tried pretty hard to
straighten this out on my own.

David Bruce



1. toplevel Makefile.am:


## Top-level Makefile.am for tuxmath:
## Process with Automake to create Makefile.in


## ---
## Variables: 
## ---


SUBDIRS = data  \
doc \
intl\
linebreak \
po  \
src

ACLOCAL_AMFLAGS = -I m4

EXTRA_DIST = tuxmath.spec \
tuxmath.desktop \
config.rpath \
m4/ChangeLog \
Info.plist \
CMakeLists.txt

datadir = @datadir@
localedir = $(datadir)/locale


## These are defined in configure.ac:
makens...@nsis@
nsis_fou...@nsis_found@
nsi_install_d...@nsi_install_dir@
nsi_dll_d...@nsi_dll_dir@
NSI_TEMP_INSTALL_DIR=$(abs_top_builddir)/_instw32


## ---
## Rules: 
## ---


## Bundle in fonts for distribution tar.gz to be used without package manager:
## i.e. to make tarball to post for individual download.
##
## for tarball with fonts: use 'make dist_with_fonts' (for *tar.gz)
## or 'make dist_with_fonts_bzip2 (for *tar.bzip2)
## for tarball without fonts: (e.g. for Debian packaging) - use 'make distcheck'
##
## (thanks to Ralf Wildenhues  for automake help!)
## 'dist_fonts' is in EXTRA_DATA but is empty by default.  With this target,
## 'dist_fonts' gets set to a list of the font files in data/fonts before making
## 'dist', causing the fonts to be included in the tar.gz.
## 'data_fonts' should contain all of the fonts in data/fonts. It needs to go
## in this Makefile.am before the 'dist_with_fonts' target for that target
## to work - if it is in data/fonts/Makefile.am, it does not get expanded
## before the 'dist' target starts:
data_fonts='AndikaDesRevG.ttf'
dist_with_fonts:
$(MAKE) $(AM_MAKEFLAGS) distdir=$(PACKAGE)_w_fonts-$(VERSION) \
   dist_fonts=$(data_fonts) dist
dist_with_fonts_bzip2:
$(MAKE) $(AM_MAKEFLAGS) distdir=$(PACKAGE)_w_fonts-$(VERSION) \
   dist_fonts=$(data_fonts) dist-bzip2




## For building the NSIS executable Win32 installer - this rule first
## does a "make install" into NSI_TEMP_INSTALL_DIR, which results in
## a local copy of the complete unix-style install.
## Subsequent commands then copy the needed files into NSI_INSTALL_DIR,
## which has the exact directory structure of the self-contained
## 'TuxMath' folder that gets installed onto the Windows machine.

install-nsi-local: all
## create NSI_TEMP_INSTALL_DIR and install to that location:
$(INSTALL) -d $(NSI_TEMP_INSTALL_DIR)
$(MAKE) $(AM_MAKEFLAGS) DESTDIR=$(NSI_TEMP_INSTALL_DIR) install
## create NSI_INSTALL_DIR/data dir and copy data files to that location:
$(INSTALL) -d $(top_builddir)/$(NSI_INSTALL_DIR)/data;
(cd $(NSI_TEMP_INSTALL_DIR)/$(pkgdatadir); \
   tar cf -  * ) \
   | ( cd $(top_builddir)/$(NSI_INSTALL_DIR)/data; \
   tar xf -)
## create NSI_INSTALL_DIR/doc dir and copy docs to that location:
$(INSTALL) -d $(top_builddir)/$(NSI_INSTALL_DIR)/doc;
(cd $(NSI_TEMP_INSTALL_DIR)/$(docdir); \
   tar cf -  * ) \
   | ( cd $(top_builddir)/$(NSI_INSTALL_DIR)/doc; \
   tar xf -)
## create NSI_INSTALL_DIR/locale dir and copy locales to that location:
$(INSTALL) -d $(top_builddir)/$(NSI_INSTALL_DIR)/locale;
(cd $(NSI_TEMP_INSTALL_DIR)/$(localedir); \
   tar cf -  * ) \
   | ( cd $(top_builddir)/$(NSI_INSTALL_DIR)/locale; \
   tar xf -)
## copy executable into NSI_INSTALL_DIR:
(cd $(NSI_TEMP_INSTALL_DIR)/$(bindir); \
   mv *TuxMath.exe TuxMath.exe; \
   tar cf - TuxMath.exe  ) \
   | ( cd $(top_builddir)/$(NSI_INSTALL_DIR); \
   tar xf -)
## Done with NSI_TEMP_INSTALL_DIR so uninstall:
$(MAKE) $(AM_MAKEFLAGS) DESTDIR=$(NSI_TEMP_INSTALL_DIR) uninstall
rm -rf $(NSI_TEMP_INSTALL_DIR)
## copy needed dll files into NSI_INSTALL_DIR:
-cp $(NSI_DLL_DIR)/*.dll $(top_builddir)/$(NSI_INSTALL_DIR);


install-nsi-am: install-nsi-local


nsis:
if test "x$(MAKENSIS)" = "x"; then \

Re: how to detect broken install-sh?

[Robert Collins]

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 install other packages.
> > coreutils of course cannot depend on itself being installed. A more
> 
> This seems like a pretty unreasonable requirement to me.  The 
> install-sh strategy has been working for quite a long time with hardly 
> any complaint until today.

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.

Its true that it is not a lot of dead weight, but at some point we
should be raising the bar - ever so slightly - on what we bundle into
the tarball. At one point we never required a Make implementation that
does includes, now we do [for dependency tracking] - and sure we degrade
well.

All I'm suggesting is that the time has come to let folk on the small
proportion of machines without a sufficiently useful install, build it -
exactly as they have to build any other dependency they are lacking.

BTW, on solaris, /usr/ucb/install is apparently the right thing to use,
and has been there since SunOS 5.10  Last Revised 14 Sep 1992 :).

-Rob


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

Re: how to detect broken install-sh?

[Bob Friesenhahn]

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 installed. A more


This seems like a pretty unreasonable requirement to me.  The 
install-sh strategy has been working for quite a long time with hardly 
any complaint until today.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: place automake files separately from source files

[Ralf Wildenhues]

* 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 time, you can require GNU make to be used, and use only files
> named GNUmakefile.am for automake.  The generated GNUmakefile files will
> be read and executed by GNU make instead of any Makefile files then.

Thinking about it a bit more, it should be possible without GNU make
even: name all automake input files foobar.am, list each foobar in
configure.ac:AC_CONFIG_FILES, and add
  AM_MAKEFLAGS = -f foobar

to the toplevel foobar.am.  Given that AM_MAKEFLAGS is not needed for
any other purpose, that should invoke all recursive make on the foobar
files.  Of course, this still requires the user to
  make -f foobar

on the toplevel, or some additional logic in the toplevel Makefile.

> After the transition is done, you could remove all old Makefile files,
> rename all GNUmakefile.am to Makefile.am, and adjust configure.ac.

This then still applies with s/GNUmakefile.am/foobar.am/.

Cheers,
Ralf

Re: how to detect broken install-sh?

[Ralf Wildenhues]

* 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 installed on each system is unreasonable.
> > Other systems have quite well-functioning tools, too.  Autotools
> > generally strive to produce packages that work well on all kinds of
> > Posix and almost-Posix systems.

> So I don't expect coreutils to be installed; I'm saying *packages other
> than coreutils* should *depend on a working /usr/bin/install*.
> 
> Thats quite a different thing :)

Right; and sorry for mixing that up.  However, I still consider that
unreasonable.  install-sh is selected on several systems, including,
if I remember correctly, AIX, IRIX, Tru64, and Solaris (my access to
these systems is down ATM).  None of these can be expected to fix their
/usr/bin/install any time soon, esp. since install is not standardized
in any way.  Also, some systems are known to use an old version of the
install-sh script as install program, which doesn't support multi-file
install.

Contrast that with us supplying a replacement script: that's easy,
rather lightweight in additional file size, maybe not in execution time
on systems where install-sh is selected.

I still don't see any valid reason to drop install-sh completely, esp.
not since the original bug report wasn't about our install-sh, but only
an old version of it.

Cheers,
Ralf

Re: how to detect broken install-sh?

[Robert Collins]

-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 unreasonable.
> Other systems have quite well-functioning tools, too.  Autotools
> generally strive to produce packages that work well on all kinds of
> Posix and almost-Posix systems.
> 
> Cheers,
> Ralf

So I don't expect coreutils to be installed; I'm saying *packages other
than coreutils* should *depend on a working /usr/bin/install*.

Thats quite a different thing :)

- -Rob
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkq/SOwACgkQ42zgmrPGrq55bQCeKM3laGVIGbsvaxhH/pXpGvTl
AAwAoJt+Tye5QcVTZr8qRhVbxz4kan73
=4YWB
-END PGP SIGNATURE-

Re: place automake files separately from source files

[Ralf Wildenhues]

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 directory as well, as common in a simple
> project from a third party source that does not use automake/autoconf.  Now
> I want to add automake support.  Can I create a subdirectory in parallel
> with source{1,2}.c, say I call it build_system
> and then in build_system I will place the top level GNU automake files such
> as Makefile.am, configure.ac, etc.

Not easily.  When transitioning from hand-written makefiles to
automake-generated ones, you have a couple of possible strategies
though:

Assuming the old build system is recursive, and recursion mostly happens
with plain `cd SUBDIR && $(MAKE)', you should be able to replace files
one by one.  Of course, that may require adjusting configure.ac and an
upper Makefile.am in each step.

Another possible strategy is to require the user to use GNU make and
VPATH builds only; that way, the source tree may have old Makefile files
and the build tree will have the new generated ones.  This is pretty
fragile as it depends on time stamp ordering and the specific VPATH
semantics used by GNU make only, so I'd advise against it.

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 time, you can require GNU make to be used, and use only files
named GNUmakefile.am for automake.  The generated GNUmakefile files will
be read and executed by GNU make instead of any Makefile files then.

After the transition is done, you could remove all old Makefile files,
rename all GNUmakefile.am to Makefile.am, and adjust configure.ac.

For more information, see
  info make "Makefile names"
  info Automake Requirements
  info Automake Rebuilding

HTH.

Cheers,
Ralf

Re: how to detect broken install-sh?

[Ralf Wildenhues]

* 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 install,

Yes, some testing of the system install is done.

> if so extending that to
> the bundled one isn't a great stretch.

> > 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 unreasonable.
Other systems have quite well-functioning tools, too.  Autotools
generally strive to produce packages that work well on all kinds of
Posix and almost-Posix systems.

Cheers,
Ralf

Re: how to detect broken install-sh?

[Robert Collins]

-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 :).

> I can see a couple of ways this could be done:
> 
>   - 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 install, if so extending that to
the bundled one isn't a great stretch.

> 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. 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 installed. A more
conservative fix would be to keep install-sh for the transitive closure
of coreutils build dependencies (but given that one can cross compile I
think this is also unnecessary).

- -Rob
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkq/JCsACgkQ42zgmrPGrq6DcwCggZlqS67rlS71viXlFm8iM5pO
WMAAnj9sN8RhFgPRSEeancSsWDvH6pRv
=JJoX
-END PGP SIGNATURE-

Re: how to detect broken install-sh?

[Ralf Wildenhues]

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) independently
> > check that all files which are supposed to be installed actually
> > do get installed.
> 
> The various supporting files that Automake includes in the distribution
> package, including install-sh, do all generally have version numbers in
> some form.  Maybe distcheck should just directly check that the included
> files have sufficiently recent versions?  I know that version checks
> normally go against the philosophy of the Autotools, but in this case
> they're files shipped by Automake itself, and it might be the easiest
> path.

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 replacement to
have all desired functionality though.

Checking at AC_PROG_INSTALL time seems interesting; but what about the
GNU/Linux-only package that has replaced install-sh with an empty file
"because our kernel module doesn't ever run elsewhere"?  (We can decide
to require them to fix their package; but that's a NEWS-worthy change.)
Checking the script only on systems where it will be used is feasible,
but won't gain you much confidence while testing on other systems.

Cheers,
Ralf

Re: "make dist" and "make distcheck" trouble

[Ralf Wildenhues]

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.

Thanks,
Ralf

"make dist" and "make distcheck" trouble

[David Bruce]

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, however, the src directory
contains not only the source files, but all the object files as well,
and also copies of anything else in the svn src directory - foo.o,
foo.c~ and the like.

2. If I do an in-tree build on the tarball, it works.
3. If I do a vpath build on the tarball, it fails - no *.o files get
made in the build/src directory.
4. If I first remove all the *.o files that are (incorrectly) included
in the tarball src directory, then do a vpath build, it succeeds.
5. If I do a make distcheck from either the tarball or svn, either
in-tree or vpath, it fails at make distcheck's own vpath stage.
6. The project has two other source subdirs at the same level as src
that get handled correctly.

So somehow "make dist" is wrongly putting the object files for src
into the tarball in an "in-tree" fashion, and this apparently confuses
a subsequent vpath build into not compiling the needed files.  Plus,
"make dist" is copying absolutely everything from the svn src
directory into the tarball, even files never mentioned in any
Makefile.am

I've looked at the top-level and src Makefile.am files for flags that
might be wrong, without seeing any clear culprit.  I would be happy to
post whatever files or output might help figure this out.

Does any of this sound like any familiar problem?

Thanks for any help,

David Bruce

Re: how to detect broken install-sh?

[Russ Allbery]

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 replacement to
> have all desired functionality though.

> Checking at AC_PROG_INSTALL time seems interesting; but what about the
> GNU/Linux-only package that has replaced install-sh with an empty file
> "because our kernel module doesn't ever run elsewhere"?  (We can decide
> to require them to fix their package; but that's a NEWS-worthy change.)
> Checking the script only on systems where it will be used is feasible,
> but won't gain you much confidence while testing on other systems.

The conservative approach would be to add a new Automake option that says
to check all the versions of scripts included in the package at make dist
time and not default it to on.

The less conservative approach would be to check the scripts at make dist
time by default but add an option similar to foreign that lets people turn
that check off if they're intentionally replacing or zeroing things.

-- 
Russ Allbery (r...@stanford.edu) 

Re: how to detect broken install-sh?

[Russ Allbery]

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 installed.

The various supporting files that Automake includes in the distribution
package, including install-sh, do all generally have version numbers in
some form.  Maybe distcheck should just directly check that the included
files have sufficiently recent versions?  I know that version checks
normally go against the philosophy of the Autotools, but in this case
they're files shipped by Automake itself, and it might be the easiest
path.

-- 
Russ Allbery (r...@stanford.edu) 

how to detect broken install-sh?

[Brian Gough]

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 one file and moves it instead of copying, due to differences
in the options handling.

I believe the old copy was a stray file from when I converted the
repository from CVS to git last year.  Afterwards I only used
autoreconf -i without --force so it was never updated.

I didn't notice the problem on my local system because ./configure
finds /usr/bin/install (so install-sh is never used) and the release
passed "make distcheck".  Fortunately most other people seem to have a
working /usr/bin/install as well so they haven't noticed (see [2] for
an exception).

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 installed.

  - 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.

What would be the best way?  Do you think this might cause other
problems?

-- 
Brian Gough

GNU Scientific Library -
http://www.gnu.org/software/gsl/


[1] It's ftp://ftp.gnu.org/gnu/gsl/gsl-1.13.tar.gz if you want to see it.

[2] http://lists.gnu.org/archive/html/bug-gsl/2009-09/msg9.html