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

Поиск
Список
Период
Сортировка
От Michael Felt
Тема Re: Before I call it a bug - some comments and questions
Дата
Msg-id AANLkTik3hDNh02MP+jDU0bxDLDk6MMzHQXdQRVcbtkqe@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Before I call it a bug - some comments and questions  (Michael Felt <mamfelt@gmail.com>)
Список pgsql-bugs
Guess this means no further suggestions. I'll hack at it then.

On Fri, Sep 10, 2010 at 2:26 PM, Michael Felt <mamfelt@gmail.com> wrote:

> 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@acm.org> wrote:
>
>> mamfelt@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@~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
>>
>
>

В списке pgsql-bugs по дате отправления:

Предыдущее
От: "Nate Carson"
Дата:
Сообщение: BUG #5655: Composite Type Handles Null Incorrectly
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: 9.0 Bug: cannot build against python3.1, with two versions of python in the environment