Thread: "Localizing" paths?

Balkrishna Sharma <b_ki@hotmail.com> wrote on -admin:

> Thanks. If I want to do at system-wide level, where do I store the psqlrc file (assuming I want to change the timing
behaviorsystem-wide)? 
> (CentOS 5, Postgres 8.4)
> $ ./pg_config --sysconfdir/opt/PostgreSQL/8.4/etc/postgresql
> But I don't have /opt/PostgreSQL/8.4/etc/postgresql directory. Just creating the directory and putting a psqlrc file
overthere does not seem to work. 
> [...]

This got me wondering: With the 8.4 RPMs, in psql's man
page, there is an unexplained
"*PREFIX*/share/psqlrc.sample"; the sample psqlrc installed
in /usr/share/pgsql/psqlrc.sample (sic!) says:

| --  Copy this to your sysconf directory (typically /usr/local/pgsql/etc) and
| --  rename it psqlrc.

Would it be feasible and desirable to "localize" the paths
in the configure stage? Pro: Fewer guesses by new users.
Con: Adds another level of complexity to the build system.

Tim

Tim Landscheidt <tim@tim-landscheidt.de> writes:
> Would it be feasible and desirable to "localize" the paths
> in the configure stage? Pro: Fewer guesses by new users.
> Con: Adds another level of complexity to the build system.

The bigger "con" is that anyone reading the docs on-line would be
given information that might be inappropriate for their platform.

            regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> wrote:

>> Would it be feasible and desirable to "localize" the paths
>> in the configure stage? Pro: Fewer guesses by new users.
>> Con: Adds another level of complexity to the build system.

> The bigger "con" is that anyone reading the docs on-line would be
> given information that might be inappropriate for their platform.

Why? That would only be the case if the on-line docs were
copied verbatim from some developer's working directory (or
a buildfarm box). I don't know the current workflow, but it
shouldn't be a problem to "./configure --host=DOC-DUMMY &&
make www-install".

  The biggest con I see is with the generation. If I under-
stood the discussion on the diagrams correctly, the tar
balls for the packagers have the documentation already done,
so the generation of the docs would either have to be pushed
to a later stage, or the users of packages wouldn't have any
benefit at all.

  So, looking at the pro: Shelved it.

Tim

Tim Landscheidt <tim@tim-landscheidt.de> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The bigger "con" is that anyone reading the docs on-line would be
>> given information that might be inappropriate for their platform.

> Why? That would only be the case if the on-line docs were
> copied verbatim from some developer's working directory (or
> a buildfarm box).

They have to be built *somewhere* ...

            regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Tim Landscheidt <tim@tim-landscheidt.de> writes:
>> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> The bigger "con" is that anyone reading the docs on-line would be
>>> given information that might be inappropriate for their platform.

>> Why? That would only be the case if the on-line docs were
>> copied verbatim from some developer's working directory (or
>> a buildfarm box).

> They have to be built *somewhere* ...

That's why the paragraph read:

| Why? That would only be the case if the on-line docs were
| copied verbatim from some developer's working directory (or
| a buildfarm box). I don't know the current workflow, but it
| shouldn't be a problem to "./configure --host=DOC-DUMMY &&
| make www-install".

Tim

On mån, 2010-07-05 at 20:16 +0000, Tim Landscheidt wrote:
> Would it be feasible and desirable to "localize" the paths
> in the configure stage? Pro: Fewer guesses by new users.
> Con: Adds another level of complexity to the build system.

The documentation is shipped pre-built in the source tarball.  So other
than with a sed, we can't really change it to match local situations.