Subject: Concern about new building environment

From: [email-masked]
Date: Fri, 22 Jan 93 09:22:51 -0800

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.

Thus:

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

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)?

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

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?

Thanks for any answers that can be supplied!

---
 Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: [email-masked]
 R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA

---

From: Marc Teitelbaum <[email-masked]>
Date: Fri, 22 Jan 93 11:39:05 PST

The new make is of course being shipped directly with the
postgres source and will compile and run on the platforms
that we support.  When porting to a new platform you will
have to make sure, obviousely, that the bmake compiles and runs
there too (its directly in the postgres source tree with a 
V7 bootstraping makefile).  The code is a whole lot more portable 
than the postgres code itself, so if you have any problems porting 
bmake, you can be sure you'll be spending 10 to 15 times as much
time porting the postgres code - so i wouldn't worry :)  But, like I
said, it comes working with any supported platform.

It's a much better solution, IMHO, than the imake solution that X
uses (in retrospect that is, I'm not bashing X for trying the
imake scheme).  The make code does what we want and is freely
redistributable and available off uunet.  I haven't seen the GNU
make, (and sorry john or rms) but the copyleft IS a restrictive
license compared to the freely redistributable BSD license on
bmake (actually, BSD just calls it make - *we* call it bmake).
When offered with a choice between a copyleft program and a
freely redistributable program of comparable quality, i will choose
the latter as it causes less headaches for the end users who
wish to reship the code.  Putting a copyleft on a program is
a personal (and political) statement that anyone can make, but no one
should be forced to make.  The university policy is to make
code freely redistributable with no strings and I support that
when there's no strong reason not to.

Marc

---

From: Marc Teitelbaum <[email-masked]>
Date: Fri, 05 Feb 93 17:17:02 PST

> (Message inbox:13750)
> From:  [email-masked]
> Subject:  Concern about new building environment
> Date:  Fri, 22 Jan 93 09:22:51 -0800
> To:  [email-masked]
> Return-Path:  [email-masked]
> Sender:  [email-masked]
> Content-Type:  text
> Content-Length:  1128
> 

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

> distributed *with* postgres?

yes 

> ``make'' (and thus conflicting with whatever system-installed make

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.

> 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.

> 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).
>  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

---

From: Marc Teitelbaum <[email-masked]>
Date: Fri, 05 Feb 93 17:33:44 PST

AHEM!!.... I didn't send this message.  Would whoever reposted
this old message of mine please let me know, or at least please don't
do that again.  I don't mind old messages being reposted, but please don't
make it look like *I* sent it.  For one, the details of this response
are geared to the eariler letter, not the current one.  And two,
I already replied to [email-masked]'s message with a line by line
response...

Marc

> (Message inbox:13751)
> From:  Marc Teitelbaum <[email-masked]>
> Subject:  Re: Concern about new building environment
> Date:  Fri, 22 Jan 93 11:39:05 PST
> In-Reply-To:  Your message of Fri, 22 Jan 93 09:22:51.
>