2010-10-28 24 views
0

Je devrais créer plusieurs paquets de notre application en utilisant make (sur AIX).
Le contenu des packages doit être différent en fonction d'une variable d'environnement. Quelque chose comme - si la variable d'environnement WITH_CPP réglé sur "Y" alors la partie C++ de l'application doit être compilée et empaquetée dans le paquet d'installation.
Si la variable d'environnement WITH_CPP réglé sur "N" puis C++ partie d'application ne doit pas être construit et emballé au package d'installation.
Quelle est la manière correcte de traiter de telles conditions dans les fichiers makefile?Moyen correct d'appeler certaines cibles en fonction de la valeur de la variable d'environnement?

Répondre

1

Supposons que la cible est installation-package, et la façon d'inclure le C++ parties du package est d'ajouter C++ objets à une liste d'objets pour le package d'installation:

ifeq ($(WITH_CPP),Y) 
    INSTALLATION_OBJECTS += $(CPP_OBJECTS) 
endif 

Ou si la façon d'inclure la C++ parties est en construisant une cible distincte:

ifeq ($(WITH_CPP),Y) 
    installation-package: cpp-part 
endif 

ce sont de bonnes façons de le faire, mais il peut être une mauvaise chose à faire. Si le comportement du makefile dépend de variables environnementales, alors le même makefile donnera des résultats différents pour différents utilisateurs, ce qui peut être un casse-tête.

+0

D'accord, avec des mises en garde: Vous utilisez GNUisms dans une question qui ne traite pas nécessairement de GNUmake (l'OP mentionne AIX). Je suggère qu'une meilleure solution est d'utiliser 'automake' (ou au moins' autoconf'). Ensuite, l'utilisateur peut choisir de construire la partie C++ avec '--enable-cxx' (ou similaire, chercher la macro' AC_ARG_ENABLE') et les modifications appropriées au processus de construction peuvent être faites en utilisant 'AM_CONDITIONAL' (ou un mécanisme similaire pour non -automake'). –

+0

@Jack Kelly: Vous avez raison, je pensais en termes de GNUMake. GNUMake supporte AIX, mais AIX a son propre Make par défaut, avec lequel je ne suis pas familier. – Beta

0

Une autre approche est de faire les C++ parties de votre package dépendent une cible phony:

cxx: cxx-part-1 cxx-part-2 
.PHONY: cxx 

Ensuite, testez (mais ne dépendent pas) l'existence des différents C++ parties de votre package en cours de construction et installez-les s'ils existent. C'est faisable, mais une très mauvaise idée car le graphe de dépendance est maintenant nécessairement incomplet. Cela signifie également que l'utilisateur final doit savoir exécuter make && make cxx && sudo make install ou similaire. Utilisez simplement autoconf ou automake pour séparer l'étape de configuration de l'étape de construction.

+0

Peut-être que je me méprends. Il semble que 1) le comportement ne dépendra pas de la variable environnementale, 2) les parties C++ seront incluses si elles existent, qu'elles soient voulues ou non, et 3) il y a une certaine confusion entre faire un paquet d'installation et * installer * quelque chose. – Beta

+0

J'essaie de décrire quelque chose comme le fonctionnement du système de construction O'Caml. Fondamentalement, si vous voulez les compilateurs de code natif, vous devez exécuter 'make opt' à un moment donné avant' make install'. Le fait que cela ne dépende pas d'envvars est bien: ils étaient un mécanisme suggéré, pas celui qui doit être utilisé. Les deux méthodes ont leurs défauts, car ils ne sont pas manifestement reproductibles. –