Re: Before I call it a bug - some comments and questions

Tom and Chris - thank you for your answers. There are several reasons for
not including /usr/local/include. Some of those reasons are that I do not
want to be adding files to /usr/include - when it concerns dependencies I
have had to build before getting started. But that is my choice. No further
comment.

And while I can understand that pgsql should not run as root, I usually
build as root - so the automatic testing fails. When I ran make as 'michael'
the test failed but an installation to /usr/local started (and failed,
fortunately).

Perhaps it has to do with gmake not being my default make, but what I would
like to see (and what I recall from when I built an version 8.4.2
distribution) is that make just compile it, make test - install it, and
ideally, without modifying the configure command, be able to make an install
to a "distr" area to construct a distribution in a native AIX format
(installp).

Re: the install to distribution area - I'll work on that myself, unless you
know something simple for me. However, I would appreciate suggestions on how
to get make be less all-inclusive.

Thanks again,
Michael

On Thu, Sep 9, 2010 at 5:21 PM, Chris Browne <cbbrowne(at)acm(dot)org> wrote:

> mamfelt(at)gmail(dot)com (Michael Felt) writes:
> > I have just run compiled postgres on AIX (AIX 5.3, pgsql version 8.4.4)
> and
> > have a few surprises regarding the make process.
> >
> > 1. Very nice - it found gmake as /usr/local/bin/make and called
> GNUmakefile
> > 2. The make completes and it starts a test.
> > -- As I build, generally, as root - this failed because initdb does not
> want to
> > run as root
> > -- su to another user after changing ownership of the files, fails
> because not
> > enough space (maybe check for space)
> > -- enlarge filesystem, run make again, tests all succeed, and then make
> fails
> > trying to install docs (not root!)
> > --- why is the initial make installing/copying anything outside of the
> project
> > directory (in this case it was /usr/local/pgsql if I recall correctly).
> > --- My non-root user has no right to write there, so the "build" failed
> again.
> >
> > 3. A question: what is the best way to get the make process to install in
> a
> > alturnate directory. Some projects use an environment variable.
>
> See the output of
>
> ./configure --help
>
> Commonly, I find it sufficient to specify the alternate location via:
>
> ./configure --prefix=/path/where/pg/stuff/should/live
>
> That implies bin/, include/, share/, lib/ and other such target
> directories. If you have very specific needs, configure options should
> hopefully accommodate them.
>
> > 4. Minor point: why is /usr/local/include not in the -I list by default?
> I had
> > to add CFLAGS=-I/usr/local/include for configure to complete.
>
> That's not a standard place to put #include files across all of the
> operating systems on which Postgres runs, so it wouldn't be proper to
> have it as a default.
>
> Not all systems have /usr/local/include, and on some systems, adding
> this would point the compile to *wrong* code. Consider the case where
> an engineer at a company like Red Hat (Tom? ;-)) is building official
> packages for a Linux distribution.
>
> - On the machine where the build is being done, there might well exist a
> /usr/local/include directory.
>
> - But it shouldn't be used, because the *right* #includes to use for the
> build are in /usr/include.
>
> - They might have /usr/local/include there specifically as a test that
> programs should *NOT* be referencing it without specific instruction
> to do so! I could imagine stowing #includes there that are designed
> to make stuff break. Probably not a good thing on an Official Build
> Server, but an excellent torture test for a QA server :-).
>
> --
> (format nil "~S(at)~S" "cbbrowne" "gmail.com")
> The statistics on sanity are that one out of every four Americans is
> suffering from some form of mental illness. Think of your three best
> friends. If they're okay, then it's you. -- Rita Mae Brown
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>