Re: configuration parameters

Re: configuration parameters

[Tom Culliton x2278]

I'd like to agree with Chris on this and disagree with who ever
suggested using imake.  Having the configuration parameters in the make
file, as they are now, works beautifully.  As matters stand I copy
"Makefile" to "makefile" edit the configuration options in that and go.
I never even have to touch any of the original files (aside from
applying patches from Byron ;-) ).

This is utterly painless and shows an absolutely incredible level of
portability.  Having ported more packages than I care to count to
various machines, rc is probably the cleanest.  Most packages get
checked into RCS the minute they're unbundled so we can track the
changes necessary just to get them running, not so with rc!

As to Imake... While the concept is probably OK the execution generally
stinks.  I've never seen it work right yet.  Please don't inflict it on
us!

Tom

configuration parameters

[jew]

I downloaded and compiled the latest version of kermit over the weekend.
It had a seperate set of options for each platform, for instance to compile
it on this old wheezer, I type: make aixrt  or somesuch.  Is that a horrible
solution?

Re: configuration parameters

[Alan Hargreaves]

> Date: Fri, 14 Feb 1992 17:20:40 -0600
> From: rjc@math.Princeton.EDU
> Subject: Re: configuration parameters
> 
> If we don't go with the config.h file, how about making the .o files
> dependent on the Makefile itself?  When trying to get rc up and running,
> I'll be tweaking the Makefile switches and adjusting the source and
> I'll forget to rm *.o before re-making, yielding a bizarre combination
> of old and new object code in the final executeable.  You can imagine
> how often I mumble to myself, ``But wait, I thought I fixed that
> in the Makefile...''

simpler idea, why not have config.h depend on Makefile and have make
build config.h? We have a few locally written packages here that do it
that way.

alan.
-- 
Alan Hargreaves (VK2MGL) alan@frey.newcastle.edu.au, Uni of Newcastle, UCS.
Ph: +61 49 215 512 Fax: +61 49 687 472 ICBM: 32 53 44.6 S / 151 41 52.6 E

Software Bloat -  Any UNIX(tm) after Version 7.	(Sm@cerberus.bhpese.oz.au)

Re: configuration parameters

[rjc]

If we don't go with the config.h file, how about making the .o files
dependent on the Makefile itself?  When trying to get rc up and running,
I'll be tweaking the Makefile switches and adjusting the source and
I'll forget to rm *.o before re-making, yielding a bizarre combination
of old and new object code in the final executeable.  You can imagine
how often I mumble to myself, ``But wait, I thought I fixed that
in the Makefile...''
--
Raymond (not named after `rc') Chen

Re: configuration parameters

[Tom Culliton x2278]

>>  Can someone describe the GNU configure tool? Does it fall down on
>> strange machines? Does it force you to answer lots of chatty questions?
>> 
>> 	- cks

I've had many problems porting "Auto-configuring" GNU (etc.) stuff to
SCO Unix.  To the best of my knowledge their configure stuff is very
similar (if not identical to) Larry Wall's which also has problems with
SCO.  Admittedly SCO Unix is a bastard cross between a bull bitch and a
window shutter, (don't ask me what that means it's just something my
father used to say) and has various bugs, mis-features and down right
stupidity built in for our enjoyment, but there's a lot of it out here
in the real world.

For example... most auto-config packages deduce that SCO has a working
POSIX rename function.  BZZZZT!  Just try to use it on a NFS mounted
file system and watch the fun.

Hand editing make files usually works much better unless the number of
configuration options is about three or four times what rc has now.

Tom

Re: configuration parameters

[Chris Siebenmann]

 Can someone describe the GNU configure tool? Does it fall down on
strange machines? Does it force you to answer lots of chatty questions?

	- cks

configuration parameters

[Brendan Kehoe]

   Date: Thu, 13 Feb 1992 23:33:14 -0600
   From: Chris Siebenmann <cks@hawkwind.utcs.toronto.edu>

    Actually, I'll disagree here; I think the combination of the Makefile and the
   'canned' stuff in config.h has worked fine. It also (importantly!)
   keeps the number of files one usually has to edit when moving
   rc from platform to platform down to one (Makefile), which people
   are used to editing.

Have you thought of using the GNU configure tool?

--
Brendan Kehoe, Sun Network Manager                      brendan@cs.widener.edu
Widener University                                                 Chester, PA

            This is the .signature that Bell Atlantic doesn't want you to see.

Re: configuration parameters

[Rich Salz]

I think your new scheme is a little better, if only because I find the
explanations easier to read (not sure why, I just do).  You might want to
think about shipping "config.h-dist" and force people to at least review
it before copying it into config.h.  (People who love the defaults can
just symlink it.)

If you start using imake, I'll cry.
	/r$

Re: configuration parameters

[Chris Siebenmann]

 Actually, I'll disagree here; I think the combination of the Makefile and the
'canned' stuff in config.h has worked fine. It also (importantly!)
keeps the number of files one usually has to edit when moving
rc from platform to platform down to one (Makefile), which people
are used to editing.

	- cks

configuration parameters

[Byron Rakitzis]

rc's configuration has become unweildy. I want to try something cleaner
than that ugly makefile. Is the solution shown below satisfactory?

(the file that follows replaces the current config.h:)

/*
 * Configuration parameters for rc. Suggested defaults are at the bottom
 * of this file (you should probably look at those first to see if your
 * system matches one of them; you can search for the beginning of the
 * defaults section by looking for the string "#ifndef CUSTOM"). If you
 * want to override the suggested defaults, define the macro CUSTOM.
#define CUSTOM
 */

/*
 * (Note that certain default settings redefine this macro)
 * DEFAULTPATH the default search path that rc uses when it is started
 * without either a PATH or path environment variable. You must pick
 * something sensible for your system if you don't like the path shown
 * below.
 */
#define DEFAULTPATH "/usr/ucb", "/usr/bin", "/bin", "."

/*
 * Define the macro NODIRENT if your system has <sys/dir.h> but not
 * <dirent.h>. (e.g., NeXT-OS and RISCos)
#define NODIRENT
 */

/*
 * Define the macro SVSIGS if your system has System V signal semantics,
 * i.e., if "slow" system calls are interrupted rather than resumed
 * after returning from an interrupt handler. (If you are not sure what
 * this means, see the man page for signal(2). In any case, it is probably
 * safe to leave this macro undefined.)
#define SVSIGS
 */

/*
 * Define the macro NOCMDARG if you do not have /dev/fd or fifos on your
 * system. You may also want to define this if you have broken fifos.
 * For example, if you have a Sun with /tmp mounted as a ramdisk
 * (type "tmpfs") then you cannot use fifos in /tmp (sigh).
#define NOCMDARG
 */

/*
 * Define the macro DEVFD if your system supports /dev/fd.
#define DEVFD
 */

/*
 * Define the macro NOLIMITS if your system does not support Berkeley
 * limits.
#define NOLIMITS
 */

/*
 * Define the macro NOSIGCLD if your system uses SIGCLD in the System
 * V way. (e.g., sgi's Irix)
#define NOSIGCLD
 */

/*
 * Define the macro READLINE if you want rc to call GNU readline
 * instead of read(2) on interactive shells.
#define READLINE
 */

/*
 * Define the macro EDITLINE if you want rc to call Simmule Turner's
 * readline-like library. (it's about 1/10 the size of GNU, but with
 * fewer options) Also uncomment the EDITLIB variable in the Makefile.
#define EDITLINE
 */

/*
 * Define the macro NOEXECVE if your Unix does not interpret #! in the
 * kernel, and uncomment the EXECVE variable in the Makefile.
#define NOEXECVE
 */

/*
 * If you want rc to default to some interpreter for files which don't
 * have a legal #! on the first line, define the macro DEFAULTINTERP.
#define DEFAULTINTERP "/bin/sh"
 */

/*
 * If your /bin/sh (or another program you care about) rejects
 * environment variables with special characters in them, rc can put
 * out ugly variable names using [_0-9a-zA-Z] that encode the real
 * name; define PROTECT_ENV for this hack. (Known offenders: every
 * sh I have tried; SunOS (silently discards), NeXT (aborts with
 * error), SGI (aborts with error), Ultrix (sh seems to work, sh5
 * aborts with error))
#define PROTECT_ENV
 */

/* Beginning of defaults section: */

#ifndef CUSTOM

/*
 * Suggested settings for Sun, NeXT and sgi (machines here at TAMU):
 */

#ifdef NeXT
#define NODIRENT
#define	PROTECT_ENV
#define NOCMDARG
#endif

#ifdef sgi
#define SVSIGS
#define NOSIGCLD
#define	PROTECT_ENV
#undef DEFAULTPATH
#define DEFAULTPATH "/usr/bsd", "/usr/sbin", "/usr/bin", "/bin", "."
#endif

#ifdef sun
#define PROTECT_ENV
#undef DEFAULTPATH
#define DEFAULTPATH "/usr/ucb", "/usr/bin", "."
#endif

/*
 * Suggested settings for HP300 running 4.3BSD-utah (DWS):
 */

#if defined(hp300) && !defined(hpux)
#define NODIRENT
#define NOCMDARG
#define DEFAULTINTERP "/bin/sh"
#define PROTECT_ENV
#endif

/*
 * Suggested settings for Ultrix
 */

#ifdef ultrix
#define PROTECT_ENV
#define DEFAULTINTERP "/bin/sh"	/* so /bin/true can work */
#endif

/*
 * Suggested settings for RiscOS 4.52
 */

#ifdef host_mips
#define NODIRENT
#define PROTECT_ENV
extern int errno; /* not defined in the mips <errno.h> !?!?! */
#endif

#endif /* CUSTOM */