Closed GoogleCodeExporter closed 9 years ago
Adrian, changing ownership of this item over to you.
I'm not very familiar with autotools on the development side of things, but
have used it plenty as an end user.
I typically see tarballs distributed with the "configure", "Makefile.in", et.
al.
I also recognize that Makefile.am, configure.ac & src/Makefile.am are source
files for autoreconf, I am unsure what autogen.sh is? I deleted it and the
following commands work as expected:
% autoreconf --install
% ./configure --prefix=/usr
% make
% sudo make install
...so I am unsure what it is used for?
Lastly, I understand how to make a distribution tarball "make dist", but how is
the version number incremented? ...and we use the svn revision as part of the
number in the interim?
Original comment by dmoore4...@gmail.com
on 20 Oct 2010 at 11:38
While some tarballs are distributed directly with configure and Makefile.in,
that's not technically the "correct" way to do things -- those are generated
files. autogen.sh is the script which generates them.
I will update the README tonight with updated instructions for autoconf, but
really the workflow should just be:
1. Run ./autogen.sh to create a configure script
2. Run ./configure to create a Makefile
3. Run make to compile the project
I'm not sure about the distribution tarballs myself, yet. I will also look into
that tonight :)
Original comment by apetresc
on 20 Oct 2010 at 11:47
Original comment by apetresc
on 20 Oct 2010 at 11:48
Here is the reference that I have been looking at:
http://www.lrde.epita.fr/~adl/dl/autotools.pdf
% make dist
creates the tarball.
To include the svn revision number:
--- configure.ac (revision 212)
+++ configure.ac (working copy)
@@ -1,7 +1,8 @@
dnl Process this file with autoconf to produce a configure script.
+define([svnversion], esyscmd([sh -c "svnversion -n"]))dnl
AC_PREREQ(2.59)
-AC_INIT(s3fs, 1.0)
+AC_INIT(s3fs, 1.0.svnversion)
AC_CANONICAL_SYSTEM
Original comment by dmoore4...@gmail.com
on 21 Oct 2010 at 12:34
Using svnversion -n isn't a good idea as is requires the build system to have
subversion installed. Strictly speaking, subversion is not (and probably should
not) be a dependency for building s3fs.
Furthermore, only basic utilities should be used in Makefile and configure
scripts as outlined in this document:
http://www.gnu.org/prep/standards/html_node/Utilities-in-Makefiles.html#Utilitie
s-in-Makefiles
Incrementing the version number upon releases seems to be the way to go.
Original comment by dmoore4...@gmail.com
on 25 Oct 2010 at 2:38
[deleted comment]
A quick spot check of what is installed on Debian stable a.k.a. lenny is as
follows:
libxml-2.0 2.6.32
libcurl 7.18.2
libcrypto 0.9.8
fuse 2.7.4
I currently use "sid" and Ubuntu 10.10, so the versions that I have been using
are newer than these. I personally don't know of any reason to require
versions newer than these.
Original comment by dmoore4...@gmail.com
on 29 Oct 2010 at 7:52
I agree we should definitely try to support the oldest versions of these
dependencies as we can; all we have to do is make sure it still links.
I will spin up a Debian Lenny EC2 instance and make sure S3FS works fine there.
If so, I'll lower the requirements.
Original comment by apetresc
on 29 Oct 2010 at 9:36
Can we marked this one fixed?
Original comment by dmoore4...@gmail.com
on 12 Nov 2010 at 11:24
Original comment by apetresc
on 12 Nov 2010 at 11:28
Original issue reported on code.google.com by
dmoore4...@gmail.com
on 18 Oct 2010 at 9:09