Je suis en train d'installer une nouvelle machine en Open42, et
j'aimerais la garder un peu "propre". Je vais donc lancer un troll :)
Dans mes Linux, j'installe mes bricolages dans /usr/local qui m'est
quasiment réservé. J'ai donc un /usr/local/lib/ include/ bin/ toussa...
Dans le BSD, cet endroit commence à être rempli de Gnuseries, et je
ne voudrais pas mélanger les t-shirts jaunes[*] et mes torchons.
Donc, je me pose la question: quel est le repaire canonique à utiliser ?
Un /opt ? Un /tth ? Un /usr/private ? Un /usr/locale/moi ?
Ensuite, quand j'ai trouvé la bonne place (au fond près du poële) le
problème suivant est l'utilisation des .h/.so que je fabrique. Quels
sont les variables d'environnement à utiliser pour que gcc/ld trouve
ces fichiers très utiles pour la compilation des serviettes ?
En espérant ne pas survolter vos Prumpleffers, je vous souhaite une
bonne fin d'année...
tTh, éternel neu².
[*] Pour ceux qui comprennent pas, c'est une private-joke.
--
"All the things I really like to do are
either immoral, illegal, or fattening."
Pour l'instant, tout ce qui est ports termine dans /usr/local.
Tu peux mettre tes trucs ou tu veux.
C'est meme pas un gros probleme de les mettre dans /usr/local, tant que tu n'entres pas en conflit avec celles des ports, vu que pkg_add sait faire la difference.
Suffit d'un -Ipath_to_include -Lpath_to_libraries pour poser tes entetes et bibliotheques.
Par defaut, ld.so ne connait que /usr/local/lib, il est donc conseille d'y mettre les bibliotheques, ou au moins des liens symboliques vers celles-ci (c'est comme ca qu'on gere les versions multiples, a la qt et cie)
On a toujours des versions sur les bibliotheques, le libtool des ports est patche pour te permettre de mettre ce que tu veux comme numero de version, ce dont on se sert abondamment.
Pour l'instant, tout ce qui est ports termine dans /usr/local.
Tu peux mettre tes trucs ou tu veux.
C'est meme pas un gros probleme de les mettre dans /usr/local, tant que
tu n'entres pas en conflit avec celles des ports, vu que pkg_add sait
faire la difference.
Suffit d'un -Ipath_to_include -Lpath_to_libraries pour poser tes
entetes et bibliotheques.
Par defaut, ld.so ne connait que /usr/local/lib, il est donc conseille
d'y mettre les bibliotheques, ou au moins des liens symboliques vers
celles-ci (c'est comme ca qu'on gere les versions multiples, a la qt et cie)
On a toujours des versions sur les bibliotheques, le libtool des ports
est patche pour te permettre de mettre ce que tu veux comme numero de
version, ce dont on se sert abondamment.
Pour l'instant, tout ce qui est ports termine dans /usr/local.
Tu peux mettre tes trucs ou tu veux.
C'est meme pas un gros probleme de les mettre dans /usr/local, tant que tu n'entres pas en conflit avec celles des ports, vu que pkg_add sait faire la difference.
Suffit d'un -Ipath_to_include -Lpath_to_libraries pour poser tes entetes et bibliotheques.
Par defaut, ld.so ne connait que /usr/local/lib, il est donc conseille d'y mettre les bibliotheques, ou au moins des liens symboliques vers celles-ci (c'est comme ca qu'on gere les versions multiples, a la qt et cie)
On a toujours des versions sur les bibliotheques, le libtool des ports est patche pour te permettre de mettre ce que tu veux comme numero de version, ce dont on se sert abondamment.
espie
In article <1i9yc56.m13klszv4zfoN%, Xavier wrote:
Marc Espie wrote:
Pour l'instant, tout ce qui est ports termine dans /usr/local.
Tu peux mettre tes trucs ou tu veux.
C'est pour ma part le seul avantage restant que je vois à NetBSD. Les ports/packages vont dans /usr/pkg, et /usr/local est réservé à l'utilisateur. Ou au compilateur de Linuxeries, mais personne ne fait ça, j'en suis sûr :-)
C'est dans les cartons comme truc eventuellement a faire un jour. Ca demande juste pas mal de boulot d'adaptation, et on n'est pas trop sur que le jeu en vaille vraiment la chandelle.
In article <1i9yc56.m13klszv4zfoN%xavier@groumpf.org>,
Xavier <xavier@groumpf.org> wrote:
Marc Espie <espie@lain.home> wrote:
Pour l'instant, tout ce qui est ports termine dans /usr/local.
Tu peux mettre tes trucs ou tu veux.
C'est pour ma part le seul avantage restant que je vois à NetBSD. Les
ports/packages vont dans /usr/pkg, et /usr/local est réservé à
l'utilisateur. Ou au compilateur de Linuxeries, mais personne ne fait
ça, j'en suis sûr :-)
C'est dans les cartons comme truc eventuellement a faire un jour. Ca demande
juste pas mal de boulot d'adaptation, et on n'est pas trop sur que le jeu
en vaille vraiment la chandelle.
Pour l'instant, tout ce qui est ports termine dans /usr/local.
Tu peux mettre tes trucs ou tu veux.
C'est pour ma part le seul avantage restant que je vois à NetBSD. Les ports/packages vont dans /usr/pkg, et /usr/local est réservé à l'utilisateur. Ou au compilateur de Linuxeries, mais personne ne fait ça, j'en suis sûr :-)
C'est dans les cartons comme truc eventuellement a faire un jour. Ca demande juste pas mal de boulot d'adaptation, et on n'est pas trop sur que le jeu en vaille vraiment la chandelle.
Thierry P.
Suffit d'un -Ipath_to_include -Lpath_to_libraries pour poser tes entetes et bibliotheques.
il suffit d'utiliser pkg-config
Suffit d'un -Ipath_to_include -Lpath_to_libraries pour poser tes
entetes et bibliotheques.
Suffit d'un -Ipath_to_include -Lpath_to_libraries pour poser tes entetes et bibliotheques.
il suffit d'utiliser pkg-config
espie
In article <flbn5p$461$, Thierry P. wrote:
Suffit d'un -Ipath_to_include -Lpath_to_libraries pour poser tes entetes et bibliotheques.
il suffit d'utiliser pkg-config
Laisse-moi doucement rigoler. Une des raisons pour lesquelles on a remplace celui de gnu, c'est parce qu'avec son pote libtool, il se mettait systematiquement en travers du chemin a chaque fois qu'on voulait faire quelque chose de vaguement intelligent avec les entetes et bibliotheques...
In article <flbn5p$461$1@aioe.org>, Thierry P. <pinuche@gmail.com> wrote:
Suffit d'un -Ipath_to_include -Lpath_to_libraries pour poser tes
entetes et bibliotheques.
il suffit d'utiliser pkg-config
Laisse-moi doucement rigoler. Une des raisons pour lesquelles on a remplace
celui de gnu, c'est parce qu'avec son pote libtool, il se mettait
systematiquement en travers du chemin a chaque fois qu'on voulait faire
quelque chose de vaguement intelligent avec les entetes et bibliotheques...
Suffit d'un -Ipath_to_include -Lpath_to_libraries pour poser tes entetes et bibliotheques.
il suffit d'utiliser pkg-config
Laisse-moi doucement rigoler. Une des raisons pour lesquelles on a remplace celui de gnu, c'est parce qu'avec son pote libtool, il se mettait systematiquement en travers du chemin a chaque fois qu'on voulait faire quelque chose de vaguement intelligent avec les entetes et bibliotheques...
Thierry P.
il suffit d'utiliser pkg-config
Laisse-moi doucement rigoler. Une des raisons pour lesquelles on a remplace celui de gnu, c'est parce qu'avec son pote libtool, il se mettait systematiquement en travers du chemin a chaque fois qu'on voulait faire quelque chose de vaguement intelligent avec les entetes et bibliotheques...
Remplacer la Gnuterie est le fantasme de tout utilsateur d'un *BSD* ;)
Pour en revenir à nos moutons, le mieux serait que Thierry de la Buvette apprenne à fabriquer lui même ses paquets :(
il suffit d'utiliser pkg-config
Laisse-moi doucement rigoler. Une des raisons pour lesquelles on a remplace
celui de gnu, c'est parce qu'avec son pote libtool, il se mettait
systematiquement en travers du chemin a chaque fois qu'on voulait faire
quelque chose de vaguement intelligent avec les entetes et bibliotheques...
Remplacer la Gnuterie est le fantasme de tout utilsateur d'un *BSD* ;)
Pour en revenir à nos moutons, le mieux serait que Thierry de la Buvette
apprenne à fabriquer
lui même ses paquets :(
Laisse-moi doucement rigoler. Une des raisons pour lesquelles on a remplace celui de gnu, c'est parce qu'avec son pote libtool, il se mettait systematiquement en travers du chemin a chaque fois qu'on voulait faire quelque chose de vaguement intelligent avec les entetes et bibliotheques...
Remplacer la Gnuterie est le fantasme de tout utilsateur d'un *BSD* ;)
Pour en revenir à nos moutons, le mieux serait que Thierry de la Buvette apprenne à fabriquer lui même ses paquets :(
espie
In article <flhqnc$ful$, Thierry P. wrote:
il suffit d'utiliser pkg-config
Laisse-moi doucement rigoler. Une des raisons pour lesquelles on a remplace celui de gnu, c'est parce qu'avec son pote libtool, il se mettait systematiquement en travers du chemin a chaque fois qu'on voulait faire quelque chose de vaguement intelligent avec les entetes et bibliotheques...
Remplacer la Gnuterie est le fantasme de tout utilsateur d'un *BSD* ;)
Ah non, chez nous, c'est pas du fantasme, c'est de la realite. Et les vraies raisons du remplacement de pkg-config/libtool sont d'ordre technique: les versions gnu ne font pas ce qu'on veut, et c'est pas la peine d'esperer qu'elles le fassent un jour.
In article <flhqnc$ful$1@aioe.org>, Thierry P. <pinuche@gmail.com> wrote:
il suffit d'utiliser pkg-config
Laisse-moi doucement rigoler. Une des raisons pour lesquelles on a remplace
celui de gnu, c'est parce qu'avec son pote libtool, il se mettait
systematiquement en travers du chemin a chaque fois qu'on voulait faire
quelque chose de vaguement intelligent avec les entetes et bibliotheques...
Remplacer la Gnuterie est le fantasme de tout utilsateur d'un *BSD* ;)
Ah non, chez nous, c'est pas du fantasme, c'est de la realite.
Et les vraies raisons du remplacement de pkg-config/libtool sont d'ordre
technique: les versions gnu ne font pas ce qu'on veut, et c'est pas la
peine d'esperer qu'elles le fassent un jour.
Laisse-moi doucement rigoler. Une des raisons pour lesquelles on a remplace celui de gnu, c'est parce qu'avec son pote libtool, il se mettait systematiquement en travers du chemin a chaque fois qu'on voulait faire quelque chose de vaguement intelligent avec les entetes et bibliotheques...
Remplacer la Gnuterie est le fantasme de tout utilsateur d'un *BSD* ;)
Ah non, chez nous, c'est pas du fantasme, c'est de la realite. Et les vraies raisons du remplacement de pkg-config/libtool sont d'ordre technique: les versions gnu ne font pas ce qu'on veut, et c'est pas la peine d'esperer qu'elles le fassent un jour.
Thierry B.
--{ Thierry P. a plopé ceci: }--
Laisse-moi doucement rigoler. Une des raisons pour lesquelles on a remplace celui de gnu, c'est parce qu'avec son pote libtool, il se mettait systematiquement en travers du chemin a chaque fois qu'on voulait faire quelque chose de vaguement intelligent avec les entetes et bibliotheques...
Ils ont aussi des fourbes, à la FSF Corp. ?-)
Remplacer la Gnuterie est le fantasme de tout utilsateur d'un *BSD* ;)
Pas trop pour moi... En fait, je n'en ais pas trop: bash, glib, peut-être gmake...
Pour en revenir à nos moutons, le mieux serait que Thierry de la Buvette apprenne à fabriquer lui même ses paquets :(
J'y suis dessus en ce moment. Mais ça ne répond pas à la question d'origine. Pô grâve... Bon début d'année à tous.
-- <fufe> À vaincre sans baril, on triomphe sans boire.
--{ Thierry P. a plopé ceci: }--
Laisse-moi doucement rigoler. Une des raisons pour lesquelles on a remplace
celui de gnu, c'est parce qu'avec son pote libtool, il se mettait
systematiquement en travers du chemin a chaque fois qu'on voulait faire
quelque chose de vaguement intelligent avec les entetes et bibliotheques...
Ils ont aussi des fourbes, à la FSF Corp. ?-)
Remplacer la Gnuterie est le fantasme de tout utilsateur d'un *BSD* ;)
Pas trop pour moi... En fait, je n'en ais pas trop: bash, glib,
peut-être gmake...
Pour en revenir à nos moutons, le mieux serait que Thierry de la Buvette
apprenne à fabriquer lui même ses paquets :(
J'y suis dessus en ce moment. Mais ça ne répond pas à la
question d'origine. Pô grâve... Bon début d'année à tous.
--
<fufe> À vaincre sans baril, on triomphe sans boire.
Laisse-moi doucement rigoler. Une des raisons pour lesquelles on a remplace celui de gnu, c'est parce qu'avec son pote libtool, il se mettait systematiquement en travers du chemin a chaque fois qu'on voulait faire quelque chose de vaguement intelligent avec les entetes et bibliotheques...
Ils ont aussi des fourbes, à la FSF Corp. ?-)
Remplacer la Gnuterie est le fantasme de tout utilsateur d'un *BSD* ;)
Pas trop pour moi... En fait, je n'en ais pas trop: bash, glib, peut-être gmake...
Pour en revenir à nos moutons, le mieux serait que Thierry de la Buvette apprenne à fabriquer lui même ses paquets :(
J'y suis dessus en ce moment. Mais ça ne répond pas à la question d'origine. Pô grâve... Bon début d'année à tous.
-- <fufe> À vaincre sans baril, on triomphe sans boire.
Thierry B.
--{ Xavier a plopé ceci: }--
Pour l'instant, tout ce qui est ports termine dans /usr/local. Tu peux mettre tes trucs ou tu veux.
C'est pour ma part le seul avantage restant que je vois à NetBSD. Les ports/packages vont dans /usr/pkg, et /usr/local est réservé à l'utilisateur.
En fait, c'est vrai que je trouve ça NETtement plus propre. Depuis que je fréquente des nixeries diverses, j'ai toujours cru que /usr/local était, comme son nom semble l'indiquer, réservés aux trucs fabriqués sur place. Quelle est la raison (historique (legacy :), je suppose) pour que les gnuseries se retrouvent là dans Open ?
Ou au compilateur de Linuxeries, mais personne ne fait ça, j'en suis sûr :-)
Pouquoi vouloir à tout prix stigmatiser les switchers ;-}
-- L'attaque d'Usenet par UTF-8 (film à 22h30)
--{ Xavier a plopé ceci: }--
Pour l'instant, tout ce qui est ports termine dans /usr/local.
Tu peux mettre tes trucs ou tu veux.
C'est pour ma part le seul avantage restant que je vois à NetBSD. Les
ports/packages vont dans /usr/pkg, et /usr/local est réservé à
l'utilisateur.
En fait, c'est vrai que je trouve ça NETtement plus propre.
Depuis que je fréquente des nixeries diverses, j'ai toujours
cru que /usr/local était, comme son nom semble l'indiquer,
réservés aux trucs fabriqués sur place. Quelle est la raison
(historique (legacy :), je suppose) pour que les gnuseries
se retrouvent là dans Open ?
Ou au compilateur de Linuxeries, mais personne ne fait
ça, j'en suis sûr :-)
Pouquoi vouloir à tout prix stigmatiser les switchers ;-}
Pour l'instant, tout ce qui est ports termine dans /usr/local. Tu peux mettre tes trucs ou tu veux.
C'est pour ma part le seul avantage restant que je vois à NetBSD. Les ports/packages vont dans /usr/pkg, et /usr/local est réservé à l'utilisateur.
En fait, c'est vrai que je trouve ça NETtement plus propre. Depuis que je fréquente des nixeries diverses, j'ai toujours cru que /usr/local était, comme son nom semble l'indiquer, réservés aux trucs fabriqués sur place. Quelle est la raison (historique (legacy :), je suppose) pour que les gnuseries se retrouvent là dans Open ?
Ou au compilateur de Linuxeries, mais personne ne fait ça, j'en suis sûr :-)
Pouquoi vouloir à tout prix stigmatiser les switchers ;-}
-- L'attaque d'Usenet par UTF-8 (film à 22h30)
espie
In article , Thierry B. wrote:
--{ Xavier a plopé ceci: }--
Pour l'instant, tout ce qui est ports termine dans /usr/local. Tu peux mettre tes trucs ou tu veux.
C'est pour ma part le seul avantage restant que je vois à NetBSD. Les ports/packages vont dans /usr/pkg, et /usr/local est réservé à l'utilisateur.
En fait, c'est vrai que je trouve ça NETtement plus propre. Depuis que je fréquente des nixeries diverses, j'ai toujours cru que /usr/local était, comme son nom semble l'indiquer, réservés aux trucs fabriqués sur place. Quelle est la raison (historique (legacy :), je suppose) pour que les gnuseries se retrouvent là dans Open ?
Historique, essentiellement.
Plus le cote flag-day le jour ou on changera...
In article <vm8v45-3pb.ln1@prout.stex>,
Thierry B. <tth@prout.stex.invalid> wrote:
--{ Xavier a plopé ceci: }--
Pour l'instant, tout ce qui est ports termine dans /usr/local.
Tu peux mettre tes trucs ou tu veux.
C'est pour ma part le seul avantage restant que je vois à NetBSD. Les
ports/packages vont dans /usr/pkg, et /usr/local est réservé à
l'utilisateur.
En fait, c'est vrai que je trouve ça NETtement plus propre.
Depuis que je fréquente des nixeries diverses, j'ai toujours
cru que /usr/local était, comme son nom semble l'indiquer,
réservés aux trucs fabriqués sur place. Quelle est la raison
(historique (legacy :), je suppose) pour que les gnuseries
se retrouvent là dans Open ?
Pour l'instant, tout ce qui est ports termine dans /usr/local. Tu peux mettre tes trucs ou tu veux.
C'est pour ma part le seul avantage restant que je vois à NetBSD. Les ports/packages vont dans /usr/pkg, et /usr/local est réservé à l'utilisateur.
En fait, c'est vrai que je trouve ça NETtement plus propre. Depuis que je fréquente des nixeries diverses, j'ai toujours cru que /usr/local était, comme son nom semble l'indiquer, réservés aux trucs fabriqués sur place. Quelle est la raison (historique (legacy :), je suppose) pour que les gnuseries se retrouvent là dans Open ?
Historique, essentiellement.
Plus le cote flag-day le jour ou on changera...
Thierry P.
En fait, c'est vrai que je trouve ça NETtement plus propre. Depuis que je fréquente des nixeries diverses, j'ai toujours cru que /usr/local était, comme son nom semble l'indiquer, réservés aux trucs fabriqués sur place. Quelle est la raison (historique (legacy :), je suppose) pour que les gnuseries se retrouvent là dans Open ?
Il n'y a pas que de la gnuserie là-dedans
En fait, c'est vrai que je trouve ça NETtement plus propre.
Depuis que je fréquente des nixeries diverses, j'ai toujours
cru que /usr/local était, comme son nom semble l'indiquer,
réservés aux trucs fabriqués sur place. Quelle est la raison
(historique (legacy :), je suppose) pour que les gnuseries
se retrouvent là dans Open ?
En fait, c'est vrai que je trouve ça NETtement plus propre. Depuis que je fréquente des nixeries diverses, j'ai toujours cru que /usr/local était, comme son nom semble l'indiquer, réservés aux trucs fabriqués sur place. Quelle est la raison (historique (legacy :), je suppose) pour que les gnuseries se retrouvent là dans Open ?
