> Plus sérieusement au niveau des gestionnaire de paquetage -rpm, portage, deb...- > cela rend caduc les bases des gestionnaire non???
Pas vraiment, mais ça leur enlève (enfin, simplifie à l'extrême) une partie du boulot: la gestion des fichiers. Quand à la gestion des dépendances, elle est absente des AppRun, et donc le gestionnaire de packages est utile. Mais on pourrait imaginer, sur une distrib 100% ROX, et en enrichissant un peu les AppRuns, fusionner totalement ces deux aspects de la gestion de paquets. (Quand à l'aspect "gestion de la compilation", c'est évident que un .ebuild qui fait principalement "AppRun --compile" fait double emploi, et donc sur ce plan là aussi, là fusion est largement envisageable. Mais bon, je trip là.)
> qu'en est il si on met à travers ce principe une application qui apporte ses include, > et qu'on lance un configure pour compilation d'un programme tiers ayant besoin de > ces sources, ainsi que d'autre, il faut tout se taper à la main les > --with-app-include=/// pour toutes les sources requise, ecla fait bc de manip non?
Généralement, c'est pour utiliser des librairies, pas des bouts de sources, qu'on inclut des headers externes à l'application (sauf bidouille à la "utilisation des filtres de mplayer dans transcode", mais là c'est déjà manuel). Et bien rassure toi, c'est déjà tout prévu, et largement aussi (plus) pratique que ce que tu connais actuellement.
Dans Rox, tout ce qu'il faut pour utiliser la librairie Toto est dans le répertoire Toto qui est un sous répertoire d'un des répertoires référencé par ton LIBDIRPATH. Quand une appli à besoin de Toto pour être compilée, ce path est parcouru lors du "AppRun --compile", jusqu'à trouver Toto. Or Toto contient les headers, les .so, etc., et un script permettant de générer les flags gcc qu'il faut pour l'utiliser.
Donc pas de problème, un répertoire à coller dans un endroit bien connu, c'est tout ce qu'il faut pour qu'une librairie soit totallement accessible et utilisable. Le seul hic c'est si tu veux utiliser une librairie Rox pour un programme non-Rox à compiler avec les habituels autotools, alors là ça va pas, c'est pas fait pour, et faut donner les paths à la main, mais je trouve pas ça critique. Bref, le système est différent, mais dispose d'outils qui lui sont propre et sont très pratiques. Et puis y'a des petits bonus, genre si t'as juste dumpé les sources de ta librairie, elle sera compilée la première fois que ce sera nécéssaire. Et même potentiellement, si elle est compilée Linux-x86 mais que tu en as besoin depuis une compile Hurd-ppc (oui, je sais, pas de si tôt) sur une autre machine du réseau, cette nouvelle archi sera compilée aussi dans un autre sous répertoire de Toto.
[^] # Re: ca va faire du bruit
Posté par tgl . En réponse à la dépêche ROX-Filer 2.0.0 est sorti.. Évalué à 4.
> cela rend caduc les bases des gestionnaire non???
Pas vraiment, mais ça leur enlève (enfin, simplifie à l'extrême) une partie du boulot: la gestion des fichiers. Quand à la gestion des dépendances, elle est absente des AppRun, et donc le gestionnaire de packages est utile. Mais on pourrait imaginer, sur une distrib 100% ROX, et en enrichissant un peu les AppRuns, fusionner totalement ces deux aspects de la gestion de paquets. (Quand à l'aspect "gestion de la compilation", c'est évident que un .ebuild qui fait principalement "AppRun --compile" fait double emploi, et donc sur ce plan là aussi, là fusion est largement envisageable. Mais bon, je trip là.)
> qu'en est il si on met à travers ce principe une application qui apporte ses include,
> et qu'on lance un configure pour compilation d'un programme tiers ayant besoin de
> ces sources, ainsi que d'autre, il faut tout se taper à la main les
> --with-app-include=/// pour toutes les sources requise, ecla fait bc de manip non?
Généralement, c'est pour utiliser des librairies, pas des bouts de sources, qu'on inclut des headers externes à l'application (sauf bidouille à la "utilisation des filtres de mplayer dans transcode", mais là c'est déjà manuel). Et bien rassure toi, c'est déjà tout prévu, et largement aussi (plus) pratique que ce que tu connais actuellement.
Dans Rox, tout ce qu'il faut pour utiliser la librairie Toto est dans le répertoire Toto qui est un sous répertoire d'un des répertoires référencé par ton LIBDIRPATH. Quand une appli à besoin de Toto pour être compilée, ce path est parcouru lors du "AppRun --compile", jusqu'à trouver Toto. Or Toto contient les headers, les .so, etc., et un script permettant de générer les flags gcc qu'il faut pour l'utiliser.
Donc pas de problème, un répertoire à coller dans un endroit bien connu, c'est tout ce qu'il faut pour qu'une librairie soit totallement accessible et utilisable. Le seul hic c'est si tu veux utiliser une librairie Rox pour un programme non-Rox à compiler avec les habituels autotools, alors là ça va pas, c'est pas fait pour, et faut donner les paths à la main, mais je trouve pas ça critique. Bref, le système est différent, mais dispose d'outils qui lui sont propre et sont très pratiques. Et puis y'a des petits bonus, genre si t'as juste dumpé les sources de ta librairie, elle sera compilée la première fois que ce sera nécéssaire. Et même potentiellement, si elle est compilée Linux-x86 mais que tu en as besoin depuis une compile Hurd-ppc (oui, je sais, pas de si tôt) sur une autre machine du réseau, cette nouvelle archi sera compilée aussi dans un autre sous répertoire de Toto.