Discussion :

[Analou]

Bonjour,
Je suis en train d'utiliser les autotools pour faire de la compilation croisée. J'ai bien créé mes fichiers de base, j'utilise autoreconf, et arrive donc le moment du ./configure.
Le truc, c'est que j'ai des options de compilation qui diffèrent en fonction du compilateur que j'utilise. J'aimerais donc pouvoir créer un script qui, lorsque j'appelle configure, applique les bonnes options de configuration en fonction du compilateur choisi.
En espérant que j'aie réussi à me faire comprendre,
Merci d'avance.

[cmoibal]

Peut-être que la commande suivante peut t'aider :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
  ./configure --help

[kwariz]

Bonjour,

si tu écris configure.ac alors tu peux définir les options de compilation suivant le compilateur trouvé lors du configure. Si tu veux ensuite forcer un compilateur précis tu peux le passer à configure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

./configure CC=icc

si tu veux utiliser le compilateur d'intel par exemple.
Si tu as des options différentes suivant les plateformes alors tu peux les changer suivant les valeurs des variables host et build par exemple. Ces variables sont soit déduites de l'environnement soit forcées.

Pour ce que je comprends, ce que tu veux faire trouve sa place dans configure.ac et je pense qu'il n'est pas nécessaire d'ajouter un script qui lancerait configure.
Idéalement le seul script (hors configure) est autogen/bootstrap qui s'occupe de la première configuration (autoreconf -vif et autres).

[Analou]

Je vais regarder de plus près les variables que tu m'as données.
Sinon, je vais être plus précise sur ce que je souhaite faire.
Une fois les makefile.am et configure.ac créés, je souhaiterais ne plus avoir à y toucher, et ensuite les compiler pour différentes plateformes sans avoir à les modifier.
J'utilise autoreconf, et une fois que je fais ./configure avec la cible voulue, je voudrais que les options de compilation soient choisies sans que l'utilisateur ait à changer des variables:

je voudrais que ça donne quelque chose comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

./configure --target variable

et le script:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
if variable==powerpc
then
   utilise ces options de compilation;
etc...
fi

Penses-tu qu'il est possible de faire cela?

[Analou]

J'ai fait des recherches et trouvé ça :
(désolée c'est un peu long)


The variables ‘build_alias’, ‘host_alias’, and ‘target_alias’ are always exactly the arguments of --build, --host, and --target; in particular, they are left empty if the user did not use them, even if the corresponding AC_CANONICAL macro was run. Any configure script may use these variables anywhere. These are the variables that should be used when in interaction with the user.

If you need to recognize some special environments based on their system type, run the following macros to get canonical system names. These variables are not set before the macro call.

If you use these macros, you must distribute config.guess and config.sub along with your source code. See Output, for information about the AC_CONFIG_AUX_DIR macro which you can use to control in which directory configure looks for those scripts.
— Macro: AC_CANONICAL_BUILD

Compute the canonical build-system type variable, build, and its three individual parts build_cpu, build_vendor, and build_os.

If --build was specified, then build is the canonicalization of build_alias by config.sub, otherwise it is determined by the shell script config.guess.

— Macro: AC_CANONICAL_HOST

Compute the canonical host-system type variable, host, and its three individual parts host_cpu, host_vendor, and host_os.

If --host was specified, then host is the canonicalization of host_alias by config.sub, otherwise it defaults to build.

— Macro: AC_CANONICAL_TARGET

Compute the canonical target-system type variable, target, and its three individual parts target_cpu, target_vendor, and target_os.

If --target was specified, then target is the canonicalization of target_alias by config.sub, otherwise it defaults to host.

In configure.ac the system type is generally used by one or more case statements to select system-specifics. Shell wildcards can be used to match a group of system types.

For example, an extra assembler code object file could be chosen, giving access to a CPU cycle counter register. $(CYCLE_OBJ) in the following would be used in a makefile to add the object to a program or library.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
     AS_CASE([$host],
       [alpha*-*-*], [CYCLE_OBJ=rpcc.o],
       [i?86-*-*],   [CYCLE_OBJ=rdtsc.o],
       [CYCLE_OBJ=""]
     )
     AC_SUBST([CYCLE_OBJ])

Cela paraît être ce que je cherche, par contre je veux bien un peu d'aide pour m'expliquer ce que veut dire le code

[kwariz]

Bon, je vais m'étendre un peu juste pour clarifier les termes. Tu utilises les autotools, ils vont, entre autre, utiliser ton script configure.ac pour créer un script shell qui se nomme configure. Ce dernier va ensuite examiner ton système et créer des Makefile qui seront adaptés.
Nous allons donc agir sur configure.ac c'est là que nous allons gérer la cross-compilation.
Il y a trois paramètres que configure va examiner pour savoir si on crosscompile ou non :

• --build : c'est l'identification de la machine sur laquelle on compile
• --host : c'est l'identification de la machine sur laquelle on va exécuter le programme compilé
• --target : on ne va pas s'en préoccuper maintenant tu ne l'utiliseras jamais sauf si tu crosscompiles un crosscompilateur (-> tu buildes sur linux un compilateur tournant sous windows qui générera des exécutables pour arm )

Le build system est facilement reconnaissable, c'est la machine sur laquelle tu lances configure, le host system c'est la machine sur laquelle ton programme va tourner, celle pour laquelle tu développes.
Pour faire entrer la configuration en mode cross-compilation il va falloir préciser en paramètre pour quelle architecture tu veux compiler.
Pour cela il va falloir rajouter les deux macros AC_CANONICAL_BUILD et AC_CANONICAL_HOST dans configure.ac. Un autoreconf -vif t'installera les scripts requis (config.guess et config.sub). Cela va permettre à configure de déduire les machines pour lesquelles il va devoir générer les Makefile.

Par exemple, sur mon environnement (un pc sous linux 64bit)

• sans préciser ni host ni build, on va créer un configure qui générera des Makefile pour compiler sur un x86_64-unknown-linux-gnu et les exécutables créés seront destinés à une plateforme x86_64-unkown-linux-gnu (la même).
• si on précise un host qui est différent du host alors on entre en mode cross-compile. Imaginons que depuis mon linux je veuille créer des exécutables natifs win32 avec mingw. Je lancerais configure --host=x86_64-w64-mingw32, cela me donnera un sortie comme :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
  checking build system type... x86_64-unknown-linux-gnu
  checking host system type... x86_64-w64-mingw32
  checking target system type... x86_64-w64-mingw32
  checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc
  checking whether the C compiler works... yes
  checking for C compiler default output file name... a.exe
  checking for suffix of executables... .exe
  checking whether we are cross compiling... yes
  ...

  Cela fonctionne bien car j'ai installé toute la chaîne de crosscompilation.

Donc après avoir inséré les deux macros, tu disposes d'une variable shell host qui va contenir le nom de la plateforme d'exécution. Celle-ci est composée de trois parties, une qui identifie le processeur (ou famille de processeurs), une qui identifie le manufacteur, et la dernière pour l'OS. Ces trois parties sont séparées par des tirets, le caractère '-'. Par exemple, dans mon cas configure me dit que j'ai un x86_64 - unkown - linux-gnu : une machine à base de x86 64bit, sur un système qu'il ne reconnaît pas (en fait Suse), qui est un OS de type linux/GNU ; je lui demande de créer des exécutable pour un x86_64 - w64 - mingw32 : une plateforme à base de x86_64 sous windows 64bits avec un environement natif en utilisant les outils mingw.
La variable shell host va donc te permettre de discriminer la plateforme sur laquelle vont tourner tes softs.

C'est ce que fait le bout de code que tu as fournit. Ce sont des macros M4 (le langage utilisé pour construire le script configure. AC_CASE est une macro qui va générer un code shell portable pour faire un case.

Ton exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
     AS_CASE([$host],
       [alpha*-*-*], [CYCLE_OBJ=rpcc.o],
       [i?86-*-*],   [CYCLE_OBJ=rdtsc.o],
       [CYCLE_OBJ=""]
     )
     AC_SUBST([CYCLE_OBJ])

se lit donc simplement comme :
si la valeur de host matche alpha*-*-* (=on compile pour créer des exécutables qui tourneront sur une architecture alpha) alors CYCLE_OBJ vaudra rpcc.o
sinon si host commence par un i est suivi d'un caractère quelconque puis d'un 86 (i386,i486,i586 ...=architecture IA32) alors CYCLE_OBJ vaudra rdtsc.o
sinon, bah CYCLE_OBJ sera vide.

Ensuite dans tes Makefile.am tu peux utiliser CYCLE_OBJ[ sans te préoccuper de ce qu'il contient puis qu'il contiendra le bon fichier pour la plateforme cible

[Analou]

Merci
Juste une question (encore!):
Ils contiennent quoi ces fichiers (par exemple rpcc.o)?

[koala01]

Salut,

Merci
Juste une question (encore!):
Ils contiennent quoi ces fichiers (par exemple rpcc.o)?

Ca, c'est juste un exemple de "fichier objet" (*) qui aura été généré par ailleurs

(*) comprends :un fichier qui contient tout le code binaire exécutable pour un processeur particulier généré à partir d'un fichier d'implémentation (*.c) particulier, mais sur lequel l'éditeur de liens n'est pas encore passé (ou qui n'a pas encore été placé dans une bibliothèque tierce)

[Analou]

Si je comprends bien, une que j'ai les makefile.am et que j'ai fait mon configure.ac avec le case, je peux lancer autoreconf puis configure.
Et une fois que configure est fait, les fichiers obj en question sont créés.
Mais ensuite, comment suis-je censée les utiliser?

[koala01]

Si je comprends bien, une que j'ai les makefile.am et que j'ai fait mon configure.ac avec le case, je peux lancer autoreconf puis configure.
Et une fois que configure est fait, les fichiers obj en question sont créés.
Mais ensuite, comment suis-je censée les utiliser?

En fait, cet exemple se base sur le principe que tu as, dans ton projet, deux fichiers qui seraient sans doute nommés rpcc.c et rdtsc.c, que le premier est destiné à être utilisé sur une machine basée sur un processeur alpha et que le second est destiné à être utilisé sur une machine basée sur un X86.

Evidemment, ces deux fichiers sont, pourquoi pas, susceptible de contenir l'implémentation de fonctions identiques, mais dont la logique est adaptée soit à un alpha soit à un X86. Il ne faut donc pas que ces fichiers soient interverti (le premier utilisé avec un X86 et le second avec un alpha) parce que... ca foutrait un b...el incroyable

Mais, quand tu vas arriver à l'édition des liens, il faut:

• que rpcc.c ait été compilé (sous le doux nom de rpcc.o) pour un alpha
• que rdtsc.c ait été compilé (sous le doux nom de rdtsc.o) pour un x86
• qu'aucun fichier ne soit utilisé pour les autres architecture

Au niveau de ton Makefile.am, tu auras donc une règle pour l'édition de liens (ou pour la création de ta bibliothèque) qui contiendra la variable CYCLE_OBJ pour "tenir lieu" du nom du fichier objet adéquat, et le reste se fera automatiquement

[kwariz]

C'est un poil plus complexe
On va commencer avec un cas de figure simple mais général pour comprendre comment ça fonctionne.
Tu écris 3 fichiers (dans ton cas) qui vont décrire ton projet : configure.ac, Makefile.am, src/Makefile.am. autoreconf va lire ces trois fichiers et suivant leur contenu créer d'autres fichiers : configure, config.h.in, Makefile.in et src/Makefile.in. En fait le réalité et un peu plus complexe cat autoreconf va appeler d'autres programmes (dont le nom commence par auto -> d'où le nom autotools pour l'ensemble de ces programmes). Cette phase est une phase de préparation/description de ton projet. En général le gestionnaire de projet fournit un script shell nommé autogen.sh ou bootstrap.sh pour faire ça, car parfois il faut un peu plus qu'un simple autoreconf -vif. Mais cela en général tu ne le fais qu'une fois au départ.

Le projet est prêt à être configuré pour ta plateforme
Une fois que tu as fait ça, tu lances configure avec certains paramètres, il va prendre les autres fichiers (ceux se terminant en .in) pour créer les config.h (qui va décrire ce qui est disponible par exemple en terme de #define C), mais aussi les Makefile. Tout ça de manière à pouvoir utiliser les outils dont tu disposes. Cela tu ne le fais qu'une fois pour chaque ensemble de paramètres, il est d'ailleurs souvent plus simple de te créer une arborescence de construction pour ça et de ne pas lancer un configure à la racine de ton projet.

Le projet est prêt à être construit
Là tu es sûre d'avoir tous les outils dans les bonnes versions et prêt à être utilisés avec les bonnes options, les bonnes bibliothèques, ... Et la tu lances souvent des make en phase de dèv, les Makefile s'occupent de tout pas trop mal.

L'optique c'est qu'en déclarant un minimum de choses dans les fichiers de départ, n'importe qui avec les bon outils va pouvoir construire ton projet et même pouvoir l'adapter à ses propres outils (enfin dans l'idéal).

Ça c'est pour avoir un point de vue assez général et pouvoir prendre un peu de recul.

Donc, mais il faudra nous en dire un peu plus sur ta crosscompilation, imaginons que ton projet soit prévu pour créer un programme sensé devoir tourner aussi bien sur windows que sur linux et que ta plateforme de développement soit sous linux.
Il va falloir lors de la compilation savoir si tu utilises les outils pour créer des exe linux ou des exe windows -> ça ça se fait au moment du configure et ensuite tu es sûre qu'en lançant un make les bon outils seront utilisés. Tu n'as à priori rien à faire de plus.

Il arrive malheureusement que certaines parties de ton code soit exclusivement prévues pour linux et d'autres exclusivement pour windows.
Là ça se corse un tout petit peu.
Le moyen le plus simple (mais pas forcément le plus adéquat à toutes les situations) est de créer un #define qui va te dire dans quel cas tu te trouves. Ce #define sera mis par configure dans le fichier config.h. Il faudra évidemment l'inclure partout (oui c'est pas la meilleure solution dans certains cas).
Pour faire cela il va falloir modifier le fichier configure.ac. Dans un premier temps on va examiner la variable host pour savoir pour quelle plateforme on compile. Si on compile pour linux on va définir FOR_LINUX, et si on compile pour windows on va définir FOR_WINDOWS. Pour que ces définitions apparaissent ou non dans config.h il faut utiliser dans configure.ac la macro AC_DEFINE.
On pourrait donc imaginer dans ton configure.ac quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
     AS_CASE([$host],
       [*-*-*linux*], [AC_DEFINE(FOR_LINUX)],
       [*-*-*mingw*],   [AC_DEFINE(FOR_WINDOWS)],
       [AC_MSG_ERROR("unsupported system")]
     )

Le fichier config.h contiendra alors une ligne du genre #define FOR_LINUX 1 si on compile pour linux, ou bien #define FOR_WINDOWS 1 si on compile pour windows.

Ensuite dans ton propre code tu peux faire un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
  ici le code qui est commun aux deux plateformes
#if  defined(FOR_LINUX)
  ici le code spécifique à linux
#elif defined(FOR_WINDOWS)
  ici le code spécifique à windows
#endif
  ici on a de nouveau le code commun aux deux plateformes

Ça peut paraître un peu compliqué (surtout que pour un exemple simple comme celui que j'ai donné il y a d'autres méthodes) mais c'est surtout parce que tu commences directement à apprendre les autotools en faisant de la crosscompilation ...

[Analou]

Je poste ici, même si ce n'est pas exactement le sujet.
J'utilise la compilation croisée grâce à:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

./configure --host=...

Mon programme compile sur mon pc (linux), sur c6x, mais quand je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

./configure --host=ppc

j'obtiens l'erreur suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
./configure --host=powerpc
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for powerpc-strip... no
checking for strip... strip
checking for powerpc-gcc... ppc_60x-gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.

Voici la partie du config.log qui, je pense, est concernée:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
gcc version 3.4.4 (ELinOS 4.2 3.4.4-40 2008-09-17)
configure:2034: $? = 0
configure:2036: ppc_60x-gcc -V </dev/null >&5
ppc_60x-gcc: `-V' option must have argument
configure:2039: $? = 1
configure:2062: checking for C compiler default output file name
configure:2065: ppc_60x-gcc  -march=c674x -L/vobs/elin/C66/ATELIER/sdk/bin/../c6x-uclinux/libc/c674x -DC6X  -march=c674x -L/vobs/elin/C66/ATELIER/sdk/bin/../c6x-uclinux/libc/c674x -DC6X  conftest.c  >&5
cc1: error: invalid option `arch=c674x'
cc1: error: invalid option `arch=c674x'
configure:2068: $? = 1
configure: failed program was:
| /* confdefs.h.  */

Je n'ai pas trouvé sur internet ce que cette erreur pouvait vouloir dire

[Analou]

Autant pour moi, comme je chargeais alternativement les deux environnements, ils se "collapsaient" et configure ne comprenait plus rien.