J'ai un projet assez complexe (C++) utilisant autoconf/automake, qui inclut des fichiers "générés" (foo.yy -> foo.cc). Les builds réels sont réalisés en utilisant un "script de contrôle" (Gentoo .ebuild pour ceux qui sont familiers avec le concept), sur différentes plateformes. Maintenant, l'une des plates-formes cible ne prend pas correctement en charge l'étape foo.yy -> foo.cc et doit utiliser le fichier foo.cc généré sur une machine Linux.Le meilleur moyen d'ajouter des fichiers générés à la distribution?
Maintenant, j'ai deux façons d'aller à ce sujet:
1) Arrivée foo.cc dans le référentiel du projet et le patch en quelque sorte configure.in (ou autre) pour inclure un contrôle d'horodatage sur foo.yy/foo .cc, générant un message d'erreur compréhensible s'il est exécuté sur la cible en question avec un foo.cc obsolète;
2) Archivez foo.cc dans le référentiel de scripts de contrôle et demandez au script de contrôler les horodatages et de donner le message d'erreur.
Je pourrais faire 2) pas de problème, mais je ne pense pas que ce soit le bon endroit pour mettre foo.cc. D'autre part, je ne connais pas grand-chose à autoconf/automake, et je ne saurais pas comment implémenter un message d'erreur/vérification d'horodatage dans configure.in (ou ailleurs).
Quelles sont vos suggestions, et quelqu'un pourrait-il savoir comment s'y prendre?
Édition: Résolvez en utilisant la solution 3), peaufinant la boîte cible problématique jusqu'à ce qu'elle soit capable de faire elle-même l'étape foo.yy -> foo.cc. Mon problème est résolu.
Mais je vais laisser la question ouverte - comment faire des contrôles d'horodatage/messages d'erreur compréhensible avec autoconf/automake?
Si vous faites un "make dist", puis distribuez * that * aux cibles et construisez le paquet à partir de la distribution. Mais ce n'est pas fait dans ce cas, les binaires sont construits directement à partir de ce qui est dans le CVS ... Voir la question éditée - ce n'est plus un problème pour moi personnellement. – DevSolar
Pourquoi distribuer directement à partir de votre VCS? (J'espère que 'CVS' est une faute de frappe - vous n'utilisez pas vraiment CVS, n'est-ce pas?) Les choses sont vraiment plus simples si vous ne faites que lancer la chaîne d'autotool sur votre boîte de développement et distribuer l'archive tar. En particulier, vous n'avez pas besoin d'avoir yacc ou lex ou autoconf ou automake ou libtool ou m4 (etc) installé sur votre boîte cible. –
"' make dist' "est le moyen de créer une distribution en utilisant automake (ou n'importe quel paquet qui suit les conventions GNU, d'ailleurs). Si vous n'allez pas utiliser ce que automake fournit, automake ne peut pas faire grand-chose pour vous aider. – Braden