El 12/03/10 18:30, 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!!
>
>
>
Álvaro, estaba leyendo tu correo sobre el script que utilizas para el
mantenimiento de varias versiones de PostgreSQL en tu PC, y me quedó una
duda. Me dices acá que runpg config: ejecuta el ./configure de manera
estándar, pero que le cambiaste varios parámetros para que ya los tome
por defecto.
¿Cuáles fueron lo que cambiaste?
Y lo último, luego de que yo hago algún cambio en el configure, como yo
le digo a las fuentes que se ajusten a estos cambios. ¿Esto tiene que
ver con GNU/autotools?
Saludos