Re: tarball should include m4-files needed for autoconf

On Montag, 26. Februar 2007, Burkhard Plaum wrote:
> Hi,
>
Its me another time!

> This is usual practice, also for other projects. Users (the ones who call
> configure; make) need only mandatory requirements, developers (the ones who
> call ./autogen.sh) need much more (like libtool, automake, autoconf plus
> all m4 files). If bundled, every time the sdl.m4 file is changed upstream,
> the mjpegtools tree would have to be changed as well. And developers have
> better things to do than syncing .m4 files :)
>
Syncing m4-files takes around 20sec I think, is that too much for getting the 
package more friendly for using it?


Citing http://programming.linux.com/programming/05/08/11/1923248.shtml:

--- cut ---
Always provide the m4 files you used. As autotools have been in use for years, 
many packages (for example libraries) that can be reused by other programs 
provide an m4 library file in /usr/share/aclocal that makes it possible to 
check for their presence (for example using the -config scripts) with a 
simple macro call. These files are used by aclocal to create the aclocal.m4 
file, and they usually are present on the developers' systems where aclocal 
is executed to create the release, but when they are for optional 
dependencies, they can be missing on users' systems. While this is usually 
not a problem, because users rarely executes aclocal, it's a problem for 
source distributions, such as Gentoo, where sometimes you need to patch a 
Makefile.am or the configure.ac and then re-run autoconf without having all 
the optional dependencies installed (or having different versions, which can 
be incompatible or bugged, of the same m4 file).


To avoid this problem, you should create an m4 subdirectory in your package's 
directory and then put there the m4 library files you are using. You must 
then call aclocal with aclocal -I m4 options to search in that directory 
before the system library. You can then choose whether to put that directory 
under revision control (CVS, SVN, or whatever else you are using) or just 
create it for the releases. The latter case is the bare minimum requirement 
for a package. It minimizes the amount of revision-controlled code and 
ensures that you're always using the latest m4 version, but has the drawback 
that anyone who checks out your repository won't be able to execute autoconf 
without having to look on a release tarball to take the m4 from (and that 
might not work, as you can have updated the configure.ac to suit a newer 
macro or added more dependencies). On the other hand, putting the m4 
directory under revision control sometimes tempts the developers to change 
the macros to suit their needs. Although this seems logical, as the m4 files 
are under your revision control, it will upset many package maintainers, as 
sometimes new versions of m4 files fix bugs or support newer options and 
installation paths (for example multilib setups), and having the m4 files 
modified makes it impossible to just replace them with updated versions. It 
also mean that when you're going to update an m4 file you must redo the 
modification against the original.
--- cut ---


The second paragraph suggests you can extend the tarball creation routine to 
include the m4-file there: No need to manually sync the file then.

Matthias

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV