Re: [Tsp-devel] TSP release 0.8.4?

[Eric Noulard]

Le 23 avril 2014 23:17, Olivier BONHOMME <address@hidden> a écrit :
> Le 23/04/2014 16:14, Eric Noulard a écrit :
>
>> Quelle version de CPack? (cpack --version)
>
> cpack 2.6-patch4
>
>>
>> Il est possible que le pb ne soit pas lié à CPack mais à des macros
>> (RPM) prédéfinies sur CentOS:
>> Est-ce que ça aurait à oir avec ça:
>> http://public.kitware.com/Bug/view.php?id=9872
>
> Ca pourrait ressembler effectivement. J'ai tenté d'appliquer le patch
> mais la variable CPACK_TOPLEVEL_DIRECTORY ne se substitue pas dans le
> tsp.spec généré par CPACK. Faut il faire une manip supplémentaire ?

Non mais je ne comprends pas.
Tu as remplacé ton CPackRPM.cmake de ton système avec celui
que tu as patché puis  tu as tenté un cpack -g RPM et le tsp.spec
généré n'est pas bon?


>
>> CPack a beaucoup évolué depuis l'époque ou j'avais écris le 
>> "UseRPMTools.cmake"
>>
>> Pour la gestion du ChangeLog tu as:
>>
>> CPACK_RPM_CHANGELOG_FILE
>> RPM changelog file.
>>
>>  * Mandatory : NO
>>  * Default   : -
>>
>>  May be used to embed a changelog in the spec file.
>>  The refered file will be read and directly put after the %changelog
>>  section.
>>
>> Voir aussi:
>> http://www.cmake.org/cmake/help/v2.8.8/cpack.html#section_VariablesspecifictoCPackRPMgenerator
>>
>> En dernier recours:
>> http://www.cmake.org/cmake/help/v2.8.8/cpack.html#variable:CPACK_RPM_USER_BINARY_SPECFILE
>
> Effectivement il y a des choses en plus depuis que je n'ai plus touché à
> CMake.
>>
>
>>> C'est à dire ? Séparer le packaging des sources ? Je suis 100 % pour.
>>
>> C'est déjà le cas:
>> make package_source
>>
>> Pour ce qui est de la production des RPM ou deb source
>> ce n'est pas vraiment le boulot de CPack (hors mis faire un tarball).
>
> Je voulais dire de sortir le SPEC et le répertoire debian/ et les
> générer avec les outils des distrib plutôt qu'avec CPack.

Ok si tu sais faire ça c'est probablement la meilleure méthode.
CPack sait générer des RPMs et de DEBs mais il sont considérés
comme "impurs" par des packageurs de distrib'.

Ceci étant CPack RPM utilise les outils des distrib' puisqu'il utilise
rpmbuild.
Pour CPack DEB c'est différent.

>> Je parlais plutôt de se servir des fonctionnalités un peu récentes
>> de CPack/CMake/CTest dans le build system de TSP.
>>
>> Génération plus "propre" des RPM et DEB, proposer l'utilisation
>> d'un installeur NSIS et WiX sous Windows etc...
>> Proposer des confs de cross-compile (target Win32/Win64 sur host
>> Linux) qui fonctionnent....
>
> Pour DEB et RPM ca peut se faire par contre je n'ai pas ce qu'il faut
> pour Windows. De plus je ne également pas si c'est utilisé en ce moment.

C'est la première question à se poser tu as raison.

Tout ce qui n'est pas utilisé devrait être supprimé et ressuscité plus tard si
quelqu'un en a besoin. Maintenir des choses utilisées est déjà suffisamment
chronophage pour ne pas avoir à maintenir des trucs inutilisés...

Pour finir si les DEB et RPM sont utiles le mieux est de les générer avec
les moyens/outils familier de celui qui fera le boulot. SI j'avais à le faire
(mais je ne le ferais pas par manque de temps) j'aurais utilisé CPack
si c'est toi ou une autre personne qui le fait je pense que c'est à elle
de choisir.

Bon courage.

-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org