Salut les gens,

Je vais devoir faire des paquets pour une lib c++ qui est mi template header, mi objet statique.
Je vais avoir besoin de deployer ca sur plusieurs OS (macos, linux, windows), et potentiellement plusieurs architecture (x86, amd64, et peut etre de l'arm aussi).

Naturellement ce que je fais a des dependances externes que je peux compiler de facon differente. Typiquement les dependences externs font du cmake.

Vous avez des idees de ce que je devrais lire ou faire pour que ca se bien?

Merci!

Deuxieme question puisque la premiere a ete tres populaire:

J'ai une tonne de fichiers .o.
Je voudrais creer une lib dynamique qui n'expose que quelques fonctions qui sont dans les .o et que toutes les autres fonctions et symbols soient purement internes et ne soit pas exposes le but etant que je ne veux pas faire de conflit avec d'autres lib dynamique qui pourrait offrir des symbols du meme noms.
On fait ca comment ?

Disons avec les toolchain clang et/ou gcc.

Merci!

J'avais déjà répondu à un topic similaire mais l'idée n'a vraisemblablement pas été retenue.
Faire de l'intégration continue avec Gitlab n'est pas envisageable?

Versionner le code avec Git.
Créer un fichier gitlab-cli à la racine qui va contenir les instructions pour la compilation, le lancement des tests de non régressions, le "packaging" et le stockage des exécutables sur une plateforme d'archivage.

Pour cela il te faudra soit un service gitlab que tu héberges, soit utiliser la plateforme gitlab.com qui sera payante au dela d'un certain nombre de pipelines (exécution du gitlab-cli lors de chaque push) .

Tu devras probablement créer des runners (1 par environnement sur lequel tu souhaites déployer tes exécutables). J'aurais du mal à définir ce que sont ces runners, mais il faut voir ça comme un conteneur où tu exécutes des actions.

L'utilisation de pipeline avec différents runners est à étudier car je n'ai encore jamais vu d'utilisation de ces outils pour l'intégration continue sur plusieurs environnements (mais ça semble possible).

Concernant la seconde question, aucune idée!!!

github ne change pas grand chose a la question. Le pipeline github n'est pas automagique, il fait un truc en particulier. Et pour comprendre si le bousin est bien configure il faut comprendre comment ca marche pour commencer.

Il y a des questions de dependance auquel il faut repondre de facon precise. Est ce que le mangling est defini de facon unique sur les different compilateur open source, ou est ce que clang et gcc noment les choses differement. Est ce que la question de mangling disparait si on fait une interface C au lieu d'une interface C++?

Quand est il de compiler pour windows, est ce qu'un seul paquet est suffisant, ou est ce qu'il faut une version par compilateur. Un collegue m'a dit ce matin que peut etre il faut une version par compilateur et option release/debug et sequentiel/multithread.

Qu'en est il des interactions avec libstdc++? Est ce qu'il faut compiler pour differente libstdc++? Ou est ce que c'est possible de compiler contre une vielle version et de laisser la compatibilite de la lib faire le reste? Est ce que c'est un des cas ou j'ai envie de linker statiquement contre libstdc++ et d'exposer mon interface manuellement pour m'assurer que les symbol de libstdc++ de ma lib ne viennent pas polluer l'espace de l'applicatin qui va linker contre ma lib?

Quid de macos? Est ce qu'il faut recompiler pour chaque mineur de l'OS? ou est ce que compiler pour macosX amd64 suffit?

Quelques reponses pour linux semblent etre dans: https://akkadia.org/drepper/dsohowto.pdf
Quelques reponses pour windows semblent etre dans: https://www.youtube.com/watch?v=JPQWQfDhICA

Quand on a des contraintes aussi fortes le C++ c'est peut être pas la meilleur idée

J'ai pas vraiment compris ce que tu voulais faire, mais le plus simple, c'est de recompiler dans chaque environnement séparément. C'est le plus bête mais au moins t'as pas à gérer plein de versions différentes de librairies.

C'est ce que je fais personnellement.

Mais j'essaye d'eviter ca pour les utilisateur. Le but est de distribuer ca a des etudiants en premiere annee de fac, voir meme au lycee ou college.

Le 10 juillet 2019 à 21:11:53 godrik a écrit :
github ne change pas grand chose a la question. Le pipeline github n'est pas automagique, il fait un truc en particulier. Et pour comprendre si le bousin est bien configure il faut comprendre comment ca marche pour commencer.

Il y a des questions de dependance auquel il faut repondre de facon precise. Est ce que le mangling est defini de facon unique sur les different compilateur open source, ou est ce que clang et gcc noment les choses differement. Est ce que la question de mangling disparait si on fait une interface C au lieu d'une interface C++?

Quand est il de compiler pour windows, est ce qu'un seul paquet est suffisant, ou est ce qu'il faut une version par compilateur. Un collegue m'a dit ce matin que peut etre il faut une version par compilateur et option release/debug et sequentiel/multithread.

Qu'en est il des interactions avec libstdc++? Est ce qu'il faut compiler pour differente libstdc++? Ou est ce que c'est possible de compiler contre une vielle version et de laisser la compatibilite de la lib faire le reste? Est ce que c'est un des cas ou j'ai envie de linker statiquement contre libstdc++ et d'exposer mon interface manuellement pour m'assurer que les symbol de libstdc++ de ma lib ne viennent pas polluer l'espace de l'applicatin qui va linker contre ma lib?

Quid de macos? Est ce qu'il faut recompiler pour chaque mineur de l'OS? ou est ce que compiler pour macosX amd64 suffit?

Quelques reponses pour linux semblent etre dans: https://akkadia.org/drepper/dsohowto.pdf
Quelques reponses pour windows semblent etre dans: https://www.youtube.com/watch?v=JPQWQfDhICA

Je n'en ai aucune idée car je ne maîtrise pas le c++, je proposais seulement une solution pour automatiser la génération de paquets pour différents environnements (sans prendre en compte la techno, et oui ce n'est pas magique, il est nécessaire de définir les actions à mettre en place).
Mais ce que tu souhaites nécessite pas mal de temps (apprentissage/étude de la faisabilité + mise en place) et éventuellement pas mal de ressources. Mais si ta problématique concerne le milieu scolaire, il vaut peut être mieux donner simplement les étapes de compilation aux étudiants en fonction de leur environnement

C'est assez compliqué de l'expliquer en quelques lignes sur un forum mais l'idée est plutôt simple (on va limiter aux cas windows et linux 32 bits pour illustrer mon idée).

Mise en place d'un projet sous git hébergé sous gitlab (local ou en ligne).
Chaque nouveau commit va lancer un pipeline (instructions décrites dans le fichier à la racine gitlab-cli).
Chaque pipeline sera exécuté sur un runner windows 32b et un linux 32b.
Pour chaque runner, tu vas simplement spécifier ce que tu ferais manuellement sur ta machine en shell et windows batch pour compiler et déposer tes paquets sur une plateforme d'échange: https://docs.gitlab.com/runner/ --> il semble être possible d'avoir des runners différents (je pensais au départ que c'était du docker derrière, et donc full linux).

Mais je conçois que cette solution n'est pas forcément viable: il faudrait je pense une machine par runner (1 windows 32b 1 windows 64b,...).
La montée en compétence pour l'intégration continue n'est pas si compliquée mais elle nécessite effectivement un peu de temps (surtout pour ton cas qui est un peut particulier).

C'est ce qui ce fait de plus en plus dans les sociétés informatiques pour automatiser les process, sauf qu'en général, on génère des paquets pour un environnement spécifique.
Sinon je ne vois pas vraiment d'autre solutions pour le faire.

Nan c'est sur que c'est la bonne infrastructure pour faire ca. Mais la question est de savoir quelles configurations il faut genere et quels sont les compromis dans les options qui sont disponible.

Le temps et les resources ce n'est pas vraiment un probleme. On est 8 a bosser sur le projet d'une facon ou d'une autre, on a encore deux ans de financement devant nous.

On ne peut pas faire compiler le soft aux etudiants, c'est beaucoup trop complique. Si tu veux deployer ca dans un cours avec des gamins de 12 ans, il faut que l'installation soit en moins de 5 minutes. Le checkout des lib et la compilation sur ma machine, ca prends 10 minutes. (Punaise c'est lourd boost.)

En fin de compte, je pense qu'on va finir par faire ca par essai/erreur et les quelques premieres session serviront de pot casse...

On devrait pour facilement installer ca sur cloud 9 avec une trentaine de compte preconfigure et utiliser ca en option de secours si le deployement ce passe mal.

En tout cas on s'amuse bien chez les enseignants!!
Le sujet est complexe mais j'aurais bien aimé rencontrer ce genre de problématique dans mon milieu pro.

Il n'est effectivement pas envisageable de donner les instructions de compilation s'il s'agit de collégiens : meilleur moyen pour les dégoûter de faire de l'informatique.

J'ai cherché un peu et ça semble largement envisageable si vous avez les ressources humaines et le le budget.
Exemple de topic relatif à la question, la personne souhaitant compiler sur OSX et Windows: https://gitlab.com/gitlab-org/gitlab-runner/issues/3153

Un lien fourni dans une des réponses redirigeant vers la doc : https://docs.gitlab.com/com/ce/ci/yaml/README.html#tags

windows job:
  stage:
    - build
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

osx job:
  stage:
    - build
  tags:
    - osx
  script:
    - echo "Hello, $USER!"

Je n'ai jamais utilisé les tags, mais j'imagine que ça fait référence à un runner particulier (à confirmer).

Et juste pour l'exemple (ce fichier de configuration est construit différemment de l'exemple fourni ci-dessus), voila à quoi ressemble un fichier de conf ultra simple: pas de déploiement ni d'archivage, seulement de la compilation et lancement de tests avant de merger pour un projet java.

image: maven:3.6.0-jdk-11-slim

services:
  - postgres:11.2

variables:
  POSTGRES_DB: dbname
  POSTGRES_USER: dbuser
  POSTGRES_PASSWORD: "dbpassword"

before_script:
  - apt-get clean && apt-get update && apt-get install -y locales
  - echo "fr_FR UTF-8" > /etc/locale.gen
  - locale-gen fr_FR.UTF-8
  - export LANG=fr_FR.UTF-8
  - export LANGUAGE=fr_FR:en
  - export LC_ALL=fr_FR.UTF-8
  - cd back

stages:
  - build

build:
  stage: build
  script: mvn clean package -DargLine="-Dspring.profiles.active=ci"

images : j'indique que je souhaite un runner contenant maven et un jdk11 (fourni par la communauté gitlab)
services et variables : définition d'une bd postgresql pour les tests
before_script: définition de la locale fr nécessaire car déploiement sur un serveur dont la "locale" est France.
stages et build: je n'ai qu'une seule étape qui est la compilation et le lancement des tests via maven

Dans mon exemple, il faut créer une merge request sous gitlab. Si les tests passent et que j'ai choisit "merge when pipeline succeed", ce sera merge automatiquement, sinon je serai avertit.