El 12/03/10 18:30, Alvaro Herrera escribió:
Á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.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!!
¿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
<<attachment: mlortiz.vcf>>
- Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
