[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Non-Debian packaging practice

On Sat, Mar 11, 2006 at 02:04:32PM -0500, Justin Pryzby wrote:
> > 3. Version differences: This is a legitamate gripe. The autotools don't 
> > work nearly as wel as they could when developers
> >  are using different versions. However, I see no way to easilly fix this.

They could have done more for backward compatibility, but as it is, you need
versioned depends, and you need to call them with explicit versions.  That's
not too hard though, and it solves the problems.

> > So I must ask why do people dislike the autotools?
> I've never been able to figure out what they do for me.
> The possible exception is in combination with gnulib, but this seems
> inconsistent, since most people I've asked, who know "about" autofoo,
> don't know what gnulib is.  But I'd love to understand more than I do.

I've been using gnulib without autotools without problems.  For me they are
completely orthogonal, really.  Then again, I never really used autoconf, so I
may be missing something. :-)

> Correct me if I'm wrong .. but thats now how it works.  autoconf seems
> to provides a kind of a framework to facilitate portability,

It does provide a framework, but you still need to do a lot more than just
write a configure.ac if you actually want portable code.

> and automake provides a framework for creating makefiles with common and
> useful targets.

> Just stuffing autotools into an existing project just adds crud, with no
> benefits.

I see a contradiction here.  At least I think having "common and useful
targets" in a Makefile is a benefit. ;-)

Personally, I use automake, not autoconf.  Since automake only produces
Makefile.ins, not Makefiles, I need to add some autoconf junk, but I don't
actually do any tests in there that aren't needed for automake variables.  And
it does really have a function, because I don't want to know what compiler
flags I need to use libfoo, and I don't want to know if there is perhaps a
foo-config script either.  But I'm not going to test for a library just to
find out about build depends.  They are documented in the README or INSTALL,
and people should read those (at least after they find out the build fails).

I'm pretty sure this doesn't produce portable code, but I wasn't aiming for
that, so I don't mind.  It does give me Makefiles with "common and useful
targets", as you say, and I think that is very valuable.


I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see

Attachment: signature.asc
Description: Digital signature

Reply to: