Make con varios subdirectorios

[manuelcalerosolis]

Hola a todos!

Por lo complejo de mi proyecto, me gustaría tener los ficheros fuentes, en varios directorios.

Pero no consigo hacerlo en el .mak, ¿alguno de vosotros ha resuelto esta circunstancia?

Gracias.

[Carles]

Manuel,

myrpt.mak

Code: Select all

.path.PRG = .\source.lib\lib;.\source.lib\fwh;.\source.lib\public;.\source.lib\barcode;.\source.lib\dataset
.path.C   = .\source.lib\fwh;
.path.RC  = .\dll
.path.RES = .\dll
.path.OBJ = .\obj
.path.CH  = .\include
.path.LIB = .\lib

PRG =         \
CONTROL.PRG   \
MYRPT.PRG     \
TMSG.PRG      \
RPTFORM.PRG   \
RPTINSP.PRG   \
TRPTDEF.PRG   \
IT_AREA.PRG   \
TITEM.PRG     \
TITEMSAY.PRG  \
TITEMIMG.PRG  \
TITEMBOX.PRG  \ 
TITEMBAR.PRG  \ 
TITEMLIN.PRG  \ 
TITEMBLC.PRG  \
TITEMLST.PRG  \
TITEMBND.PRG  \
TITEMSEG.PRG  \
TBLOC.PRG     \
MR_TSAY.PRG   \ 
TBOX.PRG      \
TLINE.PRG     \
TCODEBAR.PRG  \
TBAND.PRG     \
TLIST.PRG     \
TREGLA.PRG    \
TSCRWND.PRG   \
LISTPROP.PRG  \
MYXML.PRG     \
DLG_PRJ.PRG   \
DLG_ZOOM.PRG  \
DLG_BLOC.PRG  \
DLG_NPAG.PRG  \
DLG_NBLC.PRG  \
DLG_NLST.PRG  \
DLG_DATA.PRG  \
DLG_DIMG.PRG  \
DLG_DBAR.PRG  \
DLG_PAGE.PRG  \
SUPORT.PRG    \
MISC.PRG      \
PDIRPRG.PRG   \
PDBG.PRG      \
PBROWSE.PRG   \
PMSG.PRG      \
PDBG.PRG      \
PDAT.PRG      \
PTRACE.PRG    \
TENHMETA.PRG  \
MYRPTRUN.PRG  \
TPRNFUNC.PRG  \
TPRNSAY.PRG   \
TPRNIMG.PRG   \
TPRNBOX.PRG   \
TPRNLINE.PRG  \
TPRNCBAR.PRG  \
MR_DSET.PRG   \
MR_FIELDS.PRG \
MR_ADO.PRG    \
MR_ALIAS.PRG  \
MR_RS.PRG     \
MR_RSGET.PRG  \
MR_RSRDD.PRG  \
IMAGE.PRG     \
BARLIB.PRG    \
CODE128.PRG   \
CODE3DE9.PRG  \
EAN13.PRG     \
GO_CODE.PRG   \
CODABAR.PRG   \
INT25.PRG     \
BANNER.PRG

C =           \
CTRLDRAW.C    \
DRAWGRID.C

RC =          \
MYRPT.RC

BAT = Z.BAT

PROJECT    : MyRpt.lib MyRpt.dll

MyRpt.lib  : $(PRG:.PRG=.OBJ) $(C:.C=.OBJ) $(BAT:.BAT=.FIN)
MyRpt.dll  : $(RC:.RC=.RES)


.PRG.OBJ:
   cls
   harbour $< /N /W /w /es2 /Oobj\ > comp.log
   bcc32 -c -tWM -oobj\$& obj\$&.c
   TLib .\lib\MyRpt.lib -+$@
   @echo $< >> log.txt

.C.OBJ:
   bcc32 -c -O2 -D__HARBOUR__ -oobj\$& .\source.lib\fwh\$&.c
   TLib .\lib\MyRpt.lib -+$@
   @echo $< >> log.txt

.RC.RES:
   bcc32 -c -o.\dll\screen32.obj .\dll\screen32.hc
   brc32 -r $<
   ilink32 /Tpd c0d32.obj .\dll\screen32.obj, $*.dll,,cw32.lib import32.lib,, $*.res
   del .\dll\*.il*
   del .\dll\*.map
   del .\dll\*.res
   del .\dll\*.tds
   del .\dll\*.bak


.BAT.FIN:
   @echo Netejant fitxers...
   del .\source.lib\fwh\*.bak        >> log.txt
   del .\source.lib\lib\*.bak        >> log.txt
   del .\source.lib\public\*.bak     >> log.txt
   type log.txt
 

[manuelcalerosolis]

Creo q no me he explicado bien.

Quiero q mis .prg esten en varios directorios distintos.

Source\main\mani.prg
.
.
.
Source\mail\tmailgenerator.prg
.
.
.
Source\print\tprintergeneratos.prg

y todo se refunda en el mismo exe.

Saludos

[cnavarro]

Manuel
Creo que lo que Carles quiere decirte es eso precisamente con la linea:

Code: Select all

.path.PRG = .\source.lib\lib;.\source.lib\fwh;.\source.lib\public;.\source.lib\barcode;.\source.lib\dataset
 

Con los distintos paths en los que pueden estar los siguientes .PRGs de la lista

[manuelcalerosolis]

Am! voy a intentar implementarlo.

Gracias.

[manuelcalerosolis]

Perfecto!

Muchas gracias.

[hmpaquito]

Esa solución tiene el "defectillo" de no saber, leyendo el .mak, en qué directorio se haya cada .prg... por no decir que qué pasa cuando en las rutas hay dos .prgs con el mismo nombre y por supuesto se quiere coger uno de los dos... y qué decir si un dia se nos ocurre crear un .prg en uno de esos directorios con uno de los nombres de .prg que ya se usa...

Resumiendo... a mi ese sistema me crea bastante inseguridad... pero supongo que es cuestión de gustos.

La solución que yo implementé vara evitar todo eso es tan ACME que ni me atrevo a ponerla.

[cnavarro]

Me encantan las ACME-herramientas
Animate y ponlo, no?

[hmpaquito]

Ahí va la animalada:

Lo normal es invocar el .mak desde un .bat ¿ de acuerdo ? Sigo
Pues hacemos lo siguiente:
- Creamos una carpeta en .\ImportCode
- Luego creamos un ImportCode.bat y en el ponemos la ristra de copys
COPY \xxx\yyy\algo.prg ImportCode
...................
- En el .mak hacemos referencia al directorio de importaciones (solo uno !) ImportCode.
- En el .bat que invoca el .mak le hacemos, al principio, una invocacion con CALL ImportCode.bat

Y como diria el de las galletas Chiquilín: "a mi me funciona"

De esa manera viendo el ImportCode.bat sé de donde viene cada .prg.

Saludos

[cnavarro]

Lo ves?
Pues esta HAZTE-herramientas no me parece nada mal para tenerlo claro

[Carles]

Hola,

La inseguridad te la presentara el usar el mismo nombre de prg, que ya de por si es una mala practica. El fichero .mak creas unas dependencias y si necesitas especificar unas estructuras tambien puedes hacerlo si asi te gusta mas. Cuando haces un proyecto grande en el que intervienen numeros modulos tienes q saber "higienizarlo", esto empieza con una buena estructuracion del codigo, una buena estructuracion de ficheros en sus directorios y un buen mak que puedes crearlo de varias maneras. Si necesitas estructurar el mak pues es facil, no hace falta tantos bats, copys,...

El unico "problemilla" del mak es conocer sus bondades, pero te aseguro que si lo logras "profesionalizas" un poco mas tu proyecto.

Es como poner todos tus prgs en uno solo, buffff. Divide y venceras.

Es solo mi humilde opinion y solo he querido mostrar un ejemplo que han pedido.

[cnavarro]

Carles
++++++++1

[hmpaquito]

++++++++1

Cristóbal,

¿ De veras piensas que tener varios módulos .prg con el mismo nombre en distintos directorios es una mala práctica ? Si el mismo módulo, ligeramente cambiado, lo tienes en dos proyectos ¿ Le vas a cambiar el nombre ? Si en OOP utilizamos el polimorfismo... ¿ Vamos a tener nombres distintos para módulos que hacen casi lo mismo porque el make no gestiona bien el tema de los directorios ?

Si uno tiene varios proyectos es habitual tener muchos .prgs con el mismo nombre y no sólo no es una mala práctica, sino que es bueno que sea así.

Saludos cordiales.

[cnavarro]

Feliz Navidad
Hasta donde llegan mis conocimientos, o mejor dicho, mi forma de entender el polimorfismo, se aplica a nivel de function, method, etc. pero nunca he extendido ese concepto hasta el propio contenedor de código (PRG) aunque puedo entenderlo si el PRG se llama como la única function que contiene dicho .PRG
Como en otras cuestiones, "para gustos los colores" y nuestra experiencia y sobre todo necesidades nos hace desarrollar de una forma o de otra
Yo por mi parte siempre he evitado tener .PRGs con el mismo nombre y con funcionalidades distintas, precisamente porque el tiempo y la memoria me han hecho malas pasadas (la edad también influye ).
Un dia te pones a "limpiar" tu almacen de aplicaciones y, o bien tienes una memoria fantástica, o puedes llegar a tener un pequeño problema, sin contar con las veces que he querido empezar un nuevo proyecto reutilizando codigo de aplicaciones anteriores (¿qué PRG contiene el código que necesito?), hecho éste que se agrava si en el nuevo proyecto quiero utilizar código de dos o más anteriores proyectos como es práctica habitual, no?
Pero tal y como te he comentado: esta es mi experiencia que como otras cosas me encanta compartir, pero, como en tantos otros aspectos que podríamos comentar, nunca he pretendido que sea una norma para nadie ni creo que sea ni mejor ni peor. Lo bueno del mundillo en el que nos movemos es que incluso cuando comentamos cualquier tema hemos de razonarlo y eso nos sirve para aprender de las experiencias de los demás ya que muchas veces no son solo temas técnicos los que nos decantan a tomar determinadas decisiones sino muchas otras veces elegimos por razones puramente prácticas (somos humanos aunque continuamente estemos interactuando con máquinas ).

[Antonio Linares]

Paco,

No estoy seguro si se pueden meter módulos con el mismo nombre y distintos paths en una librería.

De poderse entonces si tendría sentido lo que dices