Discussion :

[Jean-Marc.Bourguet]

Le problème serait différent si GCC permettait de spécifier un répertoire de sortie (chose triviale, supportée par tous les compilateurs normaux), mais ce n'est pas le cas.

Le repertoire de sortir de gcc (comme pour les autres compilateurs qui m'interesse, ceux de Sun et d'IBM) est le repertoire courant.

Code :

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

1
2
3
4
5
6
7
8
 
$ ls
$ touch a.c b.c 
$ mkdir obj
$ cd obj
$ gcc -c ../*.c
$ ls
a.o  b.o

[white_tentacle]

Le repertoire de sortir de gcc (comme pour les autres compilateurs qui m'interesse, ceux de Sun et d'IBM) est le repertoire courant.

Il me semble que tout le problème vient de là. MacLak ne peux pas se permettre de remodifier tous ses scripts de builds pour changer le répertoire courant avant chaque appel de gcc, et se trimbaler des .. dans tous les sens.

Chose que je peux tout à fait comprendre. Par contre, j'imagine qu'une solution à base de mv pourrait fonctionner, non ?

[screetch]

j'ai posté deux solutions potentielles qui fonctionnent (en tous cas chez moi).
ensuite, le ../ ne se promène pas partout, bordil de diou, il se promene dans la regle de compilation et est ajouté automatiquement par make.
mais il me semble que maclak n'a pas réellement demandé, ni envie, que l'on resolve son problème.

[Mac LAK]

Il me semble que tout le problème vient de là. MacLak ne peux pas se permettre de remodifier tous ses scripts de builds pour changer le répertoire courant avant chaque appel de gcc, et se trimbaler des .. dans tous les sens.

Exactement.

Chose que je peux tout à fait comprendre. Par contre, j'imagine qu'une solution à base de mv pourrait fonctionner, non ?

Justement, non : cela empêche la génération simultanée (multi plate-forme, je rappelle...) sur la même arborescence.

Or, même si c'est rare que l'on compile simultanément, cela arrive quand on doit tout lancer rapidement sans avoir à intervenir, ou lorsqu'on le fait en tâche de fond. Des déplacements, outre le fait de poser le souci de visibilité des objets produits (cf. post #18) qui fera forcément échouer les comparaisons de timestamps.

j'ai posté deux solutions potentielles qui fonctionnent (en tous cas chez moi).

C'est ce que je m'échine à t'expliquer : chez toi, c'est sur un petit test tranquille sans cas de compilation croisées, multi plate-formes, multi compilateurs et sur des sources dont l'arborescence te filerait la migraine.
Pour UN compilateur (GCC) qui n'est pas foutu de paramétrer le répertoire de sortie correctement, j'ai QUATRE autres compilos et une demi-douzaine d'outils qui, eux, savent parfaitement le faire et fonctionnent de façon optimale avec un répertoire de sortie spécifié.
Je ne vais donc pas péter cette structure pour arranger UN compilo, tout en plombant tout le reste du système.

ensuite, le ../ ne se promène pas partout, bordil de diou, il se promene dans la regle de compilation et est ajouté automatiquement par make.

Il se balade partout pour la simple et bonne raison que tous les autres outils prennent le fichier source à son emplacement d'origine, et un répertoire de sortie. Avec GCC, on est obligés de simuler ça via "-o", donc pas de compilation multiple. Autoriser la compilation multiple, cela veut dire se mettre dans le répertoire objet (qui n'est pas un sous-répertoire des sources, mais un répertoire frère), et aller pêcher les sources via un truc du style "../../../Projet1/Librairie1/Sources/*.cpp" : super, donc, va falloir calculer le nombre de "../" devant chaque nom, ou dupliquer les macros donnant les différents paths...

La raison est très simple en plus : pas de mise en configuration des fichiers intermédiaires, et pas de pollution des répertoires gérés en configuration avec des trucs qui n'y sont pas. Simple logique pour garder un truc propre, et pouvant contenir toutes les cibles de compilation simultanément (debug, release, win32, linux, etc...). De plus, bien entendu, les bases de makefiles sont communes à TOUTES les cibles, pour éviter d'avoir des choses définies à douze endroits différents, surtout si c'est pour les définir de façon différente.

mais il me semble que maclak n'a pas réellement demandé, ni envie, que l'on resolve son problème.

Ce n'est pas un problème pour moi : GCC est plus lent que VS, et n'offre pas les fonctionnalités que permettent 99% des compilateurs, ça s'arrête là. Je ne vais pas plomber les AUTRES compilations (>70% du temps total de compilation) pour améliorer uniquement GCC, c'est simple à comprendre. C'est à mon outil de s'adapter à moi, pas le contraire.

[Lavock]

Ce n'est pas un problème pour moi : GCC est plus lent que VS, ...

As tu essayé sur une compilation mono-fichier très-très gros ?

Pour le reste je veux bien, c'est pas natif sous gcc et ça peut-être ennuyeux... m'enfin, la rapidité c'est pas quelque chose de toute à fais binaire...
C'est comme un combat GPU ATI/NVIDIA; ça à pas vraiment de sens de comparer qualitativement des compilateurs.

De manière générale, tant que c'est sur du x86, une application windows on la fais avec le compilateur windows... Et une linux/macos avec GCC... C'est comme pour les vis, et même si on peux, dans l'absolue, visser du cruciforme avec du plat, en général on préfèrera du cruciforme...

[Mac LAK]

As tu essayé sur une compilation mono-fichier très-très gros ?

Je n'en ai pas sous la main, sauf à préprocesser un fichier puis à l'expédier au compilo. Je t'avoue toutefois que je n'ai qu'une très petite envie de jouer à mettre "à plat" un projet complet juste pour faire ce test, et encore moins de me peler à la main les vingts ou plus répertoires d'inclusion nécessaire pour compiler mes "gros trucs"...

Pour le reste je veux bien, c'est pas natif sous gcc et ça peut-être ennuyeux... m'enfin, la rapidité c'est pas quelque chose de toute à fais binaire...

Quand la génération complète de ton projet dure une demi-journée, tu commences à y réfléchir un peu plus.

De manière générale, tant que c'est sur du x86, une application windows on la fais avec le compilateur windows... Et une linux/macos avec GCC...

???? Je ne vois pas le rapport par contre. D'une part, je n'ai pas QUE des procs x86 à gérer, et d'autre part, la compilation sur machine native n'est pas envisageable de façon sérieuse : on doit impérativement utiliser des cross-compilateurs.

[Jean-Marc.Bourguet]

Il me semble que tout le problème vient de là. MacLak ne peux pas se permettre de remodifier tous ses scripts de builds pour changer le répertoire courant avant chaque appel de gcc, et se trimbaler des .. dans tous les sens.

Chose que je peux tout à fait comprendre. Par contre, j'imagine qu'une solution à base de mv pourrait fonctionner, non ?

Ou simplement utiliser un script qui wrap gcc en faisant le cd plutot que gcc directement. Un tel script -- qui adapte des options standardisees -- est parfois plus simple a faire et a utiliser que d'essayer de faire faire l'adaptation par make.

En passant, c'est bien la premiere fois que je vois quelqu'un pretendre que gcc est un compilateur rapide...

[screetch]

j'utilise le même système de build pour toute les compilations, chez moi le résultat est ainsi :

'install' finished successfully (54.973s)
selected variant debug-gcc-win32-x86-4.4.0 for build

'install' finished successfully (51.049s)
selected variant debug-msvc-win32-x86-9.0 for build

le build est encore plus rapide avec gcc sous linux
après bon, on peut avoir envie de résoudre ses problèmes, trouver des solutions ou améliorer son système de build, ou alors on est bien content d'avoir son petit test qui ne marche pas bien pour aller troller sur les forums. Moi je le répète ainsi, GCC a a peu près la même vitesse que le compilateur de visual c++, mais le système de build utilisé couremment (make) est beaucoup plus lent que le MSBuild dans visual studio.

[3DArchi]

Salut,
Je n'ai jamais fait de test pour comparer les deux compilo, mais là où j'ai noté une différence dans l'utilisation c'est à l'édition de lien. Sur mes projets, l'éditions des liens avec gcc est très lente en comparaison de visual. Peut-être le problème est-il dans un autre paramètre ?

[screetch]

windows ou linux ?
sous linux presque personne n'utilise l'équivalent des "declspec(dllexport)" ce qui peut augmenter les temps de link (car les tables de symboles grossissent)
j'ai essayé de l'utiliser mais je ne crois pas avoir vu de progression fulgurante.

sous linux cependant, le cross compilateur vers windows a un temps de link assez faramineux comparé a l'équivalent linuxien.

[Mac LAK]

j'utilise le même système de build pour toute les compilations, chez moi le résultat est ainsi :

VS plus rapide que GCC, donc...

le build est encore plus rapide avec gcc sous linux
après bon, on peut avoir envie de résoudre ses problèmes, trouver des solutions ou améliorer son système de build, ou alors on est bien content d'avoir son petit test qui ne marche pas bien pour aller troller sur les forums.

Ben le tien est concluant, tu crois ? VS plus rapide que GCC sur ton test... Là, t'es à moins d'une minute de compilation, et sûrement sans liens complexes : tu crois que ça donne quoi avec vingt fois plus de fichiers à compiler, et des dizaines de librairies linkées ? Et ça donne quoi si tu effectues ton build VS avec SON système de build, et non pas un autre ?

Quant à modifier le système de build : si tu as une solution miracle gratuite, automatisable, portable partout (y compris sur des cibles n'ayant pas tes outils favoris et qui n'ont QUE make) et que tu acceptes de venir le faire gratuitement, je suis preneur. Sinon, les heures de boulot utilisées pour faire ça ne seront peut-être jamais amorties avec le gain de temps de compilation... Ce qui est aussi une réalité économique.

mais là où j'ai noté une différence dans l'utilisation c'est à l'édition de lien.

Pour le link, la raison est très simple en fait : VS et GCC fonctionnent très différemment sur le principe du link.

VS parcourt les symboles inconnus de l'exécutable en cours de compilation, et recherche dans les librairies fournies en paramètre le symbole en question, dans l'ordre de déclaration des librairies. Inconvénient, il peut trouver le symbole plusieurs fois, et il serait dangereux même de le faire stopper après la première occurrence (plus de détection des conflits de runtime notamment).
GCC, par contre, parcourt les librairies passées en paramètre, et tente de fourguer chaque symbole dans l'exécutable en cours de compilation. Inconvénient, il faut parfois ajouter une librairie donnée plusieurs fois dans le cas de dépendances mutuelles complexes.

Un truc facile pour plomber n'importe quel link GCC, c'est de lui mettre en paramètre une librairie énorme (genre 400 Mo de librairie avec 10.000 symboles exportés) : la même chose ne gêne quasiment pas VS.
Réciproquement, sur VS, linker avec des centaines de toutes petites librairies exportant chacune un ou deux symboles (surtout si elles sont mises dans les premières sur la liste) plombe gravement le link, alors que GCC n'est pas trop gêné.

C'est AUSSI un des paramètres de lenteur de GCC, bien entendu : je ne vais pas non plus modifier la granularité de mes projets pour lui faire plaisir.

[screetch]

VS plus rapide que GCC, donc...

cest que la version windows. Sous linux le build est plus rapide que sous windows pour l'instant. (chez moi c'est 35 secondes sous windows et 27 sous linux, mais au boulot je n'ai pas linux).
GCC n'est pas non plus deux fois plus lent que visual studio dans ce cas.

Ben le tien est concluant, tu crois ? VS plus rapide que GCC sur ton test... Là, t'es à moins d'une minute de compilation, et sûrement sans liens complexes : tu crois que ça donne quoi avec vingt fois plus de fichiers à compiler, et des dizaines de librairies linkées ? Et ça donne quoi si tu effectues ton build VS avec SON système de build, et non pas un autre ?

Le systeme de build de visual studio n'est pas très performant car j'ai une machine multiproc (8 coeurs en tout) et des dépendances un peu linéare. Le buid sous visual studio prend environ 1m30 dans mon cas. De plus je n'utilise pas les memes options de compilation (fichiers masters en ligne de commande, fichier individuels sous visual pour le build incrémental plus rapide)

mais c'est globalement le comparatif le plus neutre; j'utilise le meme système de build et les mêmes paramètres, les options equivalentes sur les deux compilateurs, et sur tous les systemes d'exploitation supportés. Ce qui permet de faire plus un comparatif gcc/cl qu'un comparatif make/visual studio.

[3DArchi]

windows ou linux ?

Sous windows. Et je trouve cela cohérent avec l'explication du link donnée par Mac LAK. Mais, en fin de compte, ça ne m'empêche ni d'utiliser l'un ni d'utiliser l'autre. Ils ont chacun leurs avantages et leurs inconvénients. Au final, les temps de compilation n'ont aujourd'hui rien à voir avec ce qu'on pouvait avoir il y a une quinzaine d'année où sur des projets moins complexes qu'aujourd'hui, on pouvait atteindre la nuit entière pour un rebuild complet.

[Mac LAK]

GCC n'est pas non plus deux fois plus lent que visual studio dans ce cas.

Je t'ai parlé de compilation complète : l'obtention des exécutables finaux. Je me contrefiche des vitesses intermédiaires des outils, ce qui m'intéresse, c'est ce que je fournis au client, et ce ne sont pas des fichiers .OBJ / .o !

De plus, le test entre deux OS (voire machines...) différents est carrément un non-sens : je vais faire tourner VS sur une machine de monstre, GCC sous un Linux sur une machine poussive, et ça va donner quoi ? La comparaison est à faire sur la même machine, vu que pour ma part je tourne en cross-compilation impérativement.

Le systeme de build de visual studio n'est pas très performant car j'ai une machine multiproc (8 coeurs en tout) et des dépendances un peu linéare.

J'arrive jusqu'à une dizaine de compilations simultanées possibles de par mon arborescence des dépendances.

mais c'est globalement le comparatif le plus neutre; j'utilise le meme système de build et les mêmes paramètres, les options equivalentes sur les deux compilateurs, et sur tous les systemes d'exploitation supportés. Ce qui permet de faire plus un comparatif gcc/cl qu'un comparatif make/visual studio.

Non, il ne l'est pas, car tu n'as pas de projet capable de mettre à genoux ton compilateur, et suffisamment complexe pour mettre le système de build à genoux lui aussi.

Le résultat du compilateur lui-même n'a quasiment aucun intérêt, étant donné qu'il n'est pas exécutable. C'est la chaîne de développement complète qu'il est intéressant de tester, c'est à dire en incluant TOUTE la chaîne de compilation (préprocesseur, compilateur, librarian et linker).

[Lavock]

???? Je ne vois pas le rapport par contre. D'une part, je n'ai pas QUE des procs x86 à gérer, et d'autre part, la compilation sur machine native n'est pas envisageable de façon sérieuse : on doit impérativement utiliser des cross-compilateurs.

A par le Dotnet, Vs peut-il cross-compiler quoi que se soit ? Oserait-je, le cas échéant, noter une certaine contradiction ?

Et puis au passage, je suis pas trop d'accord avec toi sur la réalité économique. Y a toujours de quoi occupé un homme si la compilation est longue... Le code de sortie est un peu plus important AMHA (je me suis toujours demandé quelle compilateur faisait le mieux son boulot)...

Façon, débat stérile, aucun n'est vraiment meilleurs... On est tout de même bien obligé d'admettre que GCC à un rapport qualité/prix ultime oO. A "l'achat" en tout cas.

[screetch]

On est tout de même bien obligé d'admettre que GCC à un rapport qualité/prix ultime oO. A "l'achat" en tout cas.

je dirai infini.

[Médinoc]

Visual cross-compile pour de l'embarqué (smart devices, Windows Mobile) et pour Windows 64 bits.

[screetch]

MSVC cross compile pour ARM (Windows CE), Itanium, x64 (sur une machine x86 il est possible de produire un code 64 bits), PowerPC (XBOX, XBOX360)

[Lavock]

Et ben dis donc, ça c'est de la cross compilation... Je suppose que si je veux pas de WM je l'ai dans l'os ? Et qu'il me faut la version méga-intégral pour avoir le droit de "cross-compiler" sur du MS ? C'est moche ça quand même...

[screetch]

non le kit Windows CE est gratuit si ca t'amuse.