pardon, je viens de m'apercevoir que j'ai écrit une énorme bêtise !
il y a aussi une bibliothèque, mais qui n'est pas signalée comme telle,
donc actuellement l'énorme avantage de tout laisser "en plan" après la
compilation et de ne rien installer, c'est que les utilisateurs peuvent
utiliser les fichiers objets créés Í la compilation, ça ne pose pas de pb
(pas sur que si on les déplaçait ça irais aussi bien)
... donc avant de passer Í l'étape de l'installation, il faut que je
régularise ça !
(il y a aussi la curiosité du fait que ça supporte plusieurs interfaces
graphiques au choix,
je ne sais pas si c'est possible ni souhaitable d'en installer plusieurs
"pairs" en parallèle,
mais c'est pas mon 1er pb parce que je vais commencer avec 1 Í la fois)
je tacherai d'utiliser GPRinstall (puisqu'il a été fait pour simplifier
la vie des gens, autant s'en servir)
en fait je crois que j'ai compris de travers ce que t'as écrit :
je pensais que tu parlais du Makefile et que les fichiers de données
désignaient ceux générés par la compilation
alors qu'en fait (si j'ai bien compris cette fois ci),
t'avais déjÍ commencé Í répondre Í la question écrite plus bas
(les fichiers de données désignant les images) :
par contre, il reste une question (qui était un peu plus haut) non
répondue, puisque je croyais que t'y répondais mais c'était pas ça :
tu parlais de "compiler dans un répertoire séparé", et je demandais
comment le Makefile devait être fait pour ça :
pardon, je viens de m'apercevoir que j'ai écrit une énorme bêtise !
il y a aussi une bibliothèque, mais qui n'est pas signalée comme telle,
donc actuellement l'énorme avantage de tout laisser "en plan" après la
compilation et de ne rien installer, c'est que les utilisateurs peuvent
utiliser les fichiers objets créés Í la compilation, ça ne pose pas de pb
(pas sur que si on les déplaçait ça irais aussi bien)
... donc avant de passer Í l'étape de l'installation, il faut que je
régularise ça !
(il y a aussi la curiosité du fait que ça supporte plusieurs interfaces
graphiques au choix,
je ne sais pas si c'est possible ni souhaitable d'en installer plusieurs
"pairs" en parallèle,
mais c'est pas mon 1er pb parce que je vais commencer avec 1 Í la fois)
je tacherai d'utiliser GPRinstall (puisqu'il a été fait pour simplifier
la vie des gens, autant s'en servir)
en fait je crois que j'ai compris de travers ce que t'as écrit :
je pensais que tu parlais du Makefile et que les fichiers de données
désignaient ceux générés par la compilation
alors qu'en fait (si j'ai bien compris cette fois ci),
t'avais déjÍ commencé Í répondre Í la question écrite plus bas
(les fichiers de données désignant les images) :
par contre, il reste une question (qui était un peu plus haut) non
répondue, puisque je croyais que t'y répondais mais c'était pas ça :
tu parlais de "compiler dans un répertoire séparé", et je demandais
comment le Makefile devait être fait pour ça :
pardon, je viens de m'apercevoir que j'ai écrit une énorme bêtise !
il y a aussi une bibliothèque, mais qui n'est pas signalée comme telle,
donc actuellement l'énorme avantage de tout laisser "en plan" après la
compilation et de ne rien installer, c'est que les utilisateurs peuvent
utiliser les fichiers objets créés Í la compilation, ça ne pose pas de pb
(pas sur que si on les déplaçait ça irais aussi bien)
... donc avant de passer Í l'étape de l'installation, il faut que je
régularise ça !
(il y a aussi la curiosité du fait que ça supporte plusieurs interfaces
graphiques au choix,
je ne sais pas si c'est possible ni souhaitable d'en installer plusieurs
"pairs" en parallèle,
mais c'est pas mon 1er pb parce que je vais commencer avec 1 Í la fois)
je tacherai d'utiliser GPRinstall (puisqu'il a été fait pour simplifier
la vie des gens, autant s'en servir)
en fait je crois que j'ai compris de travers ce que t'as écrit :
je pensais que tu parlais du Makefile et que les fichiers de données
désignaient ceux générés par la compilation
alors qu'en fait (si j'ai bien compris cette fois ci),
t'avais déjÍ commencé Í répondre Í la question écrite plus bas
(les fichiers de données désignant les images) :
par contre, il reste une question (qui était un peu plus haut) non
répondue, puisque je croyais que t'y répondais mais c'était pas ça :
tu parlais de "compiler dans un répertoire séparé", et je demandais
comment le Makefile devait être fait pour ça :
Thomas , dans le message
, a écrit :<http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/Makefi
le-include.mk?view=markup>
Avoir une fois la liste compète des fichiers Í compiler écrite explicitement
est une bonne idée.
2
je me demande si mon Makefile est suffisamment bien fait pour être
agréable Í ceux qui manipulent des Makefile toute l'année
Je ne vois pas les règles pour installer, donc je ne vois pas si elles
respectent la convention DESTDIR.
Il ne semble pas que ça permette de compiler dans un répertoire séparé avec
le répertoire de sources en pure lecture seule. C'est un problème.
est ce qu'on peut choisir des noms qui vont mieux, ou est ce qu'il vaut
mieux laisser ça comme ça parce que tout le monde "dans le milieu" en a
l'habitude ?
Ton «Â clobber » ressemble Í «Â distclean ».Í ce moment lÍ , on pourrais se retrouver Í aller dans le dossier des
exemples, en fabriquer un, ensuite on retourne dans le principal, et si
on nettoie, l'exemple se retrouve nettoyé aussi !
ça peut surprendre, non ?
En général, c'est ce qu'on attend : make clean efface, même les cibles
optionnelles.
Thomas , dans le message
<fantome.forums.tDeContes-D49C43.01430005042021@news.free.fr>, a écrit :
> <http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/Makefi
> le-include.mk?view=markup>
Avoir une fois la liste compète des fichiers Í compiler écrite explicitement
est une bonne idée.
> 2
> je me demande si mon Makefile est suffisamment bien fait pour être
> agréable Í ceux qui manipulent des Makefile toute l'année
Je ne vois pas les règles pour installer, donc je ne vois pas si elles
respectent la convention DESTDIR.
Il ne semble pas que ça permette de compiler dans un répertoire séparé avec
le répertoire de sources en pure lecture seule. C'est un problème.
> est ce qu'on peut choisir des noms qui vont mieux, ou est ce qu'il vaut
> mieux laisser ça comme ça parce que tout le monde "dans le milieu" en a
> l'habitude ?
Ton «Â clobber » ressemble Í «Â distclean ».
> Í ce moment lÍ , on pourrais se retrouver Í aller dans le dossier des
> exemples, en fabriquer un, ensuite on retourne dans le principal, et si
> on nettoie, l'exemple se retrouve nettoyé aussi !
> ça peut surprendre, non ?
En général, c'est ce qu'on attend : make clean efface, même les cibles
optionnelles.
Thomas , dans le message
, a écrit :<http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/Makefi
le-include.mk?view=markup>
Avoir une fois la liste compète des fichiers Í compiler écrite explicitement
est une bonne idée.
2
je me demande si mon Makefile est suffisamment bien fait pour être
agréable Í ceux qui manipulent des Makefile toute l'année
Je ne vois pas les règles pour installer, donc je ne vois pas si elles
respectent la convention DESTDIR.
Il ne semble pas que ça permette de compiler dans un répertoire séparé avec
le répertoire de sources en pure lecture seule. C'est un problème.
est ce qu'on peut choisir des noms qui vont mieux, ou est ce qu'il vaut
mieux laisser ça comme ça parce que tout le monde "dans le milieu" en a
l'habitude ?
Ton «Â clobber » ressemble Í «Â distclean ».Í ce moment lÍ , on pourrais se retrouver Í aller dans le dossier des
exemples, en fabriquer un, ensuite on retourne dans le principal, et si
on nettoie, l'exemple se retrouve nettoyé aussi !
ça peut surprendre, non ?
En général, c'est ce qu'on attend : make clean efface, même les cibles
optionnelles.
Thomas , dans le message
, a écrit :pardon, je viens de m'apercevoir que j'ai écrit une énorme bêtise !
il y a aussi une bibliothèque, mais qui n'est pas signalée comme telle,
donc actuellement l'énorme avantage de tout laisser "en plan" après la
compilation et de ne rien installer, c'est que les utilisateurs peuvent
utiliser les fichiers objets créés Í la compilation, ça ne pose pas de pb
(pas sur que si on les déplaçait ça irais aussi bien)
... donc avant de passer Í l'étape de l'installation, il faut que je
régularise ça !
(il y a aussi la curiosité du fait que ça supporte plusieurs interfaces
graphiques au choix,
je ne sais pas si c'est possible ni souhaitable d'en installer plusieurs
"pairs" en parallèle,
mais c'est pas mon 1er pb parce que je vais commencer avec 1 Í la fois)
Je n'ai absolument rien compris Í tout ça.
je tacherai d'utiliser GPRinstall (puisqu'il a été fait pour simplifier
la vie des gens, autant s'en servir)
Ce pour quoi un programme a été fait n'est pas forcément la même chose que
ce qu'il réalise en réalité. Je ne connais pas GPRinstall, et même si son
but est de simplifier la vie des gens, je devine que son effet est d'être
Yet Another F***ing Non-Standard Build System.
tu parlais de "compiler dans un répertoire séparé", et je demandais
comment le Makefile devait être fait pour ça :
La manière standard est d'avoir in script configure qui enregistre, quand il
est invoqué comme /chemin/vers/les/sources/configure, que les sources sont
dans /chemin/vers/les/sources/.
Une manière un peu moins standard est d'attendre des utilisateurs qu'ils
compilent avec make -f /chemin/vers/les/sources/Makefile, et dans ce cas le
répertoire de sources sera $(dir $(MAKEFILE_LIST)).
Thomas , dans le message
<fantome.forums.tDeContes-015EE1.16573110042021@news.free.fr>, a écrit :
> pardon, je viens de m'apercevoir que j'ai écrit une énorme bêtise !
>
> il y a aussi une bibliothèque, mais qui n'est pas signalée comme telle,
> donc actuellement l'énorme avantage de tout laisser "en plan" après la
> compilation et de ne rien installer, c'est que les utilisateurs peuvent
> utiliser les fichiers objets créés Í la compilation, ça ne pose pas de pb
> (pas sur que si on les déplaçait ça irais aussi bien)
>
> ... donc avant de passer Í l'étape de l'installation, il faut que je
> régularise ça !
>
> (il y a aussi la curiosité du fait que ça supporte plusieurs interfaces
> graphiques au choix,
> je ne sais pas si c'est possible ni souhaitable d'en installer plusieurs
> "pairs" en parallèle,
> mais c'est pas mon 1er pb parce que je vais commencer avec 1 Í la fois)
Je n'ai absolument rien compris Í tout ça.
> je tacherai d'utiliser GPRinstall (puisqu'il a été fait pour simplifier
> la vie des gens, autant s'en servir)
Ce pour quoi un programme a été fait n'est pas forcément la même chose que
ce qu'il réalise en réalité. Je ne connais pas GPRinstall, et même si son
but est de simplifier la vie des gens, je devine que son effet est d'être
Yet Another F***ing Non-Standard Build System.
>
> tu parlais de "compiler dans un répertoire séparé", et je demandais
> comment le Makefile devait être fait pour ça :
La manière standard est d'avoir in script configure qui enregistre, quand il
est invoqué comme /chemin/vers/les/sources/configure, que les sources sont
dans /chemin/vers/les/sources/.
Une manière un peu moins standard est d'attendre des utilisateurs qu'ils
compilent avec make -f /chemin/vers/les/sources/Makefile, et dans ce cas le
répertoire de sources sera $(dir $(MAKEFILE_LIST)).
Thomas , dans le message
, a écrit :pardon, je viens de m'apercevoir que j'ai écrit une énorme bêtise !
il y a aussi une bibliothèque, mais qui n'est pas signalée comme telle,
donc actuellement l'énorme avantage de tout laisser "en plan" après la
compilation et de ne rien installer, c'est que les utilisateurs peuvent
utiliser les fichiers objets créés Í la compilation, ça ne pose pas de pb
(pas sur que si on les déplaçait ça irais aussi bien)
... donc avant de passer Í l'étape de l'installation, il faut que je
régularise ça !
(il y a aussi la curiosité du fait que ça supporte plusieurs interfaces
graphiques au choix,
je ne sais pas si c'est possible ni souhaitable d'en installer plusieurs
"pairs" en parallèle,
mais c'est pas mon 1er pb parce que je vais commencer avec 1 Í la fois)
Je n'ai absolument rien compris Í tout ça.
je tacherai d'utiliser GPRinstall (puisqu'il a été fait pour simplifier
la vie des gens, autant s'en servir)
Ce pour quoi un programme a été fait n'est pas forcément la même chose que
ce qu'il réalise en réalité. Je ne connais pas GPRinstall, et même si son
but est de simplifier la vie des gens, je devine que son effet est d'être
Yet Another F***ing Non-Standard Build System.
tu parlais de "compiler dans un répertoire séparé", et je demandais
comment le Makefile devait être fait pour ça :
La manière standard est d'avoir in script configure qui enregistre, quand il
est invoqué comme /chemin/vers/les/sources/configure, que les sources sont
dans /chemin/vers/les/sources/.
Une manière un peu moins standard est d'attendre des utilisateurs qu'ils
compilent avec make -f /chemin/vers/les/sources/Makefile, et dans ce cas le
répertoire de sources sera $(dir $(MAKEFILE_LIST)).
Thomas , dans le message
, a écrit :mais si ça te dérange pas trop, j'aimerais bcp que tu me montres comment
on peut parcourir les sous dossiers avec un Makefile stp,
parce que lÍ je sèche, et j'aimerais bien savoir le faire si on peut :-)
Attends, tu changes les données du problème, lÍ . Il n'a jamais été question
dans tes questions de parcourir des sous-répertoire
(on peut éviter les
appellations microsoftiennes ?),
il a toujours été question de parcourir des
listes.
En fait, pour commencer, il faudrait poser le problème un peu plus
clairement et précisément que par la donnée d'une ébauche de solution un peu
bancale.
(veux tu dire avec "prefix" en plus de "DESTDIR" ?
je me réfère Í
https://www.gnu.org/software/make/manual/html_node/Directory-Variables.ht
ml ( https://urlpetite.fr/0mw ), penses tu qu'il faut éviter ?)
Oui, prefix est une convention très largement respectée, et absolument
indispensable pour n'importe quel programme non trivial.mais il faut bien qu'il y ait un emplacement prévu par défaut, au cas o͹
l'utilisateur n'en donne pas
/usr/local
mais ça me parait prioritaire d'avoir un logiciel qui fait ce que je
veux, plutÍ´t qu'un logiciel buggé bien installé ;-)
Il vaut mieux partir propre dès le début.
est ce que ça vaut pour l'emplacement de compilation par défaut aussi,
en vue de ne pas en avoir besoin Í l'emplacement d'installation ?
(Í la 1ere lecture je croyais que c'était seulement pour l'emplacement
de compilation personnalisé)
Euh... Si ton programme a besoin d'être Í un endroit particulier pour être
compilé, ne compte sur personne pour y contribuer.
par contre, si la doc de gnu ne te convient pas comme référence, y en a
t il une autre ?
Pas Í ma connaissance.
Thomas , dans le message
<fantome.forums.tDeContes-EF3728.17032210042021@news.free.fr>, a écrit :
> mais si ça te dérange pas trop, j'aimerais bcp que tu me montres comment
> on peut parcourir les sous dossiers avec un Makefile stp,
> parce que lÍ je sèche, et j'aimerais bien savoir le faire si on peut :-)
Attends, tu changes les données du problème, lÍ . Il n'a jamais été question
dans tes questions de parcourir des sous-répertoire
(on peut éviter les
appellations microsoftiennes ?),
il a toujours été question de parcourir des
listes.
En fait, pour commencer, il faudrait poser le problème un peu plus
clairement et précisément que par la donnée d'une ébauche de solution un peu
bancale.
>
> (veux tu dire avec "prefix" en plus de "DESTDIR" ?
> je me réfère Í
> https://www.gnu.org/software/make/manual/html_node/Directory-Variables.ht
> ml ( https://urlpetite.fr/0mw ), penses tu qu'il faut éviter ?)
Oui, prefix est une convention très largement respectée, et absolument
indispensable pour n'importe quel programme non trivial.
> mais il faut bien qu'il y ait un emplacement prévu par défaut, au cas o͹
> l'utilisateur n'en donne pas
/usr/local
> mais ça me parait prioritaire d'avoir un logiciel qui fait ce que je
> veux, plutÍ´t qu'un logiciel buggé bien installé ;-)
Il vaut mieux partir propre dès le début.
> est ce que ça vaut pour l'emplacement de compilation par défaut aussi,
> en vue de ne pas en avoir besoin Í l'emplacement d'installation ?
> (Í la 1ere lecture je croyais que c'était seulement pour l'emplacement
> de compilation personnalisé)
Euh... Si ton programme a besoin d'être Í un endroit particulier pour être
compilé, ne compte sur personne pour y contribuer.
> par contre, si la doc de gnu ne te convient pas comme référence, y en a
> t il une autre ?
Pas Í ma connaissance.
Thomas , dans le message
, a écrit :mais si ça te dérange pas trop, j'aimerais bcp que tu me montres comment
on peut parcourir les sous dossiers avec un Makefile stp,
parce que lÍ je sèche, et j'aimerais bien savoir le faire si on peut :-)
Attends, tu changes les données du problème, lÍ . Il n'a jamais été question
dans tes questions de parcourir des sous-répertoire
(on peut éviter les
appellations microsoftiennes ?),
il a toujours été question de parcourir des
listes.
En fait, pour commencer, il faudrait poser le problème un peu plus
clairement et précisément que par la donnée d'une ébauche de solution un peu
bancale.
(veux tu dire avec "prefix" en plus de "DESTDIR" ?
je me réfère Í
https://www.gnu.org/software/make/manual/html_node/Directory-Variables.ht
ml ( https://urlpetite.fr/0mw ), penses tu qu'il faut éviter ?)
Oui, prefix est une convention très largement respectée, et absolument
indispensable pour n'importe quel programme non trivial.mais il faut bien qu'il y ait un emplacement prévu par défaut, au cas o͹
l'utilisateur n'en donne pas
/usr/local
mais ça me parait prioritaire d'avoir un logiciel qui fait ce que je
veux, plutÍ´t qu'un logiciel buggé bien installé ;-)
Il vaut mieux partir propre dès le début.
est ce que ça vaut pour l'emplacement de compilation par défaut aussi,
en vue de ne pas en avoir besoin Í l'emplacement d'installation ?
(Í la 1ere lecture je croyais que c'était seulement pour l'emplacement
de compilation personnalisé)
Euh... Si ton programme a besoin d'être Í un endroit particulier pour être
compilé, ne compte sur personne pour y contribuer.
par contre, si la doc de gnu ne te convient pas comme référence, y en a
t il une autre ?
Pas Í ma connaissance.
voilÍ la nouvelle version :
http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/Makefile-include.mk?revision"6&view=markup ( https://urlpetite.fr/vgv )
en attendant, s'il te reste un peu de patience, je veux bien que tu me
dises s'il y a d'autres choses qui ne te plaisent pas dans la nouvelle
version :-)
voilÍ la nouvelle version :
http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/Makefile-include.mk?revision"6&view=markup ( https://urlpetite.fr/vgv )
en attendant, s'il te reste un peu de patience, je veux bien que tu me
dises s'il y a d'autres choses qui ne te plaisent pas dans la nouvelle
version :-)
voilÍ la nouvelle version :
http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/Makefile-include.mk?revision"6&view=markup ( https://urlpetite.fr/vgv )
en attendant, s'il te reste un peu de patience, je veux bien que tu me
dises s'il y a d'autres choses qui ne te plaisent pas dans la nouvelle
version :-)
In article
,
Thomas wrote:voilÍ la nouvelle version :
2
l 39 :
un avis sur ASCII_SP ?
4
l 79-165 :
comme le traitement de GPR_PROJECT_PATH est très long et pas très
intéressant, je pense diviser ce Makefile en 2 :
bonne idée ?
In article
<fantome.forums.tDeContes-E82A8C.00153604052021@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> voilÍ la nouvelle version :
2
l 39 :
un avis sur ASCII_SP ?
4
l 79-165 :
comme le traitement de GPR_PROJECT_PATH est très long et pas très
intéressant, je pense diviser ce Makefile en 2 :
bonne idée ?
In article
,
Thomas wrote:voilÍ la nouvelle version :
2
l 39 :
un avis sur ASCII_SP ?
4
l 79-165 :
comme le traitement de GPR_PROJECT_PATH est très long et pas très
intéressant, je pense diviser ce Makefile en 2 :
bonne idée ?
In article
,
Thomas wrote:voilÍ la nouvelle version :
1
y a t il trop de override Í ton gout ?
je n'ai pas réussi Í résister, malgré la recommandation :
ma formation est de programmer les choses les plus fiables possibles,
pour avoir le moins possible Í y revenir
2
un avis sur ASCII_SP ?
3
cette fois ci je pense que ça y est, mon test est insubmersible !! haha
:-)
... sauf que je l'ai pensé une 10aine de fois avant de m'apercevoir de
nouvelles failles ...
est t il possible de faire un peu moins "hackesque", si possible sans
trop rogner sur la fiabilité ?
In article
<fantome.forums.tDeContes-E82A8C.00153604052021@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> voilÍ la nouvelle version :
1
y a t il trop de override Í ton gout ?
je n'ai pas réussi Í résister, malgré la recommandation :
ma formation est de programmer les choses les plus fiables possibles,
pour avoir le moins possible Í y revenir
2
un avis sur ASCII_SP ?
3
cette fois ci je pense que ça y est, mon test est insubmersible !! haha
:-)
... sauf que je l'ai pensé une 10aine de fois avant de m'apercevoir de
nouvelles failles ...
est t il possible de faire un peu moins "hackesque", si possible sans
trop rogner sur la fiabilité ?
In article
,
Thomas wrote:voilÍ la nouvelle version :
1
y a t il trop de override Í ton gout ?
je n'ai pas réussi Í résister, malgré la recommandation :
ma formation est de programmer les choses les plus fiables possibles,
pour avoir le moins possible Í y revenir
2
un avis sur ASCII_SP ?
3
cette fois ci je pense que ça y est, mon test est insubmersible !! haha
:-)
... sauf que je l'ai pensé une 10aine de fois avant de m'apercevoir de
nouvelles failles ...
est t il possible de faire un peu moins "hackesque", si possible sans
trop rogner sur la fiabilité ?
