Sidebar re autoconf
David Collier-Brown
david.collier-brown at Canada.Sun.COM
Mon Apr 13 13:29:19 GMT 1998
Andrew Tridgell <tridge at samba.anu.edu.au> wrote:
| yeah, I know what you mean. autoconf can be terrible if done wrong.
|
| I do intend us to use autoconf, but I also want us to get it
| right. There are heaps of little things that we do in a horible kludgy
| way at the moment ...
I have a colleague[1] who does large-scale porting by
1) characterizing the target machine
2) defining its difference from a standard (he uses unix v6 (:-))
3) covering the difference via a compatability library.
Autoconf helps a lot in (1), but tries too hard to do (3)
without (2). Net result? Professional porters avoid overdependance
on it.
I only do small-scale porting, and so do (2) and (3) rather like
Samba does: use the initial development world as a standard and
vary some low-level code.
I've discovered a number of things via autoconf, but used it to
define ``LACKING'' lines, thusly:
# LACKING, the flags used to select optional replacement code:
# NOSTRDUP, NOSTRSTR, NOSTRNCASECMP, NOSTRTOK for strings,
# OLDSYSLOG, to indicate obsolete syslog/openlog function.
# Defaults to empty.
#
#
#LACKING=-DNOSTRDUP -DNOSTRSTR -DNOSTRNCASECMP # For SunOS 3.5, Sun 3, 3x
#LACKING= -DOLDSYSLOG -DNOSTRDUP -DNOSTRSTR -DNOHERRNO # For Ultrix 3.1D
#LACKING= -DOLDSYSLOG -DNOSTRDUP # For Ultrix 4.2, 2100s and 5000/25s
(from a program written many moons ago (:-))
This is not unlike Samba's
# The following are additional flags that may apply
# -DNETGROUP if your machine supports yp netgroups
# -DAUTOMOUNT to ask for yp auto.home for users' home directories
but is is somewhat more organized.
I recommend
a) collecting the variables
b) seperating out the portability ones
i) turning them into characterizations of missing
fratures
ii) grouping them by OS, as above.
c) doing the same with the add-a-feature variables
(should those not move to local.h, and SHMEM_SIZE
move back???)
This allows one to start from an existing version (say, Ultrix 3.1, above)
and do the port to a later version by doing an autoconf run to see what's
there, and amending the list to suit.
This is a lot less work then autoconfing all the time, and fails
less when the customer has a somewhat broken configuration, is
cross-compiling, is switching compilers, etc...
--dave (who is seriously into work avoidance) c-b
[1. David Tilbrook, the author of qef, which see]
--
David Collier-Brown, | Always do right. This will gratify some people
185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
Willowdale, Ontario | davecb at hobbes.ss.org, canada.sun.com
M2N 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb
More information about the samba-technical
mailing list