Make con varios subdirectorios

[hmpaquito]

Estimado Antonio,

Feliz Navidad.

Yo no he hablado de librerias en ningun momento. Me resulta lógico que los módulos de una .lib tengan distinto nombre. Pero ese no es el tema del hilo.

El tema es la inseguridad del make cuando se le dicen distintos directorios, además que el .mak no indica con exactitud donde se encuentra un .prg... Habría que hacer una búsqueda por todos los dir listados en el .mak cuando se quiera modificar un modulo.

Un cordial saludo

[Antonio Linares]

Paco,

Feliz navidad,

Tienes razón, no mencionastes las librerías pero como FWH se construye con makes, de ahi que pensase en ellas

[Carles]

Hola,

El tema es la inseguridad del make cuando se le dicen distintos directorios, además que el .mak no indica con exactitud donde se encuentra un .prg... Habría que hacer una búsqueda por todos los dir listados en el .mak cuando se quiera modificar un modulo.

Todo depende de como montes un mak. Si por la manera de gestionar tus proyectos necesitas saber donde esta ubicado tu prg, puedes hacerlo perfectamente. Yo nunca lo he necesitado porque con el nombre del módulo ya se de que directorio cuelga. En el caso de que uses un prg que se usa en varios proyectos (que me parece que es lo que quieres decir) pues se puede indicar la ruta y listos. El mak tiene muchas virtudes pero reconozco que es un coñazo parametrizarlo, pero una vez hecho uno...

Yo no quiero entrar en polémicas , solo he dado un ejemplo básico de un mak q es lo que pedian, simplemente no entiendo porque se ha de sacar bondades del pobre mak y decir que es inseguro... . Piensa que hay muchas variantes y combinaciones que puedes hacer con el make y seguro que alguna se puede adaptar a tu problemática.

[hmpaquito]

Hola,

Yo no quiero entrar en polémicas .

Entre amigos... son casi imposible las polémicas

Hace años que le metí mano al tema de los .mak. Desde entonces ya sólo añado modulos y a reconstruir aplicacion.
Lo que me pareció es que el .mak no permitia, al menos yo no lo vi, indicar como origen el path y el nombre del .prg.
La alternativa era una lista de directorios donde el make.exe buscaría. Lo cual no me gustó nada y es por lo que recurrí al truco de más arriba.

La solución que tu diste en este hilo incluía ese sistema, que yo considero inseguro e impreciso. Piensa en un desarrollador que tiene diez aplicaciones ya montadas y quiere, ahora, hacer un .mak para cada una. ¿ Tendrá que revisar todas las aplicaciones buscando nombres comunes, luego entrando a las aplicaciones cambiando nombres y posibles comentarios ? Por no decir que si un modulo llamado CuentaInventario.prg es casi igual a otro de otra aplicacion ¿ tendrá que cambiarle el nombre porque el make asi lo impone ?

Si al make se le pudiera pasar la ruta de cada .prg entonces todo sería miel sobre hojuelas... sino sigo aplicando mi chapu-solución que me permite tener claro donde están los .prgs que conforman una aplicacion y trabajar sin sorpresas de que por error el make monte inesperadamente un modulo porque coincide con el mismo nombre de uno existente.


Saludos cordiales.

Fdo.: Un forofo del meik