[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Fri, 2008-07-04 at 07:13 +0100, Simon Waters wrote:
> Neil Williams wrote:
> >
> > (Never update the autotools without also updating libtool.)
>
> I thought that this happens automatically if (hmm) configure.ac
> specifies it uses libtool, but you've more experience of this than I. I
> try to avoid compiling C, especially other peoples C.
libtool is checked as part of autoreconf -ifs but libtoolize is still
needed before autoreconf - especially if the current libtool is crufty.
IIRC autoreconf merely checks for the relevant libtool macro in
configure.ac and uses that to update the autotools stuff rather than
actually doing a proper upgrade of ./libtool and ltmain.sh etc. i.e. you
need both, especially if you want to do anything "interesting" with the
build like cross-build.
:-)
You're right about other peoples C code too - most of this comes from
learning the hard way that taking on old C code can be a PITA. I've
taken over upstream development of four different C projects (three
different previous upstream teams) in my time and the absolute first
things to do before any "development" are:
1. Create a linked directory with lndir
2. blitz the generated files - make distclean is just a start - remove
everything that is not intended for RCS.
3. force updates of all the tools and fix those errors
4. run ./configure --help and make sure it's sane
5. run ./configure with a few test args
6. re-run make distclean and blitz the generated files again,
update ./autogen.sh and repeat from 1.
7. Run a test make
8. Finally migrate the changes back to the original directory and remove
the directory of links. Commit all changes to RCS with sensible
ChangeLog entries and commit messages - include what went wrong as well
as how you fixed it.
9. run a real make. Fix the C code until make finishes
10. Fix the C and autotools code until 'make distcheck' works.
11. Now build a package for Debian or RH (against the current
development version of the distro {sid for Debian}) and fix the package
until that works cleanly too. Ensure you use the various check scripts
for the relevant package format (e.g. lintian for .deb).
At the end of that, you have a possible candidate for starting the work
of updating the codebase itself to current library versions and other
changes. Now create or update the various other parts of an upstream
team - mailing list, wiki, website, RCS, bug trackers, IRC . . .
The rule is: whatever you put in RCS should be the definitive code with
no generated files - if you haven't edited that file (if only to add
yourself to the Copyright), don't commit that file.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html