Logiciel : VHFFS l'hébergement libre pour tous en 4.1
Posté par baud123 (Jabber id, page perso, ). Modéré le 22 février 2008.
VHFFS ou « Virtual Hosting For Free Software » est l'outil développé par TuxFamily.org pour proposer un hébergement libre à ses utilisateurs. Il est organisé en groupes pour accéder à un ensemble de services parmi : espace web PHP 4 et 5, bases (MySQL/PostgreSQL), gestion des DNS, listes de diffusion, gestionnaires de code source (CVS, Subversion, Git), espaces de téléchargements, etc. le tout sous licence libre (BSD).
La version 4.1 de VHFFS apporte :
N'hésitez pas à l'installer pour l'utiliser ou tout simplement le tester : nous avons besoins de retours, de graphistes aussi d'ailleurs ou tout simplement de développeurs pour ajouter des fonctionnalités.
La version 4.1 de VHFFS apporte :
- Un refactoring complet, ayant notamment permis de simplifier au maximum le modèle de données et l'API ;
- Une meilleure internationalisation (espagnol mieux traduit, meilleures documentations, etc.) ;
- Passage aux autotools pour faciliter l'installation ;
- Un renouveau du thème principal utilisé (le thème Barbie a été perdu dans la bataille /o\ dommage nous n'avons pas gardé de copies d'écrans de la 4.0) et un peu plus de web 2.0 ;
- L'ajout de Git pour la gestion de code source, dont a bénéficié rapidement TuxFamily.org qui fonctionne avec une version SVN de VHFFS.
N'hésitez pas à l'installer pour l'utiliser ou tout simplement le tester : nous avons besoins de retours, de graphistes aussi d'ailleurs ou tout simplement de développeurs pour ajouter des fonctionnalités.
Site de VHFFS (1378 hits)
Téléchargement de VHFFS 4.1 (144 hits)
Documentations d'installation (149 hits)
Les tutoriels de la communauté (244 hits)
> Lire la dépêche (14 commentaires, moyenne: 4,8).
Vous avez demandé le commentaire #907064.




autotools ?
Ca fait des années que je n'ai pas vu les mots "autotools" et "facile" dans la même phrase, sans avoir une négation entre les deux.
On pourrait détailler, parce que autotools est quand même connu pour être un truc super compliqué et lourd, remplacé allègrement de nos jours par CMake, qmake, scons, waf, ...
phil.freehackers.org
[^]Re: autotools ?
Je suppose qu'il sous-entend par là que c'est facile pour l'utilisateur mais pas forcement pour les développeurs.
Tu ne peux pas nier qu'un projet basé sur des autotools (quand c'est bien fait) c'est facile : ./configure && make && sudo make install et ca te dis ce qu'il manque ou si tout va bien.
Qu'est-ce qui est petit, rond et vert, qui monte et qui descend ?
Yoda qui fait le con avec la force.
[^]Re: autotools ?
Oui oui, on a bien précisé pour faciliter l'installation parce que sinon c'est une chiotte pas possible (on vous attend sur IRC si vous voulez en discuter). Je me suis chargé en grande partie de faire fonctionner le bordel (en fait j'avais l'obsession d'avoir un distcheck qui marche) et ça n'a pas été vraiment drôle (surtout qu'il reste des trucs non standards, notamment la gestion des répertoires).
En fait j'ai l'impression que le système des autotools est prévu pour... rien, à part un ptit programme C (ou C++ à la rigueur) fait vite fait mais sinon dès qu'on commence à avoir des trucs spécifiques c'est prise de tête sur prise de tête. Je parlerais pas du système du fichier POFILES pour l'i18n qui est à vomir...
[^]Re: autotools ?
Pourquoi avoir fait ce choix dans ce cas ? Quid des alternatives, elles n'auraient pas convenu ?
phil.freehackers.org
[^]Re: autotools ?
Quelqu'un nous a soumis un patch dans un premier temps. On l'a intégré puis on s'est retrouvés à le debugger puis le maintenir...
Au niveau alternatives, j'ai regardé vite fait cmake ça m'a pas l'air mieux. J'ai l'impression qu'au niveau packaging pour les langages de script c'est pas joyeux... Mais si tu as des pistes n'hésite pas :)
[^]Re: autotools ?
Idem : on m'a dit maintes fois "autotools c'est la merde, prend x" avec x =cmake, etc...
Et au final, après un peu d'études, ben... C'est aussi aussi merdique pour cmake, en plus ca pourri ton répertoire source, non merci, si il me faut un fichier de conf par répertoire et par "système de compilation", je ne suis pas sorti... il n'y a pas que Linux dans la vie ;-) )
Donc bon, j'attends toujours une alternative, en attendant je me tape la tête avec autotools pour Linux...
[^]Re: autotools ?
ca pourri ton répertoire source
Ah bon. Pas chez moi.
(pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)
[^]Re: autotools ?
Bah, chez moi oui. J'aime bien cmake dans le principe, mais sont gros soucis c'est que, dès que tu as un gros projet, il te faut un répertoire cmake à la race, il te crée plein de fichier de cache... ect...
J'ai même du faire un .sh dédié au nettoyage de mes répertoires, pour quand je release... :s
Je cherche toujours l'outils ultime de compilation : multiplateforme, souple dans la configuration, propre dans l'organisation.
J'ai essayé :
- autotool > merde infâme a configurer
- SConstruct > trop de problème à l'utilisation (libs qui trouve pas, même si elles sont là... ect...)
- cmake > Pourri les répertoires de sources.
De plus en plus, je fais manuellement mes Makefiles, le soucis c'est que dès que tu change de distrib/os, bah, y'a toujours une modif spécifique à faire...
Milite pour un about:black sur les navigateurs ! (Sauvons la planète)
[^]Re: autotools ?
pour cmake, il est tout à fait possible de séparer les sources du répertoire "projet"
En tout cas c'est comme ça que je travaillais et ça ne pose aucun problème (y compris d'avoir un répertoire sources et plusieurs répertoires de projets, un console, un kdevelop, ...)
[^]Re: autotools ?
Plutôt que de dire "chez moi ça marche", on aimerai bien la façon de faire.
Car tiré de :
http://www.cmake.org/HTML/WritingCMakeLists.html
(c'est quand même la doc officielle...)
Adding A New Directory to a project
# A common way to extend a project is to add a new directory. This involves three steps: Create the new directory somewhere in your source directory hierarchy.
# Add the new directory to the SUBDIRS command in the parent directories CMakeLists.txt
# Create a CMakeLists.txt in the new directory with the appropriate commands
--> Ca te pourri un max ton répertoire source (déja que même une seul fichier à la racine du source est pour moi inacceptable, un fichier projet n'a pas à être dans /src... Et je passe sur les ./configure et compagnie qui sont souvent à la racine pour un projet Linux : et si je mettais les projet Boralnd, Microsoft ou Xcode à la racine aussi, ca ferait un beau bordel... Mais ca va, grace à Autotools je survi a peut pret, je peux les mettre dans un /prj/gnu...)
[^]Re: autotools ?
Plutôt que de dire "chez moi ça marche", on aimerai bien la façon de faire.
Voilà comment je fais pour avoir un répertoire src/ où les sources sont rangées, un répertoire lib/ où la librairie sera générée et un répertoire bin/ où les binaires seront rangés.
Le répertoire CMakeFiles sera aussi rangé dans le répertoire racine du projet:
http://pastebin.com/faa124b
Je ne sais pas si c'est la manière la plus esthétique de faire, mais ça marche.
[^]Re: autotools ?
Je confirme que c'est d'un point de vue utilisateur, parce que bon, le beuss c'est bien pendant 2 mois que nous l'avons entendu râler (et il râle encore sur les autotools, la preuve ci-dessus).
Généralement, cette partie absconse est faite par une personne motivée et une fois que le canevas est en place, c'est un tout petit pneu plus facile d'ajouter des vérifications en se basant sur les exemples déjà faits. En tout cas, sur eagle-usb c'est aussi comme cela que cela s'était passé.
[^]Re: autotools ?
c'est un tout petit pneu plus facile
ouais, après, ça roule !
ok -> [ ]
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc