Re: Ambientes de Desarrollo para versiones de PostgreSQL-8.4 y para 9.0alpha4

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: "Ing(dot) Marcos Ortiz Valmaseda" <mlortiz(at)uci(dot)cu>
Cc: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, POSTGRESQL - Ayuda <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Ambientes de Desarrollo para versiones de PostgreSQL-8.4 y para 9.0alpha4
Date: 2010-03-12 23:30:02
Message-ID: 20100312233002.GK3663@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Ing. Marcos Ortiz Valmaseda escribió:
> Jaime Casanova escribió:
> >2010/3/12 Ing. Marcos Ortiz Valmaseda <mlortiz(at)uci(dot)cu>:
> >>Recuerdo Jaime, que cuando Álvaro y tú vinieron acá, él tenía en su laptop
> >>esto configurado. Él ejecutaba pgsql84env si mal no recuerdo y en el mismo
> >>prompt de comandos le salía una especie de environment usando esta versión
> >>de PostgreSQL, y creo que lo hizo con Debian, porque es lo que tiene
> >>instalado en su PC si mal no recuerdo.
> >>
> >
> >ah! pero sino me equivoco eso ha de ser solo un script que cambia el
> >directorio levanta la base apropiada y setea variables de ambiente...
> >
> >aunque si se veia bonito y es mejor que hacerlo manualmente ;)
> >
> Umm, ya entendí.
> OK, tendré que preguntarle entonces a él cómo lo hizo, lancé la
> pregunta aquí para si otro a lo mejor quiera hacer lo mismo
> compartirlo con todos.

Este es mi script. Se llama "runpg" y hace muchas cosas, dependiendo
del segundo parámetro (el primer parámetro lo describo más adelante).
"config" invoca configure con los parámetros estándar (que yo defino
dentro del mismo script, o bien los puedo sobreescribir con un archivo
CONFIGURE_ARGS dentro del árbol del código fuente); "build" construye
(make); "install" hace un make install; "init" hace un initdb en la
ubicación estándar que yo defino; "server" echa a andar el postmaster;
"client" abre un psql; "check" y "pcheck" son para ejecutar los tests de
regresión, serial y paralelo respectivamente (requiere tener el server
andando); tags actualiza el archivo de ctags y cscope; changelog genera
el archivo ChangeLog para esa rama usando cvs2cl; rmderived borra los
archivos derivados; update hace un cvs update; showdiff hace un cvs diff
y lo pasa por un pager (obviamente puedes redirigirlo si quieres guardar
el parche en un archivo); touchchanged hace un "touch" de todos los
archivos modificados (esto sirve para forzar a que se recompilen); edit
abre un "vi -g" en el directorio base del código fuente.

Si uno hace "runpg commands" da una lista de órdenes que conoce (esto es
útil para el "bash completion")

El primer parámetro debe ser el nombre de un "cvs checkout" de una rama,
y el nombre debe empezar con un número, el cual se suma a 55432 para
obtener el nombre de puerto base que se pasa a --with-pgport. (Yo uso
nombres como "84_rel" y así, de manera que cada nombre es fácil de
recordar y quedan en puertos distintos, así que puedo tener los servers
corriendo simultáneamente).

Si uno le da el nombre de la rama pero ninguna otra opción, emite una
serie de definiciones de variables de ambiente. Eso se puede agregar al
ambiente existente. Por ej. yo uso `runpg 84_rel` y define PGDATA,
PGPORT, y otras cosas útiles.

El código se debe poner en un directorio con esta estructura:

pgsql/
source/
84_rel
83_rel
etc
build/
84_rel
etc
install/
(Esto se ubica en /pgsql normalmente, pero uno puede definir la variable
de ambiente PGROOT para cambiar esto. Yo tengo "export
PGROOT=~/Code/pgsql" o algo por el estilo).

Cuando uno hace "config" de una rama del source, se crea el directorio
dentro de build y se ejecuta configure allí; los .o quedan en ese otro
directorio (esto se conoce como una construcción VPATH).

Además tengo un mecanismo rudimentario pero suficiente para hacer
completación automática de órdenes en bash. Finalmente, tengo un
pequeño script que define funciones para cambiar de un directorio a
otro, por ej. si estás en source/84_rel/src/backend y ejecutas "cdbld"
te deja parado en build/84_rel/src/backend. También existen cdinst y
cdsrc. Además cdpg que te posiciona en pgsql/ (si es que no le pasas
ningún parámetro) o bien puedes hacer cdpg 84_rel y te deja en
pgsql/84_rel. Como también tiene completación automática, puedes darle
cdpg 84<tab> y luego te va completando con los directorios que existen
dentro (o sea cdpg 84<tab>s<tab>bac<tab> te completa a
84_rel/src/backend, etc etc)

Hace unos años le pasé este script a Michael Glaesemann y él hizo unas
cuantas modificaciones para sus propósitos, que yo nunca llegué a
adoptar (por pereza, no porque no me gustaran). A Germán Poo también se
lo pasé años después, y él hizo un repositorio Mercurial en alguna
parte ... ahh, acá está: http://pgsql.calcifer.org/settings/ ... ah!
si me hubiera acordado de verlo antes me habría ahorrado tener que
escribir la explicación otra vez!!

--
Alvaro Herrera http://www.amazon.com/gp/registry/3BP7BYG9PUGI8
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)

Attachment Content-Type Size
runpg text/plain 6.3 KB
pgcd text/plain 708 bytes
.bash_completion text/plain 1.0 KB

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Julio Cesar Rodriguez Dominguez 2010-03-13 00:16:00 Conexiones muertas.
Previous Message Ing. Marcos Ortiz Valmaseda 2010-03-12 22:22:55 Re: Ambientes de Desarrollo para versiones de PostgreSQL-8.4 y para 9.0alpha4