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

Alvaro Herrera escribió:
> 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!!
>
>
>
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: centalad(at)uci(dot)cu
Telf: +53 07-837-3737
+53 07-837-3714
Universidad de las Ciencias Informáticas
http://www.uci.cu