Re: Automake?

[Mark Ferlatte]

begin  Christian Hopp quote on Sun, Aug 18, 2002 at 01:02:27PM +0200:
> I don't think that the ARCH setting can be removed later.  Esp. my
> resource code would be too difficult to implement if you just use
> HAVE_.* .  We should think of a peaceful coexistence.

Maybe.  I haven't looked yet.  Tests for OS instead of features are sort
of broken, though.

> * What are the advantages with it (dev/use)?

Advantages of autoconf: system dependencies are centralized, your
application (if written correctly) can automatically port itself to
platforms that you may not have actually built on yourself.  It also
provides a semi-standardized build interface (less so without automake).

Advantages of automake: fills in a lot of the boilerplate of Makefiles
for you.  OTOH, has a quirky syntax, and many people think it's ugly.
Personally, it hasn't bit me yet, so I still kind of like it.

> * How it the integration process now?  Do I need to encapsulate any
>   #include with #ifdef HAVE_.* #endif?

If you use a non C standard header, you should surround it with #if
HAVE_FOO_H #endif (not #ifdef).  Some headers require special handling
to do portably (notably time.h vs. sys/time.h), and the autoconf manual
describes the correct #if foo for them.

> * What includes/features do you consider not system dependent?  What
>   has to be checked in configure what not?

Configure tends to check for a lot of stuff as a sanity check for the
build environment.  You probably don't have to header guard stdlib.h or
stdio.h, for example, but configure will still check for them to make
sure you're build has a chance of succeeding.  Keep in mind that every
time you guard a header, you need to have a potential replacement... you
don't necessarily have to write it yourself, though.  I generally header
check stuff that is not in the C standard, and figure that if someone
tries to build on a system that doesn't have those headers, the
configure script will at least point them to where they need to start
porting.

> * Would you #include now every "non-project" header file in config.h
>   instead of c-file itself?

I wouldn't.  You will need to include the config.h at the beginning of
every .c file, and any .h files that have #includes.

> * Do you see any development overhead/speedup in using auto(make|.*)?

There's some initial overhead, sure.  Once you're using them, I find
that they don't require much overhead, and they provide some nice
benefits.  The overhead of retrofitting them is that you need to
determine where and what sort of guards you actually require, and where.
Since we've got OS guards, we can replace most of them with feature
guards, which will solve the problem, and means that some poor shmuck
stuck on IRIX has a chance of running monit.  :)

M

pgp8sh5XTFD9e.pgp
Description: PGP signature