Alvaro Herrera escribió:
Ing. Marcos Ortiz Valmaseda escribió:
Jaime Casanova escribió:
2010/3/12 Ing. Marcos Ortiz Valmaseda <mlor...@uci.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!!
Sencillamente genial !!!!
No tengo palabras para esto.
Con esto creo que ya tengo el trabajo bastante adelantado para el
desarrollo.
Realmente veo que pensaste en todo aquí.
Veo que los únicos sistemas de control de versiones que tienes
soportados son CVS y Subversion, ya que veo que Git no está soportado.
Me gusta Git para trabajar, así que voy a hacerle unas modificaciones
para que lo soporte. Luego que lo termine, te lo paso si quieres.
Saludos y gracias de nuevo.
--
--------------------------------------------------------
-- Ing. Marcos Luís Ortíz Valmaseda --
-- FreeBSD Fan/User --
-- http://www.freebsd.org/es --
-- Linux User # 418229 --
-- Database Architect/Administrator --
-- PostgreSQL RDBMS --
-- http://www.postgresql.org --
-- http://planetpostgresql.org --
-- http://www.postgresql-es.org --
--------------------------------------------------------
-- Data WareHouse -- Business Intelligence Apprentice --
-- http://www.tdwi.org --
--------------------------------------------------------
-- Ruby on Rails Fan/Developer --
-- http://rubyonrails.org --
--------------------------------------------------------
Comunidad Técnica Cubana de PostgreSQL
http://postgresql.uci.cu
Centro de Gestión de Datos (DATEC)
Contacto:
Correo: centa...@uci.cu
Telf: +53 07-837-3737
+53 07-837-3714
Universidad de las Ciencias Informáticas
http://www.uci.cu
--
TIP 1: para suscribirte y desuscribirte, visita
http://archives.postgresql.org/pgsql-es-ayuda
