Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Compiler sur un OS différent


Sujet :

C++

  1. #1
    Membre averti Avatar de Seabirds
    Homme Profil pro
    Post-doctoral fellow
    Inscrit en
    avril 2015
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Post-doctoral fellow
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : avril 2015
    Messages : 271
    Points : 330
    Points
    330
    Par défaut Compiler sur un OS différent
    Bonjour à toutes et à tous!

    J'ai codé/bricolé une petite lib pendant ma thèse, que j'ai utilisé sur Ubuntu, et aujourd'hui on a collaboré avec une chercheuse du domaine qui code sur mac. Outre le sentiment fort agréable que le travail des trois ans de thèse va peut être pas partir de suite aux oubliettes ( ) , y'a quand même quelques spécificités du travail à plusieurs à prendre en compte. Notamment le changement d'OS... Bon je m'attendais à ce qu'on rencontre quelques bricoles évidemment, et heureusement dans l'ensemble ça a été vite réglé.

    Par contre j'avoue avoir été un peu surpris de voir la nature des problèmes, je m'attendais pas à des problèmes de cet ordre.

    Par exemple je déclarais ce constructeur par déplacement:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    class MyClass {
      MyClass(MyClass&& other) noexcept = default;
    };
    Ca passait sur mon système mais pas sur mac. J'ai pas dit que ça aurait du passer incognito jusque là: à vrai dire vous allez peut être brûler ce constructeur pour hérésie. Je dis juste que c'est étonnant de voir que le code qui passe sans souci chez A plante superbement chez B. Par contre ceci met tout le monde d'accord (je vais sans doute surprendre personne à part moi )

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    class MyClass {
      MyClass(MyClass&& other) = default;
    }
    Idem, j'avais oublié un #include<functional> quelque part: ça passait crème chez moi, et ça plantait chez l'autre. Comment ça se fait que ce soit passé inaperçu alors qu'on a compilé exactement le même code de tests unitaires ?

    Bref, au final c'est assez ironique, j'ai perdu beaucoup de temps à débugger ça parce que justement je pensais pas qu'un code qui compile quelque part puisse être en fait blindé de problèmes. Ca m'a rappeler le temps perdu il y a un an à chercher une erreur au mauvais endroit parce que je partais du principe que mes tests étaient exhaustifs: ce matin je partais du principe que le compilateur de mon système avait déjà trouvé tous les défauts de mon code.

    C'est ce genre de trucs auquel il faut s'attendre à l'avenir quand on va essayer de coder des truc Linux-mac compatibles ? Ou bien ça c'était juste le côté pâte-à-choux et y'a des truc horribles qui vont nous tomber sur les dents ?

    PS: on le dit jamais assez mais vivent les batteries de tests unitaires
    PPS: il faut vraiment que j'assainisse cette batterie de tests unitaires
    PPS: encore merci à vous tous d'avoir insister pour que je fasse des tests unitaires
    Le débutant, lui, ignore qu'il ignore à ce point, il est fier de ses premiers succès, bien plus qu'il n'est conscient de l'étendue de ce qu'il ne sait pas, dès qu'il progresse en revanche, dès que s'accroît ce qu'il sait, il commence à saisir tout ce qui manque encore à son savoir. Qui sait peu ignore aussi très peu. [Roger Pol-Droit]
    Github
    Mon tout premier projet: une bibliothèque de simulation de génétique des populations

  2. #2
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    ...
    Inscrit en
    juin 2009
    Messages
    4 295
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : ...

    Informations forums :
    Inscription : juin 2009
    Messages : 4 295
    Points : 12 906
    Points
    12 906
    Billets dans le blog
    1
    Par défaut
    Salut,

    Ça fait 2 ans que je travaille sur des projets pour micro-contrôleur (MCU) pour lesquelles une grosse partie du code est compilé sur PC pour faire des tests unitaires. Et franchement tu trouves souvent des choses qui clochent entre les deux. En ce moment, c'est du GCC sur MCU et sur PC, les deux cibles sont des processeurs 32 bits, et pourtant on a des différences. Notamment le fait que std::(u)int32_t soit un alias pour (unsigned) int d'un côté et (unsigned) long de l'autre. Ce qu'il faut retenir c'est que quand tu changes de cible (processeur + OS + compilateur), il faut s'attendre à des différences. Ce sont des options qui ne sont pas toujours exactement les mêmes (ou qui des fois n'ont pas d'équivalents directs), des bibliothèques standards qui ne sont pas implémentées de la même manière (c'est là que ton histoire de header non inclus peut arriver ; des fois ça donne des trucs assez relou), ton code qui utilisent des undefined behaviors ou implementation-defined behaviors, ton code qui contient des bugs qui ne s'étaient pas encore exprimés jusque là, des compilateurs avec des bugs(oui ça existe) ou des comportements assez étranges ou des comportements pas toujours exactement collés à la norme. La norme des fois laisse aussi des latitudes qui peuvent amener des choses funs (comme par exemple le fait que dans <cstdio>, tu puisses avoir ou pas printf() dans le namespace global ou pas).

    Bref, les problèmes t'attendent au tournant.

    Les tests unitaires te permettent effectivement d'avoir une référence pour exécuter ton code sur une nouvelle plateforme. Il faut pas oublier pour autant que ce n'est pas une méthode complète de validation de code. En vrac, faire lire son code à des gens, relire soi-même son code, se reposer sur son compilateur réglé en mode paranoïaque et des outils comme valgrind ;)

  3. #3
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 197
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 6 197
    Points : 28 099
    Points
    28 099
    Billets dans le blog
    2
    Par défaut
    - la compilation n'est pas propre a l'OS mais a la chaine de compilation (qui varie d'un OS a l'autre, mais au sein d'un meme OS egalement)
    - toutes les implementations ne sont pas strictement identiques

    Apres, ca c'est le niveau 0 de la portabilite. D'autres problemes peuvent survenir
    - implementation manquante
    - comportements differents avec les memes appels
    - devoir rearchitecturer certains pans parce qu'une plateforme propose qu'une API asynchrone
    - bug de compilateur sur une plateforme donnee
    la liste continue et s'etoffe au fur et mesure des experiences
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  4. #4
    Membre expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 895
    Points : 3 842
    Points
    3 842
    Par défaut
    Complètement d'accord avec Bousk. Sur Ubuntu, tu as une toolchain GCC par défaut alors que sur Mac c'est du Clang. Les options de compilation et les includes par défaut ne sont pas les mêmes, et j'imagine que c'est encore différent sur windows/msvc.
    Pour résoudre ce genre de problème, il faut essayer de respecter les normes au maximum et surtout tester la compilation sur les différentes toolchains. Tester toutes les toolchains à la main sur sa machine est plutôt difficile. Une meilleure solution est de mettre en place de l'intégration continue avec TravisCI, Appveyor, Gitlab-CI ou autres.

  5. #5
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2007
    Messages
    5 143
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : juin 2007
    Messages : 5 143
    Points : 16 942
    Points
    16 942
    Par défaut
    Et aussi étudier les réglages de la chaine de compilation.
    Il y a souvent une option pour choisir la norme à utiliser, mais elle n'est pas la même pour tous les compilateurs.

    Il peut aussi y avoir des différences entre les versions d'un même compilateur.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  6. #6
    Membre averti Avatar de Seabirds
    Homme Profil pro
    Post-doctoral fellow
    Inscrit en
    avril 2015
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Post-doctoral fellow
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : avril 2015
    Messages : 271
    Points : 330
    Points
    330
    Par défaut
    Merci de vos réponses

    Citation Envoyé par Bousk Voir le message
    - la compilation n'est pas propre a l'OS mais a la chaine de compilation (qui varie d'un OS a l'autre, mais au sein d'un meme OS egalement)
    la liste continue et s'etoffe au fur et mesure des experiences
    Hum oui c'est bien là le souci: l'expérience ... seabirds apt-get update experience
    Citation Envoyé par SimonDecoline
    Tester toutes les toolchains à la main sur sa machine est plutôt difficile. Une meilleure solution est de mettre en place de l'intégration continue avec TravisCI, Appveyor, Gitlab-CI ou autres.
    Mhh ok depuis quelques mois déjà je sentais venir le moment où mes scripts bash lancés à la main pour les tests allait atteindre une limite. J'ai jeté un coup d'oeil à TravisCI, et j'avoue que je n'arrive pas à savoir si c'est overkill, ou si je peux facilement le mettre en place. Je vais regarder d'un peu plus près merci. Pour l'instant, j'ai une solution faite à la main un peu dégueu ou des scripts bash s'appellent en cascade à travers les différents modules de la lib pour compiler/exécuter des fichiers de tests. Franchement à une époque j'étais assez fier du service rendu à ma communauté de 1 personne, mais là ça me saoule assez clairement, notamment parce que:
    • le nombre de scripts bash explose ces derniers temps, puis c'est relou à écrire.
    • que ces tests mélangent un peu deux buts à la fois: i) fournir un code simple et fonctionnel d'exemple d'utilisation pour la classe, et ii) tester le code avec des asserts un peu dégueu. Du coup je fais un compromis et au final c'est pas super rigoureux.
    • que ma collabratrice a tout un pan des tests qui marchent pas à cause d'une option -I écrite en dur dans la commande de compilation des scripts bash.

    Moui en écrivant ces lignes ça devient assez évident qu'il faut changer ça

    Citation Envoyé par Bktero
    son compilateur réglé en mode paranoïaque
    g++ -o UTest -Wall -std=c++17 test.cpp c'est assez paranoïaque ?

    Ternel: Les réglages de la chaîne de compilation... Je vais chercher ça merci
    Le débutant, lui, ignore qu'il ignore à ce point, il est fier de ses premiers succès, bien plus qu'il n'est conscient de l'étendue de ce qu'il ne sait pas, dès qu'il progresse en revanche, dès que s'accroît ce qu'il sait, il commence à saisir tout ce qui manque encore à son savoir. Qui sait peu ignore aussi très peu. [Roger Pol-Droit]
    Github
    Mon tout premier projet: une bibliothèque de simulation de génétique des populations

  7. #7
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    ...
    Inscrit en
    juin 2009
    Messages
    4 295
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : ...

    Informations forums :
    Inscription : juin 2009
    Messages : 4 295
    Points : 12 906
    Points
    12 906
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Seabirds Voir le message
    g++ -o UTest -Wall -std=c++17 test.cpp c'est assez paranoïaque ?
    Euh non ça c'est le minimum vital

    En ce moment je compile avec ça :
    -pedantic
    -Wall
    -Wextra

    -Wsuggest-override

    -Wold-style-cast
    -Wuseless-cast

    -Wdouble-promotion

    -Wmissing-declarations
    -Wshadow=compatible-local

    -Wswitch-default
    -Wswitch-enum
    Si tu veux vraiment te faire mal, regarde ce dépôt Github qui te donne des listes d'options pour différents compilateurs https://github.com/jonathanpoelen/cpp-compiler-options Au hasard (presque), utilise cette gcc-8.0-warnings_strict:
    -pedantic
    -pedantic-errors
    -Wall
    -Wextra
    -Wcast-align
    -Wcast-qual
    -Wdisabled-optimization
    -Wfloat-equal
    -Wformat-security
    -Wformat-signedness
    -Wformat=2
    -Wmissing-declarations
    -Wmissing-include-dirs
    -Wnon-virtual-dtor
    -Wold-style-cast
    -Woverloaded-virtual
    -Wpacked
    -Wredundant-decls
    -Wundef
    -Wuninitialized
    -Wunused-macros
    -Wvla
    -Wconversion
    -Wswitch-default
    -Wswitch-enum
    -Wsuggest-attribute=noreturn
    -Wzero-as-null-pointer-constant
    -Wlogical-op
    -Wvector-operation-performance
    -Wdouble-promotion
    -Wtrampolines
    -Wuseless-cast
    -Wconditionally-supported
    -Wfloat-conversion
    -Wopenmp-simd
    -fsized-deallocation
    -Warray-bounds=2
    -Wconditionally-supported
    -Wnoexcept
    -Wsized-deallocation
    -Wstrict-null-sentinel
    -Wsuggest-override
    -Wduplicated-cond
    -Wnull-dereference
    -Waligned-new
    -Walloc-zero
    -Walloca
    -Wformat-overflow
    -Wshadow=compatible-local
    -Wclass-memaccess
    -Wsign-conversion
    -Wcast-align=strict

  8. #8
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 037
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 037
    Points : 4 438
    Points
    4 438
    Par défaut
    Bonjour,

    Je rejoins Bktero : il faut plus d'avertissements que -Wall.

    En fait, le nom -Wall est trompeur, car il n'active pas tous les avertissements.
    D'ailleurs, avec GCC, il n'est pas souhaitable d'activer tous les avertissements qui existent car, par exemple, il existe même -Wtemplates qui râle quand on déclare un template et -Wnamespaces qui râle quand on écrit du code dans un espace de nom !

    Avec GCC, je conseille d'utiliser au moins -Wall -Wextra -pedantic-errors ainsi que -Winvalid-pch si tu as des entêtes précompilés.

    Personnellement, j'utilise :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    -Wall -Wextra -pedantic-errors -Winvalid-pch -Wshadow -Weffc++
    -Wold-style-cast -Wconversion -Woverloaded-virtual -Wpointer-arith
    -Wzero-as-null-pointer-constant -Winit-self -Wredundant-decls -Wcast-align
    -Wfloat-equal -Wunreachable-code -Wmissing-include-dirs
    Cela dit, l'inconvénient des listes d'avertissements à rallonge comme la mienne, c'est que, quand on inclut des entêtes codés par d'autres personnes, on se ramasse plein d'avertissements dans la tronche. Par exemple, voici un extrait d'un de mes codes, simplement pour inclure un entête de Boost :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #pragma GCC diagnostic push
    #pragma GCC diagnostic ignored "-Weffc++"
    #pragma GCC diagnostic ignored "-Wold-style-cast"
    #pragma GCC diagnostic ignored "-Woverloaded-virtual"
    #pragma GCC diagnostic ignored "-Wzero-as-null-pointer-constant"
    # include <boost/test/unit_test.hpp>
    #pragma GCC diagnostic pop

  9. #9
    Membre averti Avatar de Seabirds
    Homme Profil pro
    Post-doctoral fellow
    Inscrit en
    avril 2015
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Post-doctoral fellow
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : avril 2015
    Messages : 271
    Points : 330
    Points
    330
    Par défaut
    Aouch la claque. Ok donc le -Wall c’était le verre d'eau qui cache l'incendie de foret.

    Bon, la conclusion de l'affaire c'est que je sais meme pas compiler un code. C'est fantastique, on apprend chaque jour.

    Bon allez "hackeur vaillant, rien d'impossible", on retrousse les manches hop hop hop

    Merci encore de vos conseils !
    Le débutant, lui, ignore qu'il ignore à ce point, il est fier de ses premiers succès, bien plus qu'il n'est conscient de l'étendue de ce qu'il ne sait pas, dès qu'il progresse en revanche, dès que s'accroît ce qu'il sait, il commence à saisir tout ce qui manque encore à son savoir. Qui sait peu ignore aussi très peu. [Roger Pol-Droit]
    Github
    Mon tout premier projet: une bibliothèque de simulation de génétique des populations

  10. #10
    Membre expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 895
    Points : 3 842
    Points
    3 842
    Par défaut
    Citation Envoyé par Seabirds Voir le message
    Mhh ok depuis quelques mois déjà je sentais venir le moment où mes scripts bash lancés à la main pour les tests allait atteindre une limite.
    J'aime beaucoup le bash mais pour compiler/tester un projet, ça ne me semble plus trop adapté aujourd'hui. Tu ne peux pas faire tes tests via le système de build + tests unitaires (genre cmake + google-test) ?

  11. #11
    Membre averti Avatar de Seabirds
    Homme Profil pro
    Post-doctoral fellow
    Inscrit en
    avril 2015
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Post-doctoral fellow
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : avril 2015
    Messages : 271
    Points : 330
    Points
    330
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Tu ne peux pas faire tes tests via le système de build + tests unitaires (genre cmake + google-test) ?
    Bonne question. Je ne fais jamais de cmake parce que ma lib c'est juste un petit paquet de headers a inclure dans le main.cpp , que je compile a la main.

    Comme tout est template, j'ai des petits fichiers de tests du genre:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    // Compiles with g++ -o test merger_test.cpp -std=c++14 -Wall
     
    #include "../../merger.h" // le code a "tester"
     
    //! [Example]
     
    #include <vector>
    #include <list>
    #include <string>
    #include <algorithm>
    #include <iostream>
    #include <iterator>
    #include <random>
    #include <cassert>
     
    int main () {
     
      using node_type = std::string;
      using quetzal::coalescence::occupancy_spectrum::on_the_fly;
      using SMM = quetzal::coalescence::SimultaneousMultipleMerger<on_the_fly> ;
     
      std::vector<node_type> nodes = {"a", "b", "c", "d"};
     
      unsigned int N = 3;
     
      std::mt19937 gen;
     
      std::cout << "\nNodes at sampling time :\n";
      std::copy(nodes.begin(), nodes.end(), std::ostream_iterator<node_type>(std::cout, "\n"));
      std::cout << "\n";
     
      auto last = SMM::merge(nodes.begin(), nodes.end(), N, gen);
     
      std::cout << "\nAfter one simultaneous multiple merge generation:\n";
      for(auto it = nodes.begin(); it != last; ++it){
        std::cout << *it << std::endl;
      }
     
      return 0;
    }
     
    //! [Example]
    Un ficher bash compile, l’exécute, enregistre l'output. L'output et le code source sont récupérés par Doxygen.

    On est bien d'accord que c'est assez éloigné du test unitaire idéal et c'est sans doute crado, mais bon, ça m'a jusque la permis a moindre coût de tester des modules indépendamment les uns des autres tout en pouvant retourner dans la doc voir comment utiliser telle ou telle classe, tout en me permettant de tester tous les modules avec un petit ./run_all_tests avant de merger mes betises sur la branche master du depot git.

    Ma nature paranoïaque (pas encore assez pour le compilo semble-t-il) m’encourage a mettre des asserts partout et a vérifier chaque fonction, et les attendus statistiques des simulations, ce que j'ai fait dans certains cas qui fleurait bon le casse-gueule, mais pas partout non plus parce que [ironie]des tests unitaires complets c'est un luxe que je ne peux pas me permettre et puis ça ruinerait la doc [/ironie].

    Voila pour ce que j'ai fait, mais je ne sais pas comment j'aurais du procéder au mieux. Ce qui est certain c'est que aujourd'hui ce bricolage ne tient plus bien la route. La petite ligne de compilation me semblait tellement minimaliste qu'utiliser Cmake pour ça me paraissait un peu accablant en comparaison.
    Le débutant, lui, ignore qu'il ignore à ce point, il est fier de ses premiers succès, bien plus qu'il n'est conscient de l'étendue de ce qu'il ne sait pas, dès qu'il progresse en revanche, dès que s'accroît ce qu'il sait, il commence à saisir tout ce qui manque encore à son savoir. Qui sait peu ignore aussi très peu. [Roger Pol-Droit]
    Github
    Mon tout premier projet: une bibliothèque de simulation de génétique des populations

  12. #12
    Membre expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2011
    Messages
    622
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : juin 2011
    Messages : 622
    Points : 3 039
    Points
    3 039
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Cela dit, l'inconvénient des listes d'avertissements à rallonge comme la mienne, c'est que, quand on inclut des entêtes codés par d'autres personnes, on se ramasse plein d'avertissements dans la tronche. [...]
    Seulement si les paths sont ajoutés avec -I. Avec -isystem, il n'y a pas d'avertissement. Mais c'est vrai que je fais pareil sur un fichier complet lorsque je suis obligé de passer par des macros C qui sont garnis de cast et pointeur initialisé avec 0.

    @Seabirds: L'avantage des systèmes de build, c'est qu'ils sont prévus pour fonctionner sur plusieurs environnements ce qui permet de changer les options et le compilateur assez facilement, ce qui est beaucoup plus souple qu'un script bash avec des valeurs en dures qui mélangent configuration et cible. Il y a aussi un vrai système de dépendance qui permet de ne compiler que le nécessaire comme une cible précise ou les tests impactés par la modification d'un fichier X (même si je trouve ctest une catastrophe sur ce point).

    Un framework de test est aussi beaucoup plus souple qu'une comparaison d'output. Il possède divers macro de comparaison de valeur (égalité, infériorité, etc) ce qui permet d'avoir très tôt les erreurs avec un affichage beaucoup plus pratique qu'un diff. J'imagine mal comment vérifier qu'une valeur est différente d'une autre avec une comparaison d'output. Après il y a plus ou moins de chose comme la vérification d'exception, la séparation en scénario, plein d'options sur la manière de lancer les tests, etc. Clairement, c'est un investissement qui vaut le coup.

  13. #13
    Membre averti Avatar de Seabirds
    Homme Profil pro
    Post-doctoral fellow
    Inscrit en
    avril 2015
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Post-doctoral fellow
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : avril 2015
    Messages : 271
    Points : 330
    Points
    330
    Par défaut
    Citation Envoyé par jo_link_noir Voir le message
    L'avantage des systèmes de build, c'est qu'ils sont prévus pour fonctionner sur plusieurs environnements ce qui permet de changer les options et le compilateur assez facilement, ce qui est beaucoup plus souple qu'un script bash avec des valeurs en dures qui mélangent configuration et cible.
    Capito.

    Citation Envoyé par jo_link_noir Voir le message
    Un framework de test est aussi beaucoup plus souple qu'une comparaison d'output.
    Beaucoup plus rigoureux aussi, la j'en étais plutôt au stade du "si déjà tous ces fichiers compilent et tournent sans casser les 223 assertions éparpillées ici et la dans le code alors c'est déjà encourageant". Le saint-graal c'est si en plus avec ces miettes de code pas très bien testées je peux me dépêcher d'écrire un programme pas garanti très correct dont la valeur de sortie converge vers la vraie valeur attendue et publier un article sur ma méthode stat très intelligente avant ma soutenance (sur ce point par contre c'est un échec)

    Citation Envoyé par jo_link_noir Voir le message
    Il possède divers macro de comparaison de valeur (égalité, infériorité, etc) ce qui permet d'avoir très tôt les erreurs avec un affichage beaucoup plus pratique qu'un diff.
    Oui c'est ce que j'avais commence a faire avec Boost test. D'ailleurs, mon défaut avait été de tester trop de trucs et pas forcement les plus pertinents.

    Citation Envoyé par jo_link_noir Voir le message
    J'imagine mal comment vérifier qu'une valeur est différente d'une autre avec une comparaison d'output.
    A vrai dire je ne compare mes output a rien. Histoire de définitivement perdre en crédibilité il y a même une ou deux section "output" de la doc qui sont vide parce que le code de "test" a planter quelque part...

    Citation Envoyé par jo_link_noir Voir le message
    Clairement, c'est un investissement qui vaut le coup.
    Maintenant oui, clairement Mais il y a 1-2 ans, perdu au large de ma thèse sur mon rafiot de code en pleine tempête, bah j'ai fait des compromis et j'ai pas vérifié que mon compas pointait le Nord

    Donc si je résume bien...

    • Ce que j'ai pour l'instant ressemble plutôt a un ensemble de codes d'illustration pour la doc. Dans l'esprit j'ai voulu faire un peu ce qu'on trouve dans la partie Example de cppreference.com: ça teste rien mais y'a garantie que "ça tourne" et ça illustre super bien l'utilisation de la classe (wah d'ailleurs y'a une option "run this code" que j'avais jamais vu!)
    • J'aimerai retourner dans le framework de test de boost pour pouvoir me lâcher sur des tests unitaires plus rigoureux
    • Et je commence a avoir besoin de tests d’intégrations parce que c'est quand même bien pratique de vérifier que le module A parle bien au module B
    • Et j'ai besoin que tout ce joli monde puisse tourner sur différents OS.


    Si j'ai bien lu entre les lignes de vos réponses, c'est que tout ça c'est faisable/préférable avec un framework de tests. Et que même ce framework de test aura besoin d'un système de build comme CMake, parce que c'est a ce point la que ce fait l'interface avec les différents environnements.

    Si oui, bah y'a un peu de boulot ahah
    Le débutant, lui, ignore qu'il ignore à ce point, il est fier de ses premiers succès, bien plus qu'il n'est conscient de l'étendue de ce qu'il ne sait pas, dès qu'il progresse en revanche, dès que s'accroît ce qu'il sait, il commence à saisir tout ce qui manque encore à son savoir. Qui sait peu ignore aussi très peu. [Roger Pol-Droit]
    Github
    Mon tout premier projet: une bibliothèque de simulation de génétique des populations

  14. #14
    Membre expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 895
    Points : 3 842
    Points
    3 842
    Par défaut
    @Seabirds: je confirme tout à fait ce que dit jo_link_noir. De plus, cmake s'interface assez bien avec doxygen et avec les systèmes de tests unitaires. Un autre avantage est que c'est facile de réutiliser un projet cmake dans un autre projet cmake. Et si tes projets sont dans des dépôts git, tu peux les intégrer via des sous-modules et c'est très pratique.

  15. #15
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    ...
    Inscrit en
    juin 2009
    Messages
    4 295
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : ...

    Informations forums :
    Inscription : juin 2009
    Messages : 4 295
    Points : 12 906
    Points
    12 906
    Billets dans le blog
    1
    Par défaut
    Je valide le couple CMake + Google Test !

    Et je valide aussi totalement -isystem à la place / en complément de -I !

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Delphi 7 update 1 - Erreur de compil sur SQLExpr
    Par RamDevTeam dans le forum Bases de données
    Réponses: 14
    Dernier message: 02/11/2005, 18h44
  2. Même liste sur 26 pages différentes
    Par krfa1 dans le forum Balisage (X)HTML et validation W3C
    Réponses: 8
    Dernier message: 18/03/2005, 12h32
  3. [CR7] état sur un disque différent du crystal web serv
    Par shadowR dans le forum SAP Crystal Reports
    Réponses: 10
    Dernier message: 23/12/2004, 16h44
  4. Somme de 3 COUNT() sur 3 tables différentes
    Par PyRoFlo dans le forum Langage SQL
    Réponses: 9
    Dernier message: 13/08/2004, 19h36
  5. [Eclipse][Java]Problème de compilation sur CTRL+S
    Par ZeKiD dans le forum Eclipse Java
    Réponses: 5
    Dernier message: 27/05/2004, 12h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo