Les outils automatiques peuvent-ils créer des makefiles multiplates-formes

Question

Je développe depuis quelques années un projet de plug-in qui fonctionne avec de nombreuses combinaisons de [version principale de l'application, version de la bibliothèque tierce, 32 bits par rapport à 64 bits]. Existe-t-il un moyen (propre) d'utiliser autotools pour créer un fichier Make unique qui génère toutes les versions du plug-in.

Autant que je sache, en parcourant la documentation d'Autotools, l'approximation la plus proche de ce que je voudrais, c'est d'avoir N copies indépendantes du projet, chacune avec son propre fichier Make. Cela semble un peu sous-optimal pour les tests et le développement car (a) il me faudrait continuellement propager les modifications de code sur toutes les copies et (b) il y a beaucoup d'espace perdu dans la duplication du projet à maintes reprises. Y a-t-il un meilleur moyen?

EDIT:

Je lance ma propre solution depuis un certain temps, où je dispose d’un makefile sophistiqué et de quelques scripts Perl pour rechercher différentes versions de bibliothèques tierces, etc. En tant que tel, je suis ouvert à d’autres solutions non autotools. Pour les autres outils de construction, je souhaiterais qu'ils soient très faciles à installer par les utilisateurs finaux. Les outils doivent également être suffisamment intelligents pour rechercher diverses bibliothèques et en-têtes tiers sans trop de problèmes. Je recherche principalement une solution Linux, mais une solution qui fonctionne aussi pour Windows et / ou Mac serait un bonus.

Answer 1

Autant que je sache, vous ne pouvez pas faire ça. Cependant, êtes-vous coincé avec autotools? Ne sont pas CMake ni SCons une option?

Answer 2

Si votre question est:

  

Puis-je utiliser les outils automatiques sur une machine A pour créer un seul fichier makefile universel qui fonctionnera sur toutes les autres machines?

alors la réponse est "Non". Les outils automatiques ne font même pas semblant d’essayer de le faire. Ils sont conçus pour contenir du code portable qui déterminera comment créer un fichier makeable sur la machine cible.

Si votre question est:

  

Puis-je utiliser les outils automatiques pour configurer les logiciels devant fonctionner sur différentes machines, avec différentes versions du logiciel principal utilisé par mon plug-in, ainsi que diverses bibliothèques tierces, sans oublier les problèmes 32 bits ou 64 bits?

alors la réponse est "Oui". Les outils automatiques sont conçus pour pouvoir le faire. De plus, ils fonctionnent sous Unix, Linux, MacOS X, BSD.

J'ai un programme, SQLCMD (qui date d'avance de plus de dix ans pour le programme Microsoft du même nom), qui fonctionne avec les bases de données IBM Informix. Il détecte la version du logiciel client (appelée IBM Informix ESQL / C, composant d'IBM Informix ClientSDK ou CSDK) installée, ainsi que le format 32 bits ou 64 bits. Il détecte également la version du logiciel installée et adapte ses fonctionnalités à ce qui est disponible dans le produit pris en charge. Il prend en charge les versions publiées sur une période d'environ 17 ans. Il est autoconfiguré - je devais écrire des macros autoconf pour la fonctionnalité Informix et pour quelques autres gizmos (cadencement haute résolution, présence de / dev / stdin, etc.). Mais c'est faisable.

D'autre part, je n'essaie pas de publier un seul fichier Make qui s'adapte à toutes les machines et tous les environnements client. il y a trop de possibilités pour que cela soit raisonnable. Mais autotools s’occupe des détails pour moi (et mes utilisateurs). Tout ce qu'ils font est:

./configure

C’est plus facile que de savoir comment éditer le fichier Make. (Oh, pendant les 10 premières années, le programme a été configuré à la main. C’était difficile à faire, même si ma configuration par défaut était plutôt bonne. C’est pourquoi j’ai opté pour la configuration automatique: c’est beaucoup plus facile pour les utilisateurs. personnes à installer.)

M. Fooz a commenté:

  

Je veux quelque chose entre les deux. Les clients utiliseront plusieurs versions et bits de la même application de base sur la même machine dans mon cas. Je ne m'inquiète pas de la compilation croisée telle que la construction de binaires Windows sous Linux.

Avez-vous besoin d’une version séparée de votre plugin pour les versions 32 bits et 64 bits? (Je suppose que oui, mais vous pourriez me surprendre.) Vous devez donc fournir un mécanisme permettant à l'utilisateur de dire

./configure --use-tppkg=/opt/tp/pkg32-1.0.3

(où tppkg est un code pour votre package tiers, et l'emplacement est spécifiable par l'utilisateur.) Toutefois, gardez à l'esprit la facilité d'utilisation: moins il existe d'options de ce type que l'utilisateur doit fournir, le meilleur; Par contre, ne codez pas en dur les éléments qui devraient être facultatifs, tels que les emplacements d'installation. Certainement, regardez dans les emplacements par défaut - c'est bien. Et par défaut à l'odeur des choses que vous trouvez. Peut-être que si vous trouvez à la fois les versions 32 bits et 64 bits, vous devriez les créer - cela nécessiterait cependant une construction minutieuse. Vous pouvez toujours effectuer un écho "Recherche de package TP ... " et indiquez ce que vous avez trouvé et où vous l'avez trouvé. Ensuite, l'installateur peut changer les options. Assurez-vous de documenter dans ' ./ configure --help ' quelles sont les options; c'est la pratique standard des outils automatiques.

Ne faites rien d’interactif cependant; le script de configuration devrait s'exécuter, en indiquant ce qu'il fait. Le script Perl Configure (notez la lettre majuscule - il s’agit d’un système de configuration automatique totalement séparé) est l’un des rares systèmes de configuration extrêmement interactifs restants (et c’est probablement principalement en raison de son héritage; si vous démarrez de nouveau , ce serait très probablement non interactif). Un tel système

Answer 3

Nous avons essayé et ça ne marche pas! Nous utilisons donc maintenant SCons .

Quelques articles sur ce sujet: 1 et 2

Modifier: Quelques petits exemples pourquoi j'aime SCons:

env.ParseConfig('pkg-config --cflags --libs glib-2.0')

Avec cette ligne de code, vous ajoutez GLib à l'environnement de compilation ( env ). Et n'oubliez pas le Guide de l'utilisateur . ce qui est génial pour apprendre SCons (vous n'avez vraiment pas besoin de connaître Python!). Pour l'utilisateur final, vous pouvez essayer SCons avec PyInstaller ou quelque chose du genre.

Et par rapport à make , vous utilisez Python, donc un langage de programmation complet! Dans cet esprit, vous pouvez tout faire (plus ou moins).

Answer 4

Avez-vous déjà envisagé d’utiliser un seul projet avec plusieurs répertoires de construction? si votre projet automake est correctement implémenté (c'est-à-dire pas comme gcc)

les possibilités suivantes sont possibles:

mkdir build1 build2 build3
cd build1
../configure $(YOUR_OPTIONS)
cd build2
../configure $(YOUR_OPTIONS2)
[...]

vous pouvez transmettre différents paramètres de configuration, tels que les répertoires include et les compilateurs (compilateurs croisés, par exemple).

vous pouvez même exécuter cela en un seul appel en exécutant

make -C build1 -C build2 -C build3