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 <cbbro...@acm.org> wrote: > mamf...@gmail.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" "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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs >
