Обсуждение: "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.