Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA00776; Fri, 5 Feb 93 17:17:29 -0800
Message-Id: <9302060117.AA00776@postgres.Berkeley.EDU>
From: Marc Teitelbaum <marc@vangogh.CS.Berkeley.EDU>
Subject: Re: Concern about new building environment
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of Fri, 22 Jan 93 09:22:51.
Date: Fri, 05 Feb 93 17:17:02 PST

> (Message inbox:13750)
> From:  witr@rwwa.COM
> Subject:  Concern about new building environment
> Date:  Fri, 22 Jan 93 09:22:51 -0800
> To:  postgres@postgres.Berkeley.EDU
> Return-Path:  pg_adm@postgres.Berkeley.EDU
> Sender:  pg_adm@postgres.Berkeley.EDU
> Content-Type:  text
> Content-Length:  1128
> 
> I am greatly concerned (perhaps wrongly) that the upcomming release's
> use of a new make will *reduce* rather than *increase* portability.
> Having just been through a rather painfull yet successfull port to
> SVR4, I am wary of any potential for *increased* non-portability of
> the postgres codebase.

It makes portability easier since the build environment is more flexible.

> Thus:
> 
> 1) Will the new make environment (plus any ancillary tools) be
> distributed *with* postgres?

yes 

> 
> 2) If not, are these tools readily (and freely) available, and if so
> where?
> 
> 3) Is the new build going to assume that this new make is called
> ``make'' (and thus conflicting with whatever system-installed make
> there is)?

no.  by default it installs it as "bmake" in /usr/local/{bin,lib}
You can change it to be called anything you want and put it whereever.

> 
> 4) How long is it likely to take to port the new make, before I can
> even begin to port the new postgres?

Well, we do the ports here to the platforms we "support".  For you to port
it somewhere else, well, the best i can say is it didn't require much.
mostly a library routine missing here, a broken compiler there (like
a version of ultrix was broken around "void" in "?" expressions - so we
just -D"void=char *" for that one).  If you are doing your own port and
theres a routine missing, just send me mail and I'll send you the source
from our library.  mostly, i didn't have to change the source at all.

> 
> 5) Is the new build system going to correct unwarrented bsdocentric
> assuptions, like: one always uses ranlib, each port always uses
> exactly the same set of source files, shared objects end on .o, etc?

Actually, it's an incorrect assumption that we would consider using ranlib(1)
unwarranted: we port for the systems we target.  Whether to use ranlib
or a special flag on ar(1) is cake, especially with the new make (it
has conditional constructs so you can easily support this sort of thing).
> 
> Thanks for any answers that can be supplied!
> 
> ---
>  Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM
>  R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA

In general, sure we would like to make the code as portable as possible.
But this is a research group and we have limited engineering, and our
emphasis is going to be on cleaning up the existing code and smoothing
out all the new features.

Marc Teitelbaum