Aqui se termina de configurar el resto del Make...
Ahora viene la parte donde va a colgar nuestra aplicacion, y aqui veremos
como tenemos que definir que ficheros van a formar parte de nuestra
aplicacion. Este sera otro fichero Makefile, como no ;-)
Pero este Makefile simplemente selecciona a otro , ya dije que veremos
tanto Windows como GNU/Linux, dependiendo de la variable de entorno o la macro
HB_COMPILER.
Entonces, el fichero principal de GNU Make para test ejecuta esto:
ifeq ($(HB_COMPILER),mingw32)
include Makefile.mingw32
else
include Makefile.linux
endif
Obviamente, se podria haber mejorado solamente en la creacion de un unico
fichero, pero aqui como puedes ver, selecciona uno u otro.
Miraremos el Makefile.mingw32 para que veais como debeis de montarlo.
TARGET = demo # NOMBRE DEL PROGRAMA
SOURCES = demo.prg demo2.prg # LISTA DE PRGS QUE FORMAN EL PROGRAMA
PRGFLAGS=-I../include # FLAGS PARA HARBOUR
LIBS= -L../LIB -lMisLib `pkg-config --libs gtk+-2.0` #LIBRERIAS PARA LINKAR
include ../Rules.make
Ya tenemos disponible el sistema para empezar a jugar con el.
Ahora solamente nos falta mirar como llamar a todos ellos.
En nuestro directorio raiz, tendremos un fichero llamado Makefile, que
contiene las ordenes que debe de ejecutar:
##################################
# Makefile principal
##################################
all:
make -C src
make -C c_lib
clean:
make -C src clean
make -C c_lib clean
make -C tests clean
install: all
make -C src install
make -C c_lib install
.PHONY: clean install
[Nota: Para los que usan Mingw32 desde linea de comandos de Windos, el make
como tal no existe, se llama mingw32-make, solamente teneis que cambiarle
el nombre ]
Dicho fichero lo unico que hace es ejcutar el make segun le pasamos
parametros. Por ejemplo:
c:\mi proyecto\>Make all
Creara las librerias de SRC y C_LIB
c:\mi proyecto\>Make install
Esta es muy buena, para instalar las librerias, tendra que ejecutar all y
despues se ira a copiar al directorio LIB las librerias generadas.
c:\mi proyecto\>Make clean
Lo que hace es borrar todos los ficheros necesarios para permitir volver a
generar el ejecutable, dicho sea de paso, tambien se cargara a dicho
ejecutable.
Ya esta ? Casi.... como debeis recordar, en TESTS funciona distinto, porque
podemos tener varios Makefiles para distintos proyectos.
En ese caso, simplemente nos vamos al directorio y ejecutamos Make,
y te generara el ejecutable en cuestion.
Podemos crear distintos nombres por aplicacion que queramos generar, y llamar
al Make como : Make -f MiAplicacion1
Una vez que tengamos configurado este sistema o similar, mirar que sencillo,
es tener todo el control en un par de lineas:
C:\Mi Proyecto\>Make clean
C:\Mi Proyecto\>Make install
C:\Mi Proyecto\>cd TESTS
C:\Mi Proyecto\TESTS\>Make
o otro make
C:\Mi Proyecto\TESTS\>Make -f SegundoMake
Ya esta! Se termino.....
Creo que esto terminara con muchos de los problemas actuales a la hora
de tener que estar generando librerias, compilar codigo, etc...
Solamente tendremos que tener especial cuidado en meter los prgs que formen
parte de nuestra aplicacion, el resto, ya se encargara Make de mantenerlo.
Espero al menos iluminaros un poco para que podais investigar por vuestros propios medios otros sistemas distintos pero con la misma filosofia, la sencillez de generar aplicaciones y/o librerias no nos supongan un calvario.
Saludos.
Seguimos....con los Makefiles y su optimizacion....
3.- Como compilar/linkar
Despues de revisar como esta montado basicamente el fichero Rules.make,
pasaremos a saber exactamente que es lo que hay que hacer para que la cosa
vaya tomando forma.
Generalmente, y siguiente la estructura de archivos antes propuestas, vamos
a saber como podemos nosotros adaptar este sistema para nuestro uso
particular.
Hemos dicho , que el fichero Rules.make es el alma de nuestro esfuerzo por
hacer mas simple el hecho de compilar/linkar lo que sea.
En ese caso, vamos a ubicar dicho fichero en el directorio principal de
nuestro proyecto, en XWT es el propio directorio, ahi es donde tambien lo
dejaremos.
Entonces tenemos la siguiente estructura de directorios:
C:\Mi Proyecto\ --> En este directorio dejaremos Rules.make, mas otro fichero
Makefile que es el que invocara al resto, y lo veremos mas tarde.
Veamos ahora el resto de ficheros Makefiles que nos faltan y que estaran
cada uno ubicados en sus respectivos directorios, y que nos serviran para
notificar al Rules.make como tiene que actuar.
4.- Cambiando el comportamiento interno.
Empecemos pues por el primero:
\SRC\
En este directorio vamos a poner TODOS los .prg que formaran parte de nuestra
propia libreria, es decir, que TODO lo que haya aqui , se transformara
en una libreria, y ademas, puede contener tambien, si es necesario, partes
de codigo fuente en archivos .c
Esto nos es de gran utilidad para contener codigo de clases o/y funciones que
nos sera comun a TODOS nuestras aplicaciones que vayamos a realizar.
Dicho fichero, Makefile, lo analizamos entero pues este si que tienes que
entenderlo para afinar TU sistema :
[Nota:Partimos de la base del XWT por que asi podeis verlo vosotros mismos]
############################################
#
# Makefile para librerias en codigo .PRG
#
############################################
TARGET=libxwt.a
PRGFLAGS=-I../include
CFLAGS+=-I../include
XWT_INSTALL=../lib
CSOURCES=xwt_api.c
include ../Rules.make
TARGET Nombre de la libreria que queramos que se genere.
PRGFLAGS Flags que queremos pasarle a Harbour.
CFLAGS Flags que queremos pasarle a compilador de C.
XWT_INSTALL Donde esta ubicado el directorio de las librerias para
copiar la libreria aqui generada.
fichero de C y queremos que forme parte de la libreria. Usualmente no sera
necesario que lo indiques, pues lo borrais y y hasta ;-)
¿ Que tienes mas de un .C ? pues tan simple como:
CSOURCES= uno.c dos.c tres.c \
cuatro.c cinco.c ....etc...
y por ultimo y muy importante es la siguiente linea:
include ../Rules.make que lo unico que hace es coger TODO lo del
fichero Rules.make
Lógicamente, el nombre de los flags los podemos cambiar, por ejemplo, donde
pone XWT_INSTALL, pues nos quedaria mejor poner LIB_INSTALL, y redefinirlo en
todos los Makefiles que hagan uso de dicha macro, y sobretodo en Rules.make
Ya esta , con esto, lograreis montar una libreria , sin especificar
absolutamente nada.
Si quereis que otro archivo fuente .prg o .c , forme parte de vuestra libreria
pues lo copiais aqui y punto, despues se llama a Make para que compruebe si
hace falta o no generar la libreria de nuevo.
Ahora nos toca hacer los mismo, pero para nuestro codigo en C.
[ Nota: No tengais en cuenta al pie de la letra todo. Si no tuvierais
codigo en C para generar una libreria aparte, lo descartais sin mas, y
simplemente luego en el Make principal modificais para que no vaya a ejecutar
un Makefile que no va a existir ]
Si os fijais , tenemos en el XWT, una directorio SRC, y dentro un par mas,
nos quedaremos con el primero, el xwt_gtk, ya que este es el que se usa
con las herramientas GNU, el otro se usara a partir de los Make usando el
Borland o el de Microsoft, y ya dije que no perderia el tiempo con ello.
Como veis, mi propuesta es separar y quitar de SRC el codigo de C, sera
tan simple como que el Make principal llame a otro sitio en vez de donde esta
ahora ubicado.
Viendo el Makefile en cuestion, /xwt/src/xwt_gtk, tenemos una serie de macros
que veremos a continuacion:
TARGET=libxwt_gtk.a
CFLAGS+=-I. -I../../include `pkg-config --cflags gtk+-2.0`
SOURCE_TYPE=c
XWT_INSTALL=../../lib
include ../../Rules.make
TARGET ya sabemos para que nos servira.
CFLAGS le pasa opciones de compilador de C
XWT_INSTALL ya lo vimos.
include Idem.
SORCE_TYPE ESTE ES MUY IMPORTANTE, ya que informa que los ficheros
que va a tratar aqui seran para el compilador de C, si no, entraria el
compilador de Harbour y se pegaria de ostias. ;-)
[Nota:pero si os fijais , vereis ../../, y esto
es porque desciende un nivel mas, pero como nosotros lo vamos a poner
al mismo nivel que el directorio SRC, lo cambiamos a ../, igual que el Makefile
del SRC ]
Ya tenemos listo dos librerias que se generaran automaticamente a traves
del Make.
Saludos.
..y el proximo capitulo...el resto...
Como montar el /TESTS y el makefile principal
2)Parte 2.- Definicion de las reglas (...continuacion...)
Ahora haremos un alto, para que todavia sea mas preciso.
Como bien sabeis, teneis una variables de entorno disponibles para harbour y
que son de gran utilidad a la hora de generar las librerias y ejecutables de
harbour, y que son necesarias para saber que make debe de ejecutar dependiendo
del sistema que tengamos montado, como el compilador de C, etc...
Bien, dicho sistema tambien hara uso de dichas variables de entorno, o en su
defecto, podemos redefinirlas para que contengan el valor que queramos.
Como yo, supongo que muchos de vosotros tambien, tengo varios harbour para
distintos compiladores, entonces el usar el PATH, a veces es un engorro.
La solucion es tan sencilla como definir simplemente estas variables de
entorno:
Rules.make--------------------------------
#Para con Windows , añadido
HB_COMPILER = mingw32
HB_BIN_INSTALL = c:/hargw/harbour/bin
HB_INC_INSTALL = c:/hargw/harbour/include
HB_LIB_INSTALL = c:/hargw/harbour/lib
Al principio de la linea le informo , en este caso especial, que reescriba las
variables de entorno a estos valores, asi no tengo que modificar nada de .bat,
etc... del sistema en cuestion.
[ Umm.. un apunte que se me olvidaba...aqui solamente se van a usar
herramientas GNU, un dia de estos escribire porque. ]
Pasaremos por algo lo 'obvio' y que por deduccion es muy simple, y nos
pararemos en lo mas interesante.
#Opciones genericas del Make ( Generic make options )
ifeq ($(HB_COMPILER),mingw32)
CFLAGS += -Wall `pkg-config --cflags gtk+-2.0` -mms-bitfields -mwindows -I.
else
CFLAGS += -Wall -I.
endif
GT_LIBS=-lgtcgi
Aqui teneis una caracteristica ifeq(), significa que si en la variable
HB_COMPILER esta la cadena mingw32 , CFLAGS sera igual a un valor o a otro.
[ Nota: Dentro de las herramientas GNU que ha sido portadas a otras
plataformas como Windows, donde dice pkg-config, solamente funcionara si
habeis instalado y haceis correr el CygWin y estais en ese entorno.
Ahora bien, si haceis uso simplemente del compilador gcc, mingw32, desde
una consola comun de Windows, dicha cadena debe ser montada como:
$(shell pkg-config --cflags gtk+-2.0) ]
Bien, despues podemos definir el driver GT a usar de harbour, simplemente
donde pone la linea GT_LIBS, podeis definir el driver que querais.
[Nota: Aqui explicare haciendo uso de dos sistemas a la vez ya sea a traves
de Windows o de GNU/Linux]
Las macros que nos interesan, por ser programadores de Harbour, las explicare,
aunque generalmente ESO NO LO TOCAREIS!!
LIBFILES_ += Aqui definiremos las librerias propia de Harbour.
Esto no deberias de tocarlo, excepto si le dan por añadir alguna libreria
que no la tengas definida, definela aqui.
LIBFILES_+=Libreria del sistema que nos hagan falta, por ejemplo
para GNU/Linux debemos de linkar la -lgpm, para soporte del mouse en consola.
Si os fijais muy bien, vereis que hay un += y no un = a secas, eso es muy
importante para no machacar lo que previamente habia definido, asi que
tenerlo en cuenta.
Ahora veremos unas macros que las usaremos en otros makefiles y que finalmente
seran vistas desde aqui, para que veas que son y de donde vienen.
LIBDIR_ = $(LIBDIR) -L$(HB_LIB_INSTALL)
LIBS_= $(LIBS) $(LIBFILES_)
&(LIBDIR) es una macro declarada en el makefile de los directorios, y que nos
permite usarla EXCLUSIVAMENTE en ese makefile para permitir buscar librerias
en otra ruta distinta a la que tenemos originalmente a partir de
HB_LIB_INSTALL.
&(LIBS) es una macro que se compartara exactamente IGUAL a LIBDIR, pero en
este caso sera para librerias en concreto.
No busqueis en Rules.make, que no estan aqui ;-), si no que vienen impuestas
a traves de otros makefiles si estuvisen declaradas.
Despues viene el determinar el tipo de codigo que queremos procesar, y se
lo indicaremos a traves de la macro SOURCE_TYPE en nuestro makefile,
y por defecto cogera prg si no la hemos definido.
NOTA:
Donde pone strip, es una tool de GNU, por lo tanto, debes de tener las
GNU tools instaladas, sino no te funcionara, sirve para quitar simbolos
de debugger a los ficheros objetos
Te lo explico para que no pierdas el tiempo buscando... que parecemos ya a
google con tanto buscar ;-)
Despues vienen por lo que se conoce como reglas implicitas , como por ejemplo,
esta, que la comentare por ser un tanto especial.
%$(EXETYPE):%.o
$(CC) -o$@ $< $(LIBDIR_) $(LIBS_)
Para los que no saben o saben un poco, como yo, del uso del Make, una regla
implicita, es aquella por la cual utiliza los sufijos
(extensiones de los archivos) para determinar que comandos debe ejecutar.
[ Nota: Antes unas nociones basicas sobre variables automaticas.
$<. El nombre del primer prerequisito.
$@. El nombre del archivo del objetivo de la regla. ]
Como nuestro ejecutable va ser posible crearlo tanto en Windows como en
GNU/Linux, el EXETYPE puede ser o .EXE o simplemente nada, pues ya debeis
saber que en GNU/Linux no existe el concepto de extension de archivo, si no
si se puede o no se puede ejecutar.
Como veis , es una mera introduccion al fichero Rules.make, cuyo objetivo
no es explicar cada uno de los comandos, si no un poco su funciomaniento,
para mas adelante ver la importancia de este fichero en las siguientes
definiciones de los Makefiles que nos quedan por ver.
..continuara....
Me gustaria saber vuestra opinion al respecto sobre este tema,
¿ te parece interesante o por el contrario te estas aburriendo...ohhh ?
En la siguiente entrega...
Veremos la practica de todo este pollo,
y la importancia de Rules.make, que ya digo esto practicamente ni lo
tendreis que tocar, y como desde una simple instruccion podemos
compilar, generar librerias y generar la aplicacion en un instante...
La importancia del sistema GNU.
A los que venimos del sistema Windows y nos metemos en el sistema GNU
nos damos cuenta ,ilusos, que cosas que creemos que tenemos, hace
muchisimo tiempo que esta disponible en GNU, o en su defecto UNIX.
Puesto que empiezo a concebir el software libre como una alternativa,
si no , al tiempo, nada tienen que envidiar y hasta superan con creces
a sistemas propietarios tanto en calidad como en cantidad, si no,
hasta el propio sistema es mas robusto que el sistema windows, por mucho
que se gasten el dinero en propaganda, pero en fin, no voy a discutir
sobre ello en este post.
Paremos un momento el tiempo, y pensemos que existe solamente harbour,
ese compilador xBase que tanto gusta a los que leen este blog.
Hagamos un pequeño ejercicio, y veremos , como nos vamos encaminados
directamente a usar herramientas de GNU en nuestros sistemas Windows,
y a pesar de mas de uno se resiste a cambiar, graso error, se dara
cuenta que tarde o temprano tendra que meterse en ello, y se dara
cuenta que todo lo que aprende , lo podra aplicar a cualquier sistema
que use herramientas GNU , tanto UNIX comerciales, como MAC, etc...
Son herramientas que existen desde hace mucho tiempo en UNIX, y
que no se a santo de que, en los sistemas windows prefirieron
reinventar la rueda, y porque no la pueden patentar, que si , tambien.
Estas herramientas, empezando por el todopoderoso gcc, make, etc.,
las tenemos disponibles tambien para Windows, y seguimos usando
compiladores comerciales, como el Borland C o el VC++, eso si
en linea de comandos, para construirnos el compilador.
Que paradoja! Usamos sistemas propietarios y herramientas propietarias
para crearnos el compilador que es software libre.
Yo , debido a mi fascinacion por lo desconocido, a Joaquim lo estoy
volviendo loco, me da por mirar en GNU/Linux y ahora que se
que puedo hacer lo mismo para Windows, ya puedes saber lo contento
que estoy, y no tengo que estar pensado ni cambiar el chip,
cuando programo en uno en otro.
Todo lo que hago en uno, me sirve en el otro, y eso es ganar
muchisimo tiempo, que es de lo que se trata al final ;-)
EH!!! No me grites, que si , que tienes razon.
Mayormente, el principal problema viene dado de la mano de Fivetech, que no
proporciona las librerias para el compilador gcc, en sus variantes, y
decide seguir usando el Borland C y hasta hace poco, en comparacion, el VC+.
No logro entender el porque, Antonio, padre de la criatura que es Harbour,
no decide hacer tambien unas librerias para usar el gcc para Windows,
porque mas puro en libertad no se puede ser ;-)
Quizas deberiamos tirarles de las orejas por esto!!! :-)
Tambien los de Xailer estan haciendo lo mismo, y habria que decirles
que empiecen desde un inicio , ahora estan en beta, que la comercial
permita usar el gcc.
Lo que si se , es que ultimamente para avanzar en mi investigacion
sobre harbour y no tener que volver a investigar otra vez lo mismo,
pero de distinta manera, he optado por usar solamente herramientas GNU,
de esta manera , saltar a GNU/Linux, UNIX, MAC, etc.., me importara
un pimiento, porque el comportamiento sera IDENTICO!
Todos sabemos que el dominar una determinada herramienta como puede ser
la utilidad Make, no es moco de pavo, y aunque similares son el resto,
siempre es mejor aprender a usar una que la tendras disponible en
cualquier sistema operativo, por que GNU nos esta invadiendo, tanto
en sistemas libres como propietarios.
Poco a poco, la tendencia nos lleva a GNU, y poco a poco, mas y mas
herramientas, programas, etc., se estan introduciendo en el sistema
operativo Windows, y una vez que domines la totalidad de GNU en windows,
¿ de que te sirve Windows ? De nada.
Y lo que queda por venir. Esta ya hay programas de facturacion y contabilidad,
autenticos ERP, libres, y las empresas no son tontas, y lo unico que
quieren es que a la hora de problemas , detras de la linea haya alguien.
A las pymes pequeñas les da igual Windows que Linux, mientras el programa
tenga que hacer lo que supone que tiene que hacer, y si les sale gratis
ponerlo y probarlo, y colocarlo en las maquinas que les de la real gana,
mejor, pero lo que quieren es que alguien este detras para solucionarles
los problemas, ni mas ni menos.
Creo, que al final, a Windows le quedan dos telediarios, largos tipo urdaci,
pero dos al final y al cabo.
Uy!! Me callo que no termino nunca.....hasta otra....
Saludos.
Generacion de librerias y programas desde una misma linea de comandos
Usando GNU Make y otras cosas.
1) Parte
Una de las cosas que he estado buscando largamente a sido la generacion
de librerias tanto de codigo PRG como de Codigo C o una mezcla de ambos,
y generar una libreria o un .exe indistintamente.
Despues de buscar, hace tiempo que vi que dentro del proyecto xHarbour,
contrib, tenemos el XWT, en el cual hay implementado , bajo mi humilde punto
de vista, un sistema al que estaba buscando , y que esconde una potencia
inusual, para tan pocas lineas de codigo.
Intentare explicar como funciona, despues que tuve que abordar el estudio de
la herramienta Make, pues es imprecindible el conocimiento, al menos al nivel
basico de toda esa jerga incomprensible.
Aqui se hablara de GNU Make, por servirme tanto como GNU/Linux y Windows,
no perdiendo mas tiempo en descubrir como funcionan otros make, ya sea de
borland o de Microsoft, asi, aprendiendo uno, tengo mas que suficiente.
No voy a explicar aqui 'COMO' funciona exactamente GNU Make, si no una forma
de planificar nuestro codigo y que un solo comando realice solamente lo que
queramos, teneis manuales por internet, molestate en buscarlos ;-)
Asi, por basarme en el estudio de las reglas del make usadas en el proyecto
XWT, sera necesario que tengais las contrib de xHarbour para ir siguiendo el
hilo del texto.
1.- Objectivo y estructuracion.
2.- Definicion de las reglas
3.- Como compilar/linkar
4.- Cambiando el comportamiento interno.
+ Añadir mas librerias y directorios
1.- Objectivo y estructuracion.
La primera cuestion es definir como trabajar y hara un pequeño esforzo
de directorios para que lo comprendais, su estructura.
C:\Mi Proyecto\
|--- SRC // Directorio que contiene codigo PRG que formara una libreria
|--- C_LIB // Directorio que contiene codigo C que formara una libreria
|--- TESTS // Nuestros PRG que forman la fuente del programa.
|--- INCLUDE // Nuestros includes que haremos usos.
|--- LIB // Aqui se copiaran las librerias de SRC y C_LIB
En principio, esto es suficiente para la mayor parte de los usuarios.
Lo interesante, es que en NINGUN SITIO de SRC o C_LIB le vamos a definir los
fuentes a usar,
¿ Como es posible ?
Si , señores, solamente añadiendo el fichero en cuestion, a la hora de generar la libreria , solamente compilara ese fichero que hemos añadido al directorio, sin modificar para nada el fichero Makefile y construira la propia libreria con el nuevo fichero añadido.
Logicamente, este funcionamiento no nos interesa que lo haga en TESTS, porque
al igual nos es necesario tener dos ejecutables de dos fuentes distintas.
Esto, nos permite olvidarnos por fin de herramientas generadoras de
ficheros Makefiles, como pueden ser Front-End, Verce, Ajmake, etc..., para
gente que quiera pensar como se realizan las cosas.
2.- Definicion de las reglas
Para que todo el proceso funcione como un engranaje perfectamente engrasado,
y de eso se bastante , creeme, antes era especilista en roscas de precision,
tenemos que partir de un fichero que va a contener toda la maquinaria de
trabajo para el GNU Make.
Si os fijais, debereis de tener en el directorio /contrib/xwt/ un fichero
llamado Rules.make.
Dicho fichero es de gran importancia , pues es el que tiene las reglas de
funcionamiento, y que sera usado por el resto de makefiles que debes de
contener en los distintos directorios que quieras procesar.
Echemos un vistazo a dicho fichero, para entender como funciona para poder
adaptarlo a nuestras necesidades , ya sea para Windows o para GNU/Linux.
....en fin .... continuará....que si no se hace muy pesado....
y tu, ¿ todavia en pañales , y con los .bat de toda la vida, jejeje ?
Saludos.
Como saber a quien pertenece un trozo de codigo.....
Mirando por casualidad codigo fuente de OLE de Jose F. Gimenez,
y comparandolo el original con el xHarbour, me a llamado
poderosamente la atencion esto:
/source/rtl/win32ole.prg
* Copyright 2002 José F. Giménez (JFG) -
* Ron Pinkas -
Si observan el trabajo original del soporte para OLE , lo pueden
descargar directamente a traves del CVS spanish, yo veo 'cosas'
que son distintas en muchos aspectos y faltan cosas, lo primero
que sorprende es que hasta el nombre es diferente.
El codigo original:
**************************************************************************
* *
* Descripción: Clase TOleAuto() *
* *
* Autor: José F. Giménez (JFG) - jfgimenez@wanadoo.es *
* *
* Fecha: 6-11-2000 *
* *
* Revisado: 13-2-2001, 28-2-2001, 13-3-2001, 7-9-2002 *
* *
* Nota: basado en la clase TComObj() de FW 2.1 *
**************************************************************************
Esto a desaparecido de la cabecera de win32ole, y supongo que deberia
menciar tan y como estaba el original.
Es mas, lo que mas me intriga es la siguiente pregunta:
¿ Quien es dueño del (c) ?
Ahora hay 2 dueños, osease, que si yo cojo el codigo de win32ole.prg y le
añado un par de linea,
¿ Significa que tambien el (c) es mio, seremos 3, que paso con los que
han echo correcciones? pues si se sigue la revision del codigo, hay
mas gente que a contribuido a mejorar el soporte de OLE.
Yo no entiendo nada. Teoricamente, el (c) es del autor inicial, sin
posibilidad de 'añadirse' nadie mas o .. ¿ estoy equivocado ?
Que alguien me lo aclare.. po Dios.
Saludos.
A veces siento sana envidia de lo que es la gente de organizar,
por favor miren "http://jornadespl.upc.es/" , sobre Jornades de Software Libre,
hasta se traen a Ian Murdock, fundador de Debian, todo ello sin un pagar un
duro.
A veces me pregunto porque narizes no existe esto en el mundo xBase.
Gracias a "Olivares 2000" hemos podido disfrutar , aunque no
a tanto nivel, si ampliar simplemente un poquito los conocimientos.
Particularmente, en las 2 reuniones no aprendi nada, porque no tenia nada
que aprender ;-), por que la verdad es que no da tiempo para nada, nada mas
que conocer a la gente del foro, vamos , en plan camping ;-)
Es frustante la cantidad de conocimientos que todavia no poseemos a nivel de
xBase / C( Con xBase ).
Quizas me hubiese gustado ir al evento donde Bruno Cantero ilustro con sus
conocimientos interno de Clipper/C y lo compartio con los asistentes, y
segun testimonios fue espectacular.
Me hubiese gustado ir, pero me fue imposible, quizas otro año.
Lo que si se, es que si la gente no sube cada vez un peldaño mas , nuestro
lenguaje se ira quedando huerfano, y no por que no halla ganas , si no que
cada vez es mas complejo intentar usar las nuevas tecnologias y para ello
necesitas bajar a las cavernas del lenguaje, y muy pocos estan capacitados.
Si los que estan capacitados no trasmiten sus conocimientos, seguiremos en la
oscuridad, sin poder ayudar en nada.
Por ejemplo, hace dias que quise saber, por simple curiosidad ya que segun
dicen desde xHarbour , harbour tiene un BUG, a la hora de saltar desde C
a una funcion estatica, que no deberia saltar cuando realmente salta.
Pues bien, pregunte como se hace, y si habia algun ejemplo de ello.
Perder el tiempo, el unico que me contesto fue Antonio Linares, pero, como
siempre, a Antonio le gusta mucho la teoria , pero no decir como se realiza.
Pues bien, todavia me a sido imposible realizar eso tan simple, lo deje por
imposible, no quise perder mas tiempo.
Claro esta que si supiera mas acerca de como se 'construye' un compilador,
pues seguro que no tendria ningun problema o si las API de Harbour estuviesen
documentadas otro gallo cantaria, pero :
¿ Realmente tiene uno que tener unos conocimientos tan amplios para simple
cuestion absurda como llamar desde C a una funcion estatica ?
¿ No seria factible que mientas uno va aprendiendo mas y mas acerca de como
ocurren las cosas a nivel interno del compilador de Harbour, mas gente a la
larga podra hechar una mano ?
Y no, no vale decir mucho codigo hay para ver , aprende de ahi, mal.
Jose F.Gimenez e Ignacio Ortiz me explico una cosa tan sencilla sobre el
compilador de Harbour a nivel interno, y en C, que hasta un niño de 2 años
lo entenderia. Con todos estos años , el codigo en mis narices , fui incapaz
de comprender que coño estaba haciendo el compilador de Harbour, solamente
basta leer un mensaje de menos de 20 lineas, para comprender las posibilidades
que aquello me brindaba.
En fin, algún dia me gustaria echar una mano a Harbour, pero quizas cuando
la pueda echar, o ya no hara falta o ya se habra muerto....
Bueno, haber si algun dia ' als catalans' nos hacemos una reunion en Barna,
para al menos intercambiar opiniones y conocimientos.
Saludos.