Re: [openplacos-dev] Re: configure && make && make install

[ Thread Index | Date Index | More lists.tuxfamily.org/openplacos-dev Archives ]


apres rubygem a des truc pour compiler des extension C, mais je pense pas que ca puisse s'appliquer a d'autre truc.

effectivement le module en C on est pas encore la, mais ca serais dommage de se retrouver un peut bloqué au niveau intégration si un gonz propose un truc pas en ruby, surtout si on met en avant l'aspect multi-language possible du truc.

Le 10 décembre 2011 18:21, flagos <flagospub@xxxxxxxxx> a écrit :
Le 10 décembre 2011 18:10, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :
> yop
>
> je me suis froté qu'une fois a autoconf, j'ai rien compris dans le flow mais
> ca a l'air d'être pas mal utilisé.

c'est bien on est 2 lol

>
> Setup.rb, quand j'avais matté ca avais l'air plus trop maintenu.

Oui c'est bizarre, la derniere version sur rubygem date de l'année
deniere, pas si vieux. Mais les repos sont souvent des liens morts.

>
> gem, j'ai eu l'impression que les fonctions pas trop usuelles changes tout
> le temps (un coup ca me calle des truc dans le bindir, un coup faut le faire
> a la main etc).
>
> c'est juste des impressions de surface (je veut pas lancer de troll)

>
> apres plus serieusement, les deux derniers outils sont très orienté ruby. et
> je me demande comment ca va se passer si on souhaite intégrer un module codé
> en C. a ce moment la le make devient utile.

Completement dacc. Après un module codé en C, c'est le truc qui va pas
arriver tout de suite quand meme. Enfin oui, c'est un bon point pour
autotools.
>
>
>
> Le 10 décembre 2011 17:57, flagos <flagospub@xxxxxxxxx> a écrit :
>
>> Petite précision: J'avais l'impression que les outils du style
>> autotools et setup.rb allaient plus loin que rubygem pour les paquets.
>> Je le pensais moins adapté que les autres, plus pensé pour un système
>> de lib, a la rubygem. En réalité, quand on feuillette la doc, ca a
>> tout de meme l'air possible de faire un truc pas mal. Disons qu'il n'a
>> pas l'air de manquer de plus de fonctionnalités que les autres ;-)
>>
>> Le 10 décembre 2011 17:54, flagos <flagospub@xxxxxxxxx> a écrit :
>> > Yop,
>> >
>> > En reprenant le mail envoyé cet après-midi, j'ai essayé d'imaginer ce
>> > qui serait par les outils selon les choix que l'on ferait:
>> >
>> > 1. Autotools:
>> > le ./configure aurait en argument les path vers bin_dir et lib_dir,
>> > cela résolverait des le configure les points 1 et 2.
>> > make a priori ne servirait a rien
>> > make install serait ensuite appelé, copie des sources et appel a gem
>> > ou bundler pour résoudre le point 7 (install des rubygem)
>> >
>> > 2. setup.rb
>> > Le flow serait analogue a celui des autotools. Tout ce qui change est
>> > que l'outil est plus simple a prendre en main mais moins standard.
>> >
>> > 3. gem
>> > Sur le repo, les executables se trouveraient dans le dossier bin, les
>> > sources dans un dossier lib. Ca reviendrait a résoudre dès la
>> > hirerarchie de nos fichiers sur le repo le problème du configure
>> > (points 1 et 2) grace a la surcouche gem
>> > Ensuite, on aurait un makefile:
>> > - make créerait un paquet gem en local
>> > - make install installerait ce paquet en executant directement gem
>> > install <le_paquet_genere>
>> >
>> >
>> > Dans les 3 cas, on continuerait ensuite sur un jeu de script
>> > spécifique a la distro pour résoudre les autres points souleves dans
>> > l'autre mail.
>> >
>> > Voila, c'est ce que j'ai compris de mes lectures de cet aprem. Je sais
>> > pas si j'ai tout mais ca m'a pas l'air trop déconnant, vous en pensez
>> > quoi ?
>> >
>> > --
>> > Tapé depuis mon clavier
>>
>>
>>
>> --
>> Tapé depuis mon clavier
>>
>>
>



--
Tapé depuis mon clavier





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/