BSD equivalents of autoconf, automake, etc.

Giorgos Keramidas keramida at ceid.upatras.gr
Thu Nov 18 08:33:27 PST 2004


On 2004-11-18 10:18, "Conrad J. Sabatier" <conrads at cox.net> wrote:
> On Thu, 18 Nov 2004 16:05:31 +0000, Jonathon McKitrick
> <jcm at FreeBSD-uk.eu.org> wrote:
> > I'm starting to dabble in these self-contained self-building
> > scripts and tools and so on, like automake, autoconf, libtool,
> > and so on.

I wouldn't go anywhere near these huge, hideous monsters of a shell
script, unless someone was paying me very good money for doing so :P

> > Are these the preferred way of doing things on FreeBSD, or is
> > there a better or more BSD-way of doing them?

Nope.  There is actually a better way.  Even plain Makefiles that use
the infrastructure in /usr/share/mk are A LOT easier to write than
portable autoconf stuff (if there really *is* any such thing).

The minimal Makefile for building a program in FreeBSD looks something
like this:

	PROG=	foo

	.include <bsd.prog.mk>

That's it!  All you have to do then is to write `foo.c' and `foo.1' --
the source and manpage of the program, respectively.  If you don't
have a manpage or will never need one, a simple option like this:

	NOMAN=	I have no manpage for this, because it sucks.

will inhibit the use of a manpage while building.

I can't even begin to describe all the 'make magic' that is hidden in
/usr/share/mk/*.mk, but you can find out most of it by reading the
comments in these make(1) include files.

> > Some time ago, Terry Lambert suggested that tools such as imake were
> > vastly superior, and that the GNU tools were just to compensate for
> > the inconsistencies across Linux distros.
>
> He's probably right.  :-)

Agreed.  I always found Imake easier to digest that a ton of Texinfo
documents describing a zillion m4 macros that change interfaces, APIs
and recommended usage patterns faster than I can blink my eyes.

> > I'd like to learn something that makes sense to learn because it is
> > practical, but at the same time, without sacrificing too much
> > portability.
>
> The main problem with the GNU auto* tools is their inconsistency across
> versions (which is why we still have several versions of each tool in
> the ports collection; not because this is A Good Thing, but because
> it's a necessity).  A program that will build just fine with one version
> will generate errors or other problems with another version.  Most
> annoying.

Or it will try to "guess" the right version of the tools to use for
automagic updates of the generated material, creating havoc out of
the rest of the build process.

Ah, the beauty of programs that try to be too ``smart''!



More information about the freebsd-questions mailing list