Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Unix Makefile

Makefile

17 réponses
Avatar
Thomas
bonjour :-)

y a t il un meilleur forum pour parler des Makefiles ?


est il bien vu de mettre un lien sur du code que j'ai écrit, comme ça ?

<http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/Makefi
le-include.mk?view=markup>


1
j'aimerais savoir si je peux faire mieux, pour la définition de
ADA_FILES :
est il possible de factoriser les répétitions sous forme de boucle ?
idéalement, il faudrait que ça s'arrête quand ADA_DIRS est vide.


2
je me demande si mon Makefile est suffisamment bien fait pour être
agréable Í  ceux qui manipulent des Makefile toute l'année

par exemple, avec les règles clean et clobber, c'est pas très pratique
parce que l'auto-complétion s'arrête Í  'cl' et on doit taper une lettre
de plus pour continuer :
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 ?

n'hésitez pas Í  me faire vos commentaires, si y a des choses pour
lesquelles je n'ai pas l'idée de vous poser la question :-)


je pense que je vais ajouter la construction des exemples
(dans branches/gtkada-2.24/examples,
décrits dans branches/gtkada-2.24/INSTALL partie 5)

je crois savoir comment faire,
je vais faire une règle "examples" et je vais l'ajouter Í  "all",

mais ensuite je me demande quelle politique adopter pour le nettoyage,
pour que ça soit ergonomique :

les exemples sont censés être autonomes et simples, puisque c'est leur
rÍ´le

- si je ne touche pas Í  clean et clobber,
on va avoir all qui va construire les exemples, et clean et clobber ne
vont pas les nettoyer.
- si je modifie clean et clobber pour que ça nettoie ce que "make all"
fait,
Í  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 ?
surtout que "make" ne les fabrique pas, puisque il est dirigé sur "build"

voilÍ , je crois que je suis obligé de choisir une de ces 2 alternatives,
je ne crois pas qu'il y en ait d'autres.
qu'en pensez vous ?

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Olivier Miakinen
Bonjour,
Vu l'heure je ne vais répondre qu'aux premières questions car je ne prends pas
le temps de lire le Makefile lui-même.
Le 05/04/2021 01:43, Thomas a écrit :
y a t il un meilleur forum pour parler des Makefiles ?

Je ne le pense pas. J'aurais moi aussi choisi fr.comp.os.unix/
est il bien vu de mettre un lien sur du code que j'ai écrit, comme ça ?
<http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/Makefi
le-include.mk?view=markup>

Oui, sauf que tu utilises un logiciel qui coupe les url trop longs, et que
la plupart des autres logiciels ne savent pas les reconstituer.
Du coup, Í  moins que tu ne passes sur MacCafé qui n'a pas ce problème
(il sait reconstituer les lignes coupées, mais il ne coupe pas de lui-même
les liens trop longs), tu devrais mettre un lien raccourci *en plus* du
lien long (je dis bien « en plus » et pas « Í  la place »).
P.-S. : lien non coupé pour ceux que cela pourrait aider...
<http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/Makefile-include.mk?view=markup>
Cordialement,
--
Olivier Miakinen
Avatar
Nicolas George
Thomas , dans le message
, a écrit :
<http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/Makefi
le-include.mk?view=markup>

Qu'est-ce que c'est moche, savannah.
1
j'aimerais savoir si je peux faire mieux, pour la définition de
ADA_FILES :
est il possible de factoriser les répétitions sous forme de boucle ?
idéalement, il faudrait que ça s'arrête quand ADA_DIRS est vide.

Mets la définition d'ADA_FILES après avoir complètement rempli ADA_DIRS.
Mais attention, utiliser wildcard pour définir une liste de fichiers Í 
compiler est une très mauvaise idée. À un moment o͹ Í  un autre, il y aura
d'autres fichiers dans le répertoire : des fichiers pour une partie
différente du programme, des fichiers pour des tests rapides pendant le
développement, etc.
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.
par exemple, avec les règles clean et clobber, c'est pas très pratique
parce que l'auto-complétion s'arrête Í  'cl' et on doit taper une lettre
de plus pour continuer :

La complétion de cibles make marche très mal de toutes façons.
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.
Avatar
Thomas
In article <606adb20$0$16194$,
Nicolas George <nicolas$ wrote:
Thomas , dans le message
, a écrit :
<http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/Makefi
le-include.mk?view=markup>

Qu'est-ce que c'est moche, savannah.

je pensais plutÍ´t que c'était svn qui faisait cette interface pas
super-ergonomique,
mais de toutes façons c'est pas moi qui ai choisi l'hebergeur
en as tu un autre Í  suggérer, si j'avais Í  en changer ?
1
j'aimerais savoir si je peux faire mieux, pour la définition de
ADA_FILES :
est il possible de factoriser les répétitions sous forme de boucle ?
idéalement, il faudrait que ça s'arrête quand ADA_DIRS est vide.

Mets la définition d'ADA_FILES après avoir complètement rempli ADA_DIRS.

il faudrait que je mette le '+=' sur ADA_DIRS plutÍ´t que sur ADA_FILES ?
mais ça ne change pas qu'il faut que je sache quand je m'arrête,
et ça me semble même encore plus compliqué, si on veut faire un test
plutÍ´t qu'un nb de tours prédéfini.
Mais attention, utiliser wildcard pour définir une liste de fichiers Í 
compiler est une très mauvaise idée. À un moment o͹ Í  un autre, il y aura
d'autres fichiers dans le répertoire : des fichiers pour une partie
différente du programme, des fichiers pour des tests rapides pendant le
développement, etc.

en général, pour ça, je m'organise en sous-répertoires, ce qui me donne
la possibilité d'en exclure certains,
c'est en qq sorte déjÍ  ce que je fais en démarrant sur
src/peers/$(PEER) (non récursif) + src/tki plutÍ´t que sur src
du coup, s'il y a de nouveaux fichiers dans un répertoire Í  traiter
d'une certaine façon, en principe je souhaite qu'ils soient traités de
la même façon
Avoir une fois la liste compète des fichiers Í  compiler écrite explicitement
est une bonne idée.

je trouve qu'il y en a un bcp trop grand nb pour ça,
ça serais Í  la fois illisible et in-maintenable
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.

la convention DESTDIR elle même me parait accessible,
ce qui me parait plus compliqué c'est l'étape d'avant, cad
l'installation elle même, que tu ne vois pas ;-)
as tu des conseils Í  me donner pour ça ?
idéalement j'aimerais pouvoir tester ce que je fais sans être root
le binaire cherche des images, et je ne sais pas comment gérer ça pour
qu'il les trouve quand il est Í  son emplacement de compilation et aussi
quand il est Í  son emplacement d'installation
actuellement, la conception c'est que :
- on se place dans le répertoire de compilation,
- on exécute le Makefile qui se trouve Í  cet endroit,
- le logiciel est fabriqué Í  cet endroit aussi,
- comme ça il est accessible tout ce suite, on n'a pas besoin de changer
de répertoire pour le trouver !
mauvaise idée ?
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.

qu'appelles tu le répertoire de sources ? la distribution toute entière,
ou seulement src ?
le répertoire de compilation est bin, donc ça devrais marcher sans pb
avec src entièrement en lecture seule.
par contre, pour compiler les exemples, examples ne doit pas être en
lecture seule.
est ce que README et INSTALL sont suffisamment bien écrits pour
expliquer ça ?
(est ce que cette partie de la discussion serait mieux sur
fr.comp.developpement ?)
par exemple, avec les règles clean et clobber, c'est pas très pratique
parce que l'auto-complétion s'arrête Í  'cl' et on doit taper une lettre
de plus pour continuer :

La complétion de cibles make marche très mal de toutes façons.

ah ? qu'est ce qui marche mal d'après toi ?
moi j'ai l'impression que ça marche plutÍ´t bien,
et que mon pb était du a un simple choix des noms qui rendait ça
compliqué : en tapant "c<tab>" le logiciel n'a pas la possibilité de
deviner lequel des 2 on veut
Í  moins que tu trouves qu'il propose trop de choix, parce qu'il propose
la totalité des règles alors que seulement une partie est utile aux
utilisateurs ?
pour ce cas, amha ce qui serais bien c'est d'introduire la notion de
"sous-règle", sur le même principe que les sous-programmes, destinées Í 
factoriser etc, mais pas Í  l'utilisateur final.
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 ».

si je te comprend bien,
https://www.gnu.org/software/make/manual/html_node/Standard-Targets.html
est plus fiable que
https://www.gnu.org/software/make/manual/html_node/Goals.html
dans ce cas, j'ai aussi "test" que je devrais peut-être mieux appeler
"check",
sauf que ce que ça fait ne correspond pas tout Í  fait Í  la définition :
ça compile des bouts de code destinés Í  tester le code source, ça ne
teste pas le résultat de la compilation elle même.
(et en plus ça ne fait que la compilation, je ne vois pas comment
automatiser l'exécution de ces tests.)
As tu un avis lÍ  dessus ?
Í  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.

merci :-)
voilÍ  une réponse sans ambiguité qui permet de savoir exactement o͹
aller :-)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
Nicolas George
Thomas , dans le message
, a écrit :
je pensais plutÍ´t que c'était svn qui faisait cette interface pas
super-ergonomique, mais de toutes façons c'est pas moi qui ai choisi
l'hebergeur
en as tu un autre Í  suggérer, si j'avais Í  en changer ?

Git permet de changer d'hébergement facilement. GitLab est une très bonne
interface, libre.
il faudrait que je mette le '+=' sur ADA_DIRS plutÍ´t que sur ADA_FILES ?

Ou mettre la liste en une seule fois.
mais ça ne change pas qu'il faut que je sache quand je m'arrête,

??? Tu fais une boucle avec foreach, c'est tout.
en général, pour ça, je m'organise en sous-répertoires, ce qui me donne
la possibilité d'en exclure certains,
c'est en qq sorte déjÍ  ce que je fais en démarrant sur
src/peers/$(PEER) (non récursif) + src/tki plutÍ´t que sur src
du coup, s'il y a de nouveaux fichiers dans un répertoire Í  traiter
d'une certaine façon, en principe je souhaite qu'ils soient traités de
la même façon

Si tu organises ton projet en ne considérant que ta propre manière de
travailler, tu risques de ne pas trouver de contributeurs.
je trouve qu'il y en a un bcp trop grand nb pour ça,
ça serais Í  la fois illisible et in-maintenable

Regarde ce que font d'autres projets :
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/Makefile
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gtk/meson.build
la convention DESTDIR elle même me parait accessible,
ce qui me parait plus compliqué c'est l'étape d'avant, cad
l'installation elle même, que tu ne vois pas ;-)

Ce n'est pas l'étape d'avant, DESTDIR intervient pendant l'installation.
as tu des conseils Í  me donner pour ça ?
idéalement j'aimerais pouvoir tester ce que je fais sans être root

C'est précisément l'intérêt de DESTDIR. Je ne lance jamais make install avec
des droits de root, je fais toujours :
make DESTDIR=/tmp/i install
sudo cp -r /tmp/opt/machin /opt/
le binaire cherche des images, et je ne sais pas comment gérer ça pour
qu'il les trouve quand il est Í  son emplacement de compilation et aussi
quand il est Í  son emplacement d'installation
actuellement, la conception c'est que :
- on se place dans le répertoire de compilation,
- on exécute le Makefile qui se trouve Í  cet endroit,
- le logiciel est fabriqué Í  cet endroit aussi,
- comme ça il est accessible tout ce suite, on n'a pas besoin de changer
de répertoire pour le trouver !
mauvaise idée ?

Ce n'est pas durable.
Il faut rendre l'emplacement des fichiers de données configurable Í 
l'exécution, avec une option de ligne de commande ou une variable
d'environnement.
qu'appelles tu le répertoire de sources ? la distribution toute entière,
ou seulement src ?

La distribution tout entière.
ah ? qu'est ce qui marche mal d'après toi ?
moi j'ai l'impression que ça marche plutÍ´t bien,

C'est que tu l'utilises sur des projets triviaux.
Í  moins que tu trouves qu'il propose trop de choix, parce qu'il propose
la totalité des règles alors que seulement une partie est utile aux
utilisateurs ?

Il ne proposera surtout pas les règles qui arrivent de manière non triviale.
si je te comprend bien,
https://www.gnu.org/software/make/manual/html_node/Standard-Targets.html
est plus fiable que
https://www.gnu.org/software/make/manual/html_node/Goals.html

Ce n'est pas GNU qui définit les pratiques, les pratiques se définissent par
elles-mêmes.
Avatar
Thomas
In article <606b63da$0$3710$,
Nicolas George <nicolas$ wrote:
Thomas , dans le message
, a écrit :
je pensais plutÍ´t que c'était svn qui faisait cette interface pas
super-ergonomique, mais de toutes façons c'est pas moi qui ai choisi
l'hebergeur
en as tu un autre Í  suggérer, si j'avais Í  en changer ?

Git permet de changer d'hébergement facilement. GitLab est une très bonne
interface, libre.

je réfléchis Í  cette possibilité, ainsi qu'aux autres VCS décentralisés,
mais je ne souhaite pas non plus faire ce genre de changements sans
l'avis du mainteneur précédent, tant qu'il souhaite garder un oeil sur
le projet
(et je n'ai pas le temps de finaliser ça rapidement, et il me parait
plus important d'avancer sur le contenu d'abord)
est ce que tu connais suffisamment savannah pour savoir qu'avec git
aussi son interface est moche ?
il faudrait que je mette le '+=' sur ADA_DIRS plutÍ´t que sur ADA_FILES ?

Ou mettre la liste en une seule fois.
mais ça ne change pas qu'il faut que je sache quand je m'arrête,

??? Tu fais une boucle avec foreach, c'est tout.

il me semble que t'as lu mon code,
tu as donc vu que je fais déjÍ  un foreach pour traiter chaque élément
d'un répertoire donné ?
mais il me semble qu'on ne peut pas s'en servir pour faire une boucle
récursive pour aller dans les sous dossiers, si ?
en général, pour ça, je m'organise en sous-répertoires, ce qui me donne
la possibilité d'en exclure certains,
c'est en qq sorte déjÍ  ce que je fais en démarrant sur
src/peers/$(PEER) (non récursif) + src/tki plutÍ´t que sur src
du coup, s'il y a de nouveaux fichiers dans un répertoire Í  traiter
d'une certaine façon, en principe je souhaite qu'ils soient traités de
la même façon

Si tu organises ton projet en ne considérant que ta propre manière de
travailler, tu risques de ne pas trouver de contributeurs.
Ce n'est pas GNU qui définit les pratiques, les pratiques se définissent par
elles-mêmes.

si je te comprends bien, je ne suis pas assez influent pour convaincre
les potentiels contributeurs d'adopter ma pratique ?
(en vue d'économiser une liste de noms de fichiers, longue comme les 2
bras, Í  maintenir)
le but de ce fil est précisément de me rapprocher des usages pour être
mieux intégré Í  la communauté,
et je te remercie vivement de tes remarques, y compris celle ci, et
j'espère que tu auras la patience d'insister aussi longtemps que tu le
juges utile ;-)
simplement, l͠, je bute sur un cas o͹ ce que tu me demandes me parait
avoir énormément d'inconvénients immédiats pour moi, en comparaison des
avantages potentiels (visibles de moi) pour les autres
donc au stade o͹ j'en suis, j'espère que c'est moi qui réussirai Í 
convaincre les autres que ma pratique est la bonne :-)
je trouve qu'il y en a un bcp trop grand nb pour ça,
ça serais Í  la fois illisible et in-maintenable

Regarde ce que font d'autres projets :
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/Makefile

je désapprouve.
mais on dirait que ce n'est pas un Makefile autonome, qu'il est fait
seulement pour définir des variables et pour être utilisé dans d'autres
Makefiles ?
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gtk/meson.build

désolé, mon navigateur est trop vieux
la convention DESTDIR elle même me parait accessible,
ce qui me parait plus compliqué c'est l'étape d'avant, cad
l'installation elle même, que tu ne vois pas ;-)

Ce n'est pas l'étape d'avant, DESTDIR intervient pendant l'installation.
as tu des conseils Í  me donner pour ça ?
idéalement j'aimerais pouvoir tester ce que je fais sans être root

C'est précisément l'intérêt de DESTDIR. Je ne lance jamais make install avec
des droits de root, je fais toujours :
make DESTDIR=/tmp/i install
sudo cp -r /tmp/opt/machin /opt/

ok :-)
vu comme ça, effectivement, il n'y a vraiment aucun avantage Í  faire
"install" sans DESTDIR avant !
en observant et réfléchissant, je crois savoir que la destination doit
être /opt/rapid/
pour l'instant c'est encore assez simple, il y a juste un binaire et des
images, pas de bibliothèque ou autre truc plus sophistiqué,
est ce que l'usage recommande de ranger ça d'une certaine manière,
ou est ce que je met ça vraiment comme je veux Í  l'intérieur de mon
répertoire /opt/rapid/ ?
le binaire cherche des images, et je ne sais pas comment gérer ça pour
qu'il les trouve quand il est Í  son emplacement de compilation et aussi
quand il est Í  son emplacement d'installation
actuellement, la conception c'est que :
- on se place dans le répertoire de compilation,
- on exécute le Makefile qui se trouve Í  cet endroit,
- le logiciel est fabriqué Í  cet endroit aussi,
- comme ça il est accessible tout ce suite, on n'a pas besoin de changer
de répertoire pour le trouver !
mauvaise idée ?

Ce n'est pas durable.

"pas durable" dans quel sens, peux tu préciser stp ?
(c'était exactement dans cette configuration quand je l'ai repris, et
j'essaie de l'améliorer progressivement)
Il faut rendre l'emplacement des fichiers de données configurable Í 
l'exécution, avec une option de ligne de commande ou une variable
d'environnement.

ok,
est ce que l'usage recommande une chose plutÍ´t qu'une autre,
ou est ce que je fais vraiment comme je veux du moment que cette
possibilité existe d'une façon ou d'une autre et qu'elle est documentée ?
qu'appelles tu le répertoire de sources ? la distribution toute entière,
ou seulement src ?

La distribution tout entière.

ok, j'approuve le principe :-)
mais je me demande comment je devrais gérer les images dans ce cas lÍ  :
- en faire une copie ͠ l'emplacement o͹ on me demande de compiler ?
- utiliser des astuces pour que le binaire sache retrouver les images Í 
leur emplacement d'origine ?
- on n'a pas besoin que le binaire soit exécutable Í  son emplacement de
compilation, tant qu'il n'est pas installé ? (ça par contre, j'aurais
tendance Í  désapprouver)
ah ? qu'est ce qui marche mal d'après toi ?
moi j'ai l'impression que ça marche plutÍ´t bien,

C'est que tu l'utilises sur des projets triviaux.
Í  moins que tu trouves qu'il propose trop de choix, parce qu'il propose
la totalité des règles alors que seulement une partie est utile aux
utilisateurs ?

Il ne proposera surtout pas les règles qui arrivent de manière non triviale.

ok, je crois deviner,
mais je vais pas me lancer dans cette discussion lÍ  alors qu'Í  la fois
je ne maitrise pas la chose et je n'en ai pas besoin,
je verrai ça plus tard
si je te comprend bien,
https://www.gnu.org/software/make/manual/html_node/Standard-Targets.html
est plus fiable que
https://www.gnu.org/software/make/manual/html_node/Goals.html

Ce n'est pas GNU qui définit les pratiques, les pratiques se définissent par
elles-mêmes.

effectivement, c'est des recommandations pour les programmes gnu, pas
pour tous les usagers de make
a priori, je pensais que gnu avait pu s'inspirer des pratiques
constatées, pour établir tout ça ...
si je te suis bien, ce que tu m'as dit pour "distclean" ne vaut pas pour
"test" ?
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
Nicolas George
Thomas , dans le message
, a écrit :
est ce que tu connais suffisamment savannah pour savoir qu'avec git
aussi son interface est moche ?

Non, mais je connais l'esprit qui préside Í  savannah, tout fait de pureté
idéologique et de dogmatisme.
il me semble que t'as lu mon code,
tu as donc vu que je fais déjÍ  un foreach pour traiter chaque élément
d'un répertoire donné ?
mais il me semble qu'on ne peut pas s'en servir pour faire une boucle
récursive pour aller dans les sous dossiers, si ?

On peut probablement faire une boucle récursive, mais je n'ai pas
l'impression que ce soit nécessaire ici.
On peut faire une boucle dans une boucle, ça c'est très facile.
si je te comprends bien, je ne suis pas assez influent pour convaincre
les potentiels contributeurs d'adopter ma pratique ?
(en vue d'économiser une liste de noms de fichiers, longue comme les 2
bras, Í  maintenir)

??? Si tu ne suis pas les pratiques, les gens vont maugréer et finalement ne
pas utiliser ton projet, tout simplement.
je désapprouve.

Tu fais ce que tu veux, tu as juste tort.
en observant et réfléchissant, je crois savoir que la destination doit
être /opt/rapid/

La destination doit être configurable.
est ce que l'usage recommande de ranger ça d'une certaine manière,
ou est ce que je met ça vraiment comme je veux Í  l'intérieur de mon
répertoire /opt/rapid/ ?

Regarde comment font d'autres logiciels.
"pas durable" dans quel sens, peux tu préciser stp ?

Tu ne seras jamais packagé, par exemple.
ok,
est ce que l'usage recommande une chose plutÍ´t qu'une autre,
ou est ce que je fais vraiment comme je veux du moment que cette
possibilité existe d'une façon ou d'une autre et qu'elle est documentée ?

Le mieux est de proposer les deux, plus éventuellement un mécanisme
spécifique Í  l'interface (base de données xrdb pour les applications X11 par
exemple).
mais je me demande comment je devrais gérer les images dans ce cas lÍ  :
- en faire une copie ͠ l'emplacement o͹ on me demande de compiler ?
- utiliser des astuces pour que le binaire sache retrouver les images Í 
leur emplacement d'origine ?
- on n'a pas besoin que le binaire soit exécutable Í  son emplacement de
compilation, tant qu'il n'est pas installé ? (ça par contre, j'aurais
tendance Í  désapprouver)

Il est parfaitement acceptable que lancer le binaire sans l'installer
demande une option ou une variable d'environnement.
a priori, je pensais que gnu avait pu s'inspirer des pratiques
constatées, pour établir tout ça ...

Un peu. Mais ils essaient aussi d'imposer leurs vues sur la Bonne Manière de
faire les choses.
si je te suis bien, ce que tu m'as dit pour "distclean" ne vaut pas pour
"test" ?

make test est plus rare que make distclean, dans mon estimation, donc moins
uniforme.
Avatar
Thomas
In article <s4dl3t$2aup$,
Olivier Miakinen <om+ wrote:
Bonjour,
Vu l'heure je ne vais répondre qu'aux premières questions car je ne prends
pas
le temps de lire le Makefile lui-même.

si t'as un peu de temps ça m'intéresse d'avoir ton avis :-)
même s'il est identique Í  celui de Nicolas, c'est tjr intéressant de
savoir qu'il y en a 2 qui pensent pas comme soi
(par ex pour ce qui est politique en général c'est les plus nombreux qui
font la décision)
Le 05/04/2021 01:43, Thomas a écrit :
est il bien vu de mettre un lien sur du code que j'ai écrit, comme ça ?
<http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/Makefi
le-include.mk?view=markup>

Oui, sauf que tu utilises un logiciel qui coupe les url trop longs, et que
la plupart des autres logiciels ne savent pas les reconstituer.

ah zut, je pensais que '<>' (que je me farcis Í  la main) était suffisant
(comme je vais passer sous linux je serai obligé de changer de logiciel)
tu devrais mettre un lien raccourci *en plus* du
lien long (je dis bien « en plus » et pas « Í  la place »).

oui parce que les liens raccourcis se périment
peux tu me donner un service que t'apprécies pour ça stp ?
(est ce qu'il y en a chez framasoft ?)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
Thomas
In article
,
Thomas wrote:
pour l'instant c'est encore assez simple, il y a juste un binaire et des
images, pas de bibliothèque ou autre truc plus sophistiqué,

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)
est ce que l'usage recommande de ranger ça d'une certaine manière,
ou est ce que je met ça vraiment comme je veux Í  l'intérieur de mon
répertoire /opt/rapid/ ?

je tacherai d'utiliser GPRinstall (puisqu'il a été fait pour simplifier
la vie des gens, autant s'en servir)
et il me semble qu'il sait bcp mieux que moi o͹ installer les choses !
donc le moment venu, je te demanderai (ou Í  d'autres) si le résultat te
plait ou s'il faut changer des choses
In article <606b63da$0$3710$,
Nicolas George <nicolas$ wrote:
Thomas , dans le message
, a écrit :
> le binaire cherche des images, et je ne sais pas comment gérer ça pour
> qu'il les trouve quand il est Í  son emplacement de compilation et aussi
> quand il est Í  son emplacement d'installation
>
> actuellement, la conception c'est que :
> - on se place dans le répertoire de compilation,
> - on exécute le Makefile qui se trouve Í  cet endroit,
> - le logiciel est fabriqué Í  cet endroit aussi,
> - comme ça il est accessible tout ce suite, on n'a pas besoin de changer
> de répertoire pour le trouver !
> mauvaise idée ?
Ce n'est pas durable.

Il faut rendre l'emplacement des fichiers de données configurable Í 
l'exécution, avec une option de ligne de commande ou une variable
d'environnement.


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) :
mais je me demande comment je devrais gérer les images dans ce cas lÍ  :
- en faire une copie ͠ l'emplacement o͹ on me demande de compiler ?
- utiliser des astuces pour que le binaire sache retrouver les images Í 
leur emplacement d'origine ?
- on n'a pas besoin que le binaire soit exécutable Í  son emplacement de
compilation, tant qu'il n'est pas installé ? (ça par contre, j'aurais
tendance Í  désapprouver)

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 :
est ce que l'usage recommande une chose plutÍ´t qu'une autre,
ou est ce que je fais vraiment comme je veux du moment que cette
possibilité existe d'une façon ou d'une autre et qu'elle est documentée ?

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
Thomas
In article <606d8e5a$0$3696$,
Nicolas George <nicolas$ wrote:
Thomas , dans le message
, a écrit :
il me semble que t'as lu mon code,
tu as donc vu que je fais déjÍ  un foreach pour traiter chaque élément
d'un répertoire donné ?
mais il me semble qu'on ne peut pas s'en servir pour faire une boucle
récursive pour aller dans les sous dossiers, si ?

On peut probablement faire une boucle récursive, mais je n'ai pas
l'impression que ce soit nécessaire ici.
On peut faire une boucle dans une boucle, ça c'est très facile.

il se peut que pour finir je n'ai plus du tout besoin de tout ça, si
j'arrive Í  tout faire avec GPRinstall
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 :-)
en observant et réfléchissant, je crois savoir que la destination doit
être /opt/rapid/

La destination doit être configurable.

(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 ?)
mais il faut bien qu'il y ait un emplacement prévu par défaut, au cas o͹
l'utilisateur n'en donne pas
"pas durable" dans quel sens, peux tu préciser stp ?

Tu ne seras jamais packagé, par exemple.

ok,
effectivement, j'espère être packagé Í  l'avenir :-)
mais ça me parait prioritaire d'avoir un logiciel qui fait ce que je
veux, plutÍ´t qu'un logiciel buggé bien installé ;-)
mais je me demande comment je devrais gérer les images dans ce cas lÍ  :
- en faire une copie ͠ l'emplacement o͹ on me demande de compiler ?
- utiliser des astuces pour que le binaire sache retrouver les images Í 
leur emplacement d'origine ?
- on n'a pas besoin que le binaire soit exécutable Í  son emplacement de
compilation, tant qu'il n'est pas installé ? (ça par contre, j'aurais
tendance Í  désapprouver)

Il est parfaitement acceptable que lancer le binaire sans l'installer
demande une option ou une variable d'environnement.

ok, mais ça demande que l'exécutable soit amélioré pour savoir traiter
ça ... encore un peu de travail devant moi ...
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é)
a priori, je pensais que gnu avait pu s'inspirer des pratiques
constatées, pour établir tout ça ...

Un peu. Mais ils essaient aussi d'imposer leurs vues sur la Bonne Manière de
faire les choses.

ok, je vois un peu mieux le pb ...
par contre, si la doc de gnu ne te convient pas comme référence, y en a
t il une autre ?
par ex, ceux qui intègrent les logiciels dans les distributions, ils ont
probablement une doc, pour expliquer ce qui est requis et ce qui est
libre, pour eux ?
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
Nicolas George
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.
1 2