Alors, je pourrais (une seule ligne à modifier dans le code, si c'est pas beau ), mais ça risque de compliquer les choses, parce que du coup quand je veux obtenir le /home/ de l'utilisateur actuel quand on fait sudo poulp install truc (sudo est nécessaire ici), j'obtiens pas le vrai utilisateur mais root. Bon après, je pense que ça devrait pas être trop dur de trouver un moyen pour contourner ça. Je vais essayer de regarder ça.
Ou alors, je package les fichiers de config, ce qui me semble être la meilleure solution.
Parce qu'il faut mettre des fichiers .h, .vapi et .o dans des dossiers comme /usr/include/ ou /usr/lib64 qui, si je ne dis pas de bêtises, ne sont accessibles en écriture que par root.
Pas à ma connaissance, faudrait que je me renseigne.
Je n'ai pas réussi à voir d'où venait le problème, mais je pense que c'est un truc du genre le dépôt est mis en cache est donc dnf ne voit pas les nouvelles versions. Ou il les ordonne par ordre alphabétique, et r(c) < t(est) et donc test est considéré comme plus récent. Ou les deux.
Généralement on définit des variables d'environnement particulières (CPATH, LIBRARY_PATH, LD_LIBRARY_PATH…) pour pouvoir configurer un peu son environnement et éventuellement laisser un utilisateur non-root installer des bibliothèques et autres. Certains utilitaires équivalents à poulp pour d'autres langages s'en servent aussi pour mettre tout ce qu'ils installent au même endroit tout en restant utilisables sans root, et même supporter plusieurs environnements indépendants (par exemple pour des versions différentes du langage). Je ne sais pas si valac utilise correctement ces variables d'environnement, mais ça serait vraiment dommage s'il ne le faisait pas.
Est-ce que poulp ne devient pas un projet à part entière qui mériterait son propre thread ?
Parce qu'il faut mettre des fichiers .h, .vapi et .o dans des dossiers comme /usr/include/ ou /usr/lib64 qui, si je ne dis pas de bêtises, ne sont accessibles en écriture que par root.
Généralement on définit des variables d'environnement particulières (CPATH, LIBRARY_PATH, LD_LIBRARY_PATH…) pour pouvoir configurer un peu son environnement et éventuellement laisser un utilisateur non-root installer des bibliothèques et autres. Certains utilitaires équivalents à poulp pour d'autres langages s'en servent aussi pour mettre tout ce qu'ils installent au même endroit tout en restant utilisables sans root, et même supporter plusieurs environnements indépendants (par exemple pour des versions différentes du langage). Je ne sais pas si valac utilise correctement ces variables d'environnement, mais ça serait vraiment dommage s'il ne le faisait pas.
Je crois que je vais faire comme ça. En plus ça permettra à ceux qui ont une installation un peu chelou (genre les gens sous Windows, où les différentes versions de Vala sont jamais au même endroit) de pouvoir utiliser poulp quand même.
Est-ce que poulp ne devient pas un projet à part entière qui mériterait son propre thread ?
C'est en effet assez indépendant de Valse, mais en même temps je ne pense pas faire des mises à jours souvent (déjà que Valse n'évolue pas des masses en ce moment ), donc je sais pas trop si ça vaut le coup de créer un topic dédié.
Et y'a pas moyen d'inclure le code des librairies directement dans le répertoire du projet ? (un peu à la manière du dossier node_modules de npm).
Alors, il y aurait moyen, mais c'est très sale et pas du tout dans la logique de Vala. En plus ça risque plus de créer des problèmes qu'autre chose (typiquement ld qui ne trouve pas les libs parce que l'exécutable a été changé de place ou un truc comme ça).
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
), mais ça risque de compliquer les choses, parce que du coup quand je veux obtenir le 
