DEV Community: Mr. VyM

Tester c'est tricher, compiler c'est douter

Mr. VyM — Fri, 10 Jan 2025 13:42:59 +0000

Dans cet article, nous allons voir le concept de Continuous Integration (CI), son intérêt et ses inconvénients et une démonstration.

Histoire

Mais d'abord, comme à mon habitude, un petit point histoire.

En 1999, Kent Beck a approfondi le sujet dans son premier livre sur l'Extreme Programming. En 2001, CruiseControl, l'un des premiers outils open-source de CI, a vu le jour.

Mais why ?

Le but d'une CI est de faire des tests automatisés à chaque commit. Cela garantit que le code reste fonctionnel en permanence. On appelle cela une Continuous Integration car, à chaque modification, le code est vérifié pour s'assurer qu'il n'y a pas de régressions.

Avantages

Détection précoce des erreurs : Les problèmes sont identifiés rapidement, ce qui permet de réagir sans attendre.
Amélioration de la qualité : En testant systématiquement, on garantit un code plus robuste.
Gain de temps : Les pipelines automatisés réduisent la nécessité de tests manuels répétitifs.

Inconvénients

Coût initial : Mettre en place une CI peut demander des efforts et des compétences initiales importantes.
Temps d’exécution : Les pipelines complexes peuvent rallonger le temps avant qu'un développeur puisse valider son code.

Fonctionnement

Avant de voir le fonctionnement, un petit lexique :

Jobs : Une instance d'un conteneur (souvent Docker) qui exécute un script. Cela peut inclure des commandes, des tests ou des actions simples comme un echo.
Pipeline : Une série de jobs organisés de manière séquentielle ou parallèle. Chaque commit déclenche cette série pour valider les changements.

Le principe est simple : chaque job retourne un code de statut (succès ou échec). Si un job échoue, la pipeline s’arrête ou ignore les étapes suivantes selon la configuration.

Trêve de blabla

Nous allons utiliser un exemple basé sur GitLab CI. On la configure via un fichier .gitlab-ci.yml.

Basique, simple, simple, basique

image: bookworm-slim:latest

myjobname:
  script:
    - make

Les flags

Pour ajouter des flags de compilation, deux approches sont possibles :

Via une règle dans le Makefile.
En passant les flags directement dans la commande CI.

myjobname_hard:
  script:
    - CFLAGS="-Wall -Werror" make
    # ou
    - make compile_flags

Tests avec Criterion et flags

Criterion est une bibliothèque de tests unitaires en C.

Où est passé Criterion ?

Avant d’exécuter des tests avec Criterion, il est souvent nécessaire d'installer Criterion, eh oui !

before_script:
  - apt-get update && apt-get install -y libcriterion-dev
script:
  - ./configure
  - make test

Multistaging

Diviser les tests unitaires et fonctionnels en plusieurs stages garantit :

une bonne organisation
une meilleure visibilité des résultats

stages:
  - build
  - test

build:
  stage: build
  script:
    - make all

test-unit:
  stage: test
  script:
    - make unit-test

test-functional:
  stage: test
  script:
    - make functional-test

Tu t'es fait clang ?

Le formatage du code est super important pour maintenir une base de code propre.

clang_format:
  stage: format
  before_script:
    - apt-get -qq update && apt-get -qq install -y clang-format autotools-dev autoconf-archive gcovr libcriterion-dev
  script:
    - clang-format -i $(find src/ -type f -name "*.c") --dry-run --Werror

Cache

Dans certains cas, c'est utile de mettre en cache des fichiers ou dossiers pour éviter de les recharger à chaque pipeline.

Un exemple courant est le dossier node_modules/ en JavaScript.

cache:
  paths:
    - node_modules/

install:
  script:
    - npm install

Bien entendu, vous pouvez nettoyer le cache au besoin avec une option supplémentaire dans la configuration de pipeline.

Artefacts

Les artefacts sont les fichiers générés par la CI qui peuvent être partagés entre jobs ou téléchargés.

Par exemple, les rapports de tests ou de couverture.

artifacts:
  paths:
    - build/
    - reports/

Coverage de tests

On peut mesurer la couverture de tests en intégrant des outils comme gcovr ou Cobertura dans votre pipeline CI.

test-coverage:
  stage: test
  script:
    - gcovr --html --html-details -o coverage.html
  artifacts:
    paths:
      - coverage.html

Rapporteur

Ce bloc vous permet d'intégrer le coverage report dans votre Merge Request, vous pourrez ainsi voir le code qui n'est pas couvert mais aussi votre pourcentage de coverage.

coverage-report:
  script:
    # do coverage
  coverage: /^TOTAL.*\s+(\d+\%)$/
  artifacts:
    name: coverage.xml
    expire_in: 2 days
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage.xml

Environnement custom

Vous pouvez préciser l’environnement de base pour votre CI en sélectionnant une image Docker spécifique.

image: gcc:latest

En utilisant un peu ce que l'on vient de voir, ça donnerait quelque chose comme ça :

image: gcc

stages:
  - format
  - build
  - test
  - clean

clang-format:
  stage: format
  script:
    - clang-format -i $(find src/ -type f -name "*.c") --dry-run --Werror

build:
  stage: build
  script:
    - autoreconf --install
    - ./configure
    - make all

test-unit:
  stage: test
  script:
    - autoreconf --install
    - ./configure
    - make unit-test

Attention aux .h et il manque des before_script.

Petit Bonus

On peut aussi vérifier les trash-files pour s’assurer que le make clean fait bien son travail.

trash-file:
  stage: clean
  needs: []
  before_script:
    - apt-get -qq update && apt-get -qq install -y tree
  script:
    - tree > /tmp/REF
    - make && make clean
    - tree > /tmp/TEST
    - diff /tmp/REF /tmp/TEST

Conclusion

La Continuous Integration est un outil extrêmement puissant. Il peut parfois être difficile à mettre en place, mais les gains sont immenses.

Introduction à Terraform avec Proxmox

Mr. VyM — Mon, 02 Dec 2024 10:35:20 +0000

Le but de Terraform est de déployer une infrastructure ou une entité de manière idempotente. Cela signifie que l’on doit pouvoir relancer le script 100 fois et obtenir le même résultat à chaque exécution.

Pour cela, nous utilisons un provider, qui est essentiellement une bibliothèque permettant de se connecter à notre serveur.

Dans ce cas pratique, nous allons utiliser Proxmox. Il existe deux principaux providers pour Proxmox :

Telmate

C’est une bibliothèque qui permet de déployer très simplement des VMs et des LXCs.

Inconvénient : elle n’implémente pas de fonctionnalités avancées. Cependant, elle est fréquemment mise à jour.
Bpg

Cette bibliothèque est légèrement plus complexe à prendre en main, mais elle est bien plus puissante.

Organisation et Structure d'un Projet Terraform

Afin que vous puissiez mieux comprendre le projet, voici son architecture :

├── main.tf
├── provider.tf
├── variable.tf
└── terraform.auto.tfvars

Vous pouvez ajouter ou segmenter le projet en autant de fichiers .tf que nécessaire. Par exemple, nous aurions pu avoir un fichier pour les VMs et un autre pour les LXCs.

Les fichiers se terminant par .tfvars servent à définir des variables. Lorsqu’ils commencent par auto, ils sont automatiquement chargés par Terraform.
Le fichier variable.tf permet de créer des variables sans les instancier.

Petit point Vocabulaire

Dans cette article, nous allons utiliser le terme de LXC et de VM. Je vais faire un petit point dessus.

LXC ou LinuX Container : ce sont des environnements virtualisés qui tourne sur le kernel de l'hôte mais qui ne peuvent pas discuter ensemble. Cela permet de segmenter nos services sans trop perde en performance.
VM ou Virtual Machine : comme son nom l'indique, on simule l'intégralité d'une machine. On perd en performance mais on gagne en sécurité et en fonctionnalité car un LXC n'a pas tout les privilèges.

Choisir et Configurer un Provider Proxmox

Avant tout, nous devons installer le provider (la bibliothèque). Bien entendu, nous fixons une version minimale :

terraform {
  required_providers {
    proxmox = {
      source  = "bpg/proxmox"
      version = ">= 0.3.0"
    }
  }
  required_version = ">= 0.14"
}

Une fois la bibliothèque ajoutée, nous déclarons un provider nommé "proxmox", en fournissant les informations nécessaires :

provider "proxmox" {
  endpoint = "https://${var.proxmox_endpoint}:8006"
  api_token = var.api_token_secret

  insecure = true # car un certificat TLS auto-signé est utilisé
  ssh {
    agent = true
    username = terraform
  }
}

Les Variables dans Terraform

Si vous êtes attentif, vous avez remarqué que nous utilisons l’objet var.api_token_secret dans le bloc du provider. Cette chaîne de caractères est définie dans le fichier terraform.auto.tfvars.

À la manière d’un fichier .env, ce fichier contient des valeurs sensibles et ne doit pas être poussé sur le dépôt git :

# terraform.auto.tfvars
api_token_secret = "terraform-prov@pve!terraform=TOKEN"

Dans le fichier variable.tf, nous définissons les variables et leur type.

Voici les principaux types disponibles :

number
string
list() (ex. : list(string))
object
map

Exemple :

# variable.tf

variable "api_token_secret" {
  description = "Secret token to connect Proxmox API"
  type        = string
}

variable "proxmox_endpoint" {
  description = "The domain name of the Proxmox instance"
  type        = string
  default     = "proxmox.mysite.fr"
}

Les Images et les Templates

Pour démarrer nos entités, nous devons leur fournir un système d’exploitation.

Nous téléchargeons automatiquement un fichier de template pour le LXC et un ISO avec cloud-init pour la VM.

Si vous ne connaissez pas cloud-init, c’est une méthode permettant d’instancier des machines sans passer par l’installateur de l’OS.

resource "proxmox_virtual_environment_download_file" "ubuntu_22-04_lxc" {
  content_type = "vztmpl"
  datastore_id = "local"
  node_name    = var.target_node
  url          = "http://download.proxmox.com/images/system/ubuntu-22.04-standard_22.04-1_amd64.tar.zst"
}

resource "proxmox_virtual_environment_download_file" "ubuntu_22-04_img" {
  content_type = "iso"
  datastore_id = "local"
  node_name    = var.target_node
  url          = "https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img"
}

On crée un Réseau Virtuel

Si nous avons envie que nos ressources discutent entre elles, il nous faut un réseau.

Pour créer un adaptateur virtuel, il suffit d’appeler la ressource proxmox_virtual_environment_network_linux_bridge et de lui donner un nom :

resource "proxmox_virtual_environment_network_linux_bridge" "internal_network" {
  node_name = var.target_node
  name      = "vmbr5"
  comment   = "Internal Network"
}

Votre premier Container

Passons aux choses concrètes en instanciant un LXC. Pour cela, nous créons une ressource proxmox_virtual_environment_container.

Avec l’IaC, tout peut être configuré : le disque, la RAM, le serveur DNS, etc.

resource "proxmox_virtual_environment_container" "first_lxc" {
  description   = "Managed by Terraform - Mr.VyM"
  node_name     = var.target_node
  start_on_boot = true
  started       = true

  vm_id = 101

  cpu {
    architecture = "amd64"
    cores        = var.core_nb
  }

  disk {
    datastore_id = "storage"
    size         = var.disk_size
  }

  memory {
    dedicated = var.memory_size
    swap      = 0
  }

  operating_system {
    template_file_id = proxmox_virtual_environment_download_file.ubuntu_22-04_lxc.id
    type             = "ubuntu"
  }

  initialization {
    hostname = "mycontainer"

    dns {
      servers = ["1.1.1.1", "1.0.0.1"]
    }

    ip_config {
      ipv4 {
        address = "192.168.10.2/24"
        gateway = "192.168.10.1"
      }
    }

    user_account {
      keys     = ["keys 1", "keys 2"]
      password = var.lxc_password
    }
  }

  network_interface {
    bridge = proxmox_virtual_environment_network_linux_bridge.internal_network.name
    name   = "eth0"
  }
}

Et maintenant une VM

Créer une VM suit le même pattern que pour un LXC, avec quelques différences :

resource "proxmox_virtual_environment_vm" "vm_template" {
  description = "Managed by Terraform - Mr.VyM"
  node_name   = var.target_node

  name        = "MyDummyVM"
  vm_id       = 102

  cpu {
    cores = var.core_nb
    type  = "x86-64-v2-AES"  # recommandé pour les CPU modernes
  }

  memory {
    dedicated = var.memory_size
    floating  = var.memory_size # active le ballooning
  }

  disk {
    datastore_id = "local"
    file_id      = proxmox_virtual_environment_download_file.ubuntu_22-04_img.id
    interface    = "scsi0"
    size         = var.disk_size
  }

  initialization {
    ip_config {
      ipv4 {
        address = "${var.base_subnet}.3/24"
        gateway = "${var.base_subnet}.1"
      }
    }

    user_account {
      keys     = ["keys 1", "keys 2"]
      password = var.vm_password 
      username = "mrvym"
    }

    datastore_id = "local"
  }

  network_device {
    bridge = proxmox_virtual_environment_network_linux_bridge.internal_network.name
  }

  operating_system {
    type = "l26" # Linux Kernel
  }
}

On check et ca part en Prod

Enfin, nous déployons le tout avec les commandes suivantes :

terraform init

Initialise Terraform, télécharge les providers et crée les fichiers terraform.state et terraform.lock. Ces fichiers stockent l’état des entités sur le serveur.

Si ces fichiers sont absents, Terraform recrée les ressources, ce qui pourrait entraîner leur suppression et recréation.
terraform fmt

Formate le code pour garantir sa propreté.
terraform plan

Vérifie les actions que Terraform s’apprête à exécuter.
terraform apply

Applique les modifications.

Ecrit pour l'Avent of Tech de la JECT

Disque dur : SAS, SATA, SCSI ou IDE ?

Mr. VyM — Thu, 07 Nov 2024 01:11:30 +0000

Notre but dans cet article est de mieux comprendre le concept des interfaces matérielles / programmation, des couches physiques et des jeux de commandes, et plus simplement des systèmes de stockage qui nous entourent.

Mais d'abord, un "rapide" récapitulatif de l'état actuel de nos périphériques de stockage :

Norme de stockage	Interface matérielle	Couche physique	Jeux de commandes
PATA	IDE (Integrated Drive Electronics)	Connecteur 40/44 broches, câble parallèle	ACS (ATA Command Set)
SATA	SATA (Serial ATA)	Connecteur SATA, câble série	ACS (ATA Command Set)
SAS (Serial Attached SCSI)	SCSI (Small Computer System Interface)	Connecteur SAS, câble série	SCSI (Small Computer System Interface)
NVMe (Non-Volatile Memory Express)	PCIe (Peripheral Component Interconnect Express)	Bus PCIe	AHCI (Advanced Host Controller Interface)

Si vous vous demandez, oui, les constructeurs ont pris un malin plaisir à utiliser le même nom entre l'interface et la norme.

--
Avant de commencer, un point vocabulaire

Couche Physique : C'est le cable et le connecteur.

Interface Materielle : C'est la maniere de communiquer, attention ne pas confondre avec le "language".

Jeu de commandes : C'est le language utilisé.

Pour faire une analogie, si vous etes un humain (j'espere 🤔), la couche physique c'est vos cordes vocales, l'interface materielle, c'est la maniere de faire vibrer vos cordes et le jeu de commandes, c'est le language utilisé.

Norme de stockage

ATA

Date : 1986

Qui : Western Digital

ATA signifie Advanced Technology Attachment.

C'est le véritable concurrent du protocole SCSI. C'est aussi un ensemble de normes avec l'interface matérielle (IDE), la couche physique (PATA ou bien SATA) et les jeux de commandes (ACS).

C'est une version plus low-cost de SCSI, qui avait pour but de réutiliser des éléments de ce dernier mais en simplifiant le connecteur (la couche physique) et le jeu d'instruction.

Contrairement au SAS, cette norme est en semi-duplex, ce qui signifie qu'elle ne peut exécuter qu'une seule action simultanément : soit lire, soit écrire.

SAS

Date : 1980

Qui : Shugart / NCR Corporation

C'est un ensemble de normes qui s'applique sur les couches physiques et les jeux de commandes.

Nous devons revenir dans les années 80, à cette époque, il n'y a pas des milliers de façons de communiquer avec un périphérique de stockage. L'un d'entre eux est le protocole SCSI (Small Computer System Interface).

C'est un protocole propriétaire mais très performant pour son temps. Son grand avantage est le fait de déporter la logique dans le périphérique, contrairement à ses concurrents qui utilisent allègrement la puissance de l'ordinateur. Et dans les années 80, on n'avait pas encore la puissance de calcul, ce protocole a donc été particulièrement apprécié par l'industrie.

De plus, la norme a l'avantage de pouvoir écrire en duplex, c'est-à-dire lire et écrire des données simultanément.

Interface matérielle

IDE

IDE est une norme qui intègre le contrôleur de disque directement sur le disque dur lui-même. Avant IDE, les contrôleurs de disque étaient séparés, ce qui compliquait la configuration et limitait la compatibilité.

Cela signifie qu'un disque dur est dit compatible IDE s'il possède une puce IDE.

SATA

C'est une ré-implémentation de l'interface matérielle parallèle en série (Serial ATA).

Qu'est-ce qu'un port parallèle ?

Contrairement au port série, un port parallèle peut transférer un ensemble de 8 bits à la fois sur huit fils différents.

Pour vous donner une idée de l'interface matérielle / couche physique.

PCIe

L'interface matérielle PCIe (Peripheral Component Interconnect Express) est une interface de communication utilisée principalement pour connecter des périphériques internes tels que des cartes graphiques, des cartes réseau et d'autres cartes d'extension.

Elle utilise un bus série, ce qui signifie que les données sont transmises bit par bit sur une seule ligne, contrairement aux anciennes interfaces parallèles.

PCIe fonctionne avec des connecteurs spécifiques et des voies de transmission (lanes) qui permettent des transferts de données très rapides.

Les cartes PCIe sont insérées dans des slots PCIe sur la carte mère, et l'interface est disponible en différentes versions (x1, x4, x8, x16) en fonction du nombre de voies utilisées, offrant ainsi une bande passante ajustée aux besoins des périphériques.

PCIe est largement utilisé dans les systèmes modernes en raison de sa vitesse de transmission élevée, de sa flexibilité et de sa capacité à évoluer pour prendre en charge des dispositifs nécessitant des débits importants.

Couche physique

Globalement, c'est la partie la plus simple de l'article.

(Enfin, en électronique, ce n'est jamais simple).

Une couche physique, cela signifie que c'est la norme qui régit la façon de réaliser le câble et le connecteur (cf Illustration du Pin-out)

Une nappe IDE

Dans notre cas, c'est un câble dit "IDE".

Ce genre de câble est la version parallèle, il contient 80 fils, ce qui permet de connecter deux appareils à la carte mère. Le premier sera appelé "master" et le deuxième "slave".

Mais je ne vais pas détailler les différents câbles qui existent.

Jeux de commandes

ACS (Commandes)

Date : années 80

Qui : Shugart / NCR Corporation

Le ATA Command Set (ACS) est la liste des commandes que le système peut envoyer au périphérique.

On pourrait citer comme exemples :

WRITE_SECTOR
SLEEP
PACKET
IDENTIFY PACKET DEVICE

SCSI

ACS étant un détournement du jeu de SCSI, on retrouve de grandes similitudes entre les deux jeux. Cependant, on peut les différencier en creusant un peu, notamment en ce qui concerne les rapports d'erreurs.

AHCI

AHCI (Advanced Host Controller Interface) permet une communication optimisée entre le système d'exploitation et les périphériques de stockage, en offrant des fonctionnalités avancées comme le contrôle de file d'attente (pour améliorer les lectures/écritures simultanées) et le mode NCQ (Native Command Queuing), qui permet au disque de réorganiser les commandes d'entrée/sortie pour une performance maximale.

Ce jeu de commandes facilite également des fonctionnalités telles que la gestion de l'alimentation et le hot-plug (permettre l'ajout et le retrait de périphériques sans éteindre le système).

AHCI a été conçu pour améliorer les performances et la gestion des périphériques de stockage SATA en optimisant l'utilisation des ressources et la vitesse des transferts.

Conclusion / Performance

Nous n'avons toujours pas parlé de la partie performance de ces différences, donc voici le mot de la fin.

Interface	Vitesse max (Gb/s)	Type de connexion	Utilisation principale
SATA III	6 Gb/s	Série	SSD et HDD domestiques
SAS	22,5 Gb/s	Série	Disques professionnels et serveurs
PCIe 5.0	32 Gb/s par ligne	Série	SSD NVMe internes
NVMe	Dépend de PCIe	PCIe	SSD haute performance
U.2	Selon PCIe (16-32 Gb/s)	PCIe et NVMe	Serveurs et stations de travail
M.2	Selon PCIe (16-32 Gb/s)	PCIe ou SATA	Ordinateurs portables et de bureau
Thunderbolt 3/4	40 Gb/s	Série (USB-C)	Stockage externe rapide
USB 4	40 Gb/s	Série (USB-C)	Stockage externe polyvalent

#define INC(a) INC(a+1)

Mr. VyM — Thu, 17 Oct 2024 22:05:58 +0000

Cette macro fait-elle planter GCC ? Lisez et vous aurez la réponse

Le but de cet article est de vous faire découvrir le magnifique univers des macros en C.

Une directive préprocesseur

En C, les lignes qui commencent par un # sont interprétées par le compilateur avant la compilation des fichiers sources.
On les appelle des directives du préprocesseur. Les macros en font partie.

Petit point historique :

Les macros en langage C ont été introduites avec la première norme du langage C, appelée ANSI C (ou C89),
qui a été standardisée par l'American National Standards Institute (ANSI) en 1989.

Cependant, avant cette standardisation, les macros faisaient déjà partie du langage C classique (ou K&R C) utilisé dans les années 1970.
Le compilateur C original, développé par Dennis Ritchie pour le système d'exploitation UNIX, incluait déjà une forme rudimentaire de macros via le préprocesseur, permettant des définitions avec #define.

Define

#define SENS_DE_LA_VIE 3.14

/* ... */

printf("%f\n", SENS_DE_LA_VIE);

Le define a un fonctionnement assez simple à comprendre : le compilateur remplace toutes les occurrences dans le code par la valeur définie. Il fonctionne avec la syntaxe suivante #define <MACRO_NAME> <value>. On a pour convention de mettre le nom en majuscule, la valeur quant à elle est optionnelle.

Un peu comme un "Ctrl-f et remplacer".

Mama, la macro

On peut utiliser les define pour définir des fonctions que l'on pourra utiliser dans notre code.

#define INC(a) a++ 
#define MULTI_LINE(a,b) a = b; \
                        b = 0; 


INC(my_variable); 
MULTI_LINE(my_variable, foobar) 
// Je souligne le fait qu'il peut ne pas y avoir de ';' en fin de ligne 

// Cela donnera  
my_variable++;
my_variable = foobar;
foobar = 0;

If or not if

Nous pouvons déclarer des macros de manière conditionnelle.
Si un nom est déjà défini alors on exécute le bout de code suivant.

#ifdef DEBUG
// Je souligne qu'il est rarement conseillé d'utiliser des printf() en debug
// et que nous avons brisé la règle du nom des macros en MAJ.
#define return printf("(%s:%d)\n", __FUNCTION__, __LINE__);  return
#endif /* ! DEBUG */

int main(void) {
    return 1;
}

Dans ce cas, j'utilise un #ifndef, mais il existe aussi :

#ifdef
#if
#else
#elif

#if (X == 1)
#define Y 2
#elif (X == 2)
#define Y "Ami de la bonne blague, bonjour !"
#else
#define Y NULL
#endif /* ! X */

/* ... */

int main(void) {
    #if (X == 1)
    printf("%d\n", Y);
    #elif (X == 2)
    printf("%s\n", Y);
    #else
    printf("%p\n", Y);
    #endif /* ! X */
}

On aime bien signaler avec un commentaire en bloc la fin des #if. C'est une convention qui permet de mieux se repérer dans le code.

Macros prédéfinies

Vous avez pu voir dans l'exemple précédent que j'utilisais les mots-clés __FUNCTION__ et __LINE__.
Comme vous pouvez vous en douter, ce sont des macros que le compilateur va remplacer par la bonne valeur.

Il existe une liste de macros prédéfinies Common Predifined.

À noter qu'il existe des macros dites System specific.

Petite liste non exhaustive :

__DATE__ : Jan 14 2012
__GNUC__ : Version majeure de GCC
__TIME__ : 15:12:18
__INCLUDE_LEVEL__ : La profondeur des includes en commençant par 0
__BASE_FILE__ : Le nom du fichier actuel

Vers l'infini et au-delà des arguments

// Ici, l'opérateur ## est l'opérateur de concaténation
#define DEBUG_PRNTF(fmt, ...) printf("LOG" ## fmt, __VA_ARGS__);

Ici, on peut voir que l'on génère des macros variadiques, surtout utiles lors de la création de logs.
(Même si ce n'est pas une bonne idée de faire des logs avec des printf.)

X-Macro

Pour cela, nous allons devoir créer un fichier externe, souvent nommé en *.def bien qu'il n'existe pas de convention.

// color.def
X(NC, "\e[0m", "No Color", 0x000000) 
X(BLACK, "\e[0;30m", "Black", 0x000000) 
X(GRAY, "\e[1;30m", "Gray", 0x808080) 
X(RED, "\e[0;31m", "Red", 0xFF0000) 
X(LIGHT_RED, "\e[1;31m", "Light Red", 0xFF8080) 
X(GREEN, "\e[0;32m", "Green", 0x00FF00) 
X(LIGHT_GREEN, "\e[1;32m", "Light Green", 0x80FF80) 
X(BROWN, "\e[0;33m", "Brown", 0xA52A2A) 
X(YELLOW, "\e[1;33m", "Yellow", 0xFFFF00) 
X(BLUE, "\e[0;34m", "Blue", 0x0000FF) 
X(LIGHT_BLUE, "\e[1;34m", "Light Blue", 0xADD8E6) 
X(PURPLE, "\e[0;35m", "Purple", 0x800080) 
X(LIGHT_PURPLE, "\e[1;35m", "Light Purple", 0xEE82EE) 
X(CYAN, "\e[0;36m", "Cyan", 0x00FFFF) 
X(LIGHT_CYAN, "\e[1;36m", "Light Cyan", 0xE0FFFF) 
X(LIGHT_GRAY, "\e[0;37m", "Light Gray", 0xD3D3D3) 
X(WHITE, "\e[1;37m", "White", 0xFFFFFF)

typedef struct {
    const char *name;        
    const char *ansi_code;  
    const char *description;
    unsigned int rgb;      
} Color;

#define X(NAME, ANSI, DESC, RGB) { #NAME, ANSI, DESC, RGB },
Color colors[] = {
    #include "color.def"
};
#undef X

#define X(NAME, ANSI, DESC, RGB) printf("%s (%s) = %s\n", #NAME, DESC, #RGB);
void print_colors() {
    // Bien entendu, on pourrait itérer sur la structure créée mais c'est une illustration
    #include "color.def"
}
#undef X

Ce genre de macro est extrêmement utile. Je dois reconnaître qu'on la retrouve rarement dans un code source, mais elle permet de modifier le fonctionnement du programme sans pour autant devoir modifier le code source. Fun fact, elle est souvent utilisée dans la création de kernels. Elle permet de générer les structures globales comme l'IDT et la GDT.

Les problèmes

Attention : Petite mise au point d'abord, les macros sont des outils formidables mais il faut faire attention. Vous ne devez surtout pas utiliser ce genre de macro :

#define MIN(a,b) (a < b ? a : b)

Prenons un exemple : MIN(2 + 5, fibo(25))

Problème n°1

MIN(2 + 5, fibo(25)) => (2 + 5 < fibo(25) ? 2 + 5 : fibo(25))

Ici le problème est la priorité de calcul. Le compilateur va d'abord effectuer la comparaison puis l'addition, donc 2 + (1). On corrige cela par l'ajout de parenthèses en utilisant les arguments des macros.

#define MIN(a,b) ((a) < (b) ? (a) : (b))

Comme vous ne savez jamais ce que vos utilisateurs vont passer en paramètre, mettez toujours des parenthèses sur les arguments.

Problème n°2

MIN(2 + 5, fibo(25)) => (2 + 5 < fibo(25) ? 2 + 5 : fibo(25))

On remarque que le compilateur fait un remplacement bête et méchant, ce qui veut dire que l'on va calculer deux fois fibo(25). Je vous laisse imaginer si c'est une implémentation récursive.

Pour fixer ce problème, nous déclarons une variable intermédiaire avant le if.

Macros utiles

#define MIN(a, b)                                                              \
    ({                                                                         \
        __typeof__(a) _a = a;                                                  \
        __typeof__(b) _b = b;                                                  \
        (_a) > (_b) ? (_b) : (_a);                                             \
    })

#define ABS(a)                                                                 \
    ({                                                                         \
        __typeof__(a) _a = a;                                                  \
        0 < (_a) ? (_a) : -(_a);                                               \
    })

#define MAX(a, b)                                                              \
    ({                                                                         \
        __typeof__(a) _a = a;                                                  \
        __typeof__(b) _b = b;                                                  \
        (_a) < (_b) ? (_b) : (_a);                                             \
    })

#define CLAMP(a, x, b) MAX(a, MIN(x, b))
// Pour les tableaux uniquement
#define COUNT_OF(arr) sizeof(arr) / sizeof(arr[0])

Là, on s'amuse

Ici, c'est du code purement overkill juste pour le fun. Je ne vous conseille pas forcément d'utiliser ces macros dans votre code.
Je me fais juste plaisir (faut bien dans la vie).

Un auto free

#define DEFER(free_call) __attribute__((cleanup(free_call)))

void auto_free(void *ptr) {
    void **p = (void **)ptr;
    if (*p) {
        free(*p);
        *p = NULL;
    }
}

int main() {
  DEFER(auto_free) char* buffer = malloc(10);
  return 0;
}

Je vous laisse tester avec un petit -fsanitize=address. C'est vraiment une dinguerie. On pourrait même voir une amélioration de la fonction auto_free qui prend en paramètre une chaîne de caractères du nom de notre structure pour faire un switch.

Get time

Fonction plus chill où l'on calcule juste le temps d'exécution de notre fonction. Très utile pour faire du benchmark.

#define MEASURE_TIME(block) {                                \
    clock_t start_time = clock();                            \
    block                                                    \
    clock_t end_time = clock();                              \
    double elapsed = ((double)(end_time - start_time)) / CLOCKS_PER_SEC * 1000.0; \
    printf("Execution time: %.3f ms\n", elapsed);            \
}

Define Error

Petite X-macro qui prend une macro en argument et qui l'expand.

#define ERROR_LIST(X)          \
    X(ERROR_FILE_NOT_FOUND, "File not found")    \
    X(ERROR_INVALID_INPUT, "Invalid input")      \
    X(ERROR_OUT_OF_MEMORY, "Out of memory")      \
    X(ERROR_UNKNOWN, "Unknown error")

#define DEFINE_ERROR_ENUM(code, message) code,
enum ErrorCode {
    ERROR_LIST(DEFINE_ERROR_ENUM)
};

#define DEFINE_ERROR_STRING(code, message) case code: return message;
const char* get_error_message(enum ErrorCode error_code) {
    switch (error_code) {
        ERROR_LIST(DEFINE_ERROR_STRING)
        default: return "Unrecognized error";
    }
}

/* ... */
enum ErrorCode error = ERROR_OUT_OF_MEMORY;
printf("Error: %s\n", get_error_message(error));

Génération de tests automatisés

Ici, on génère carrément des fonctions entières avec une macro, parce que le C n'a aucune limite. Moi aussi 👀

#define GENERATE_TEST_FUNC(func, test_value, wanted_value) \
    void test_##func(void) { \
        printf("Test de " #func " avec valeur %d : ", test_value); \
        if (func(test_value)) { \
            printf("Succès\n"); \
        } else { \
            printf("Échec\n"); \
        } \
    }

/* ... */
GENERATE_TEST_FUNC(fibo, 10, 55);

test_fibo();

RTFM

Il est maintenant l'heure de conclure. Nous avons vu plein de choses très cool. Et si jamais vous êtes tentés, libre à vous de découvrir les macros par vous-même. Il reste encore plein de choses à voir.
Donc, conclusion : RTFM.

PS : Pour ce qui est du titre, les macros ne sont pas récursives, elles ne s'expandent qu'avec une profondeur de 1 et dans notre cas présent, GCC va faire une implicit_declaration sur INC et crash.

Le merveilleux monde de Make

Mr. VyM — Thu, 14 Mar 2024 20:48:14 +0000

Le merveilleux monde de Make

Les Makefiles constituent un outil essentiel dans le développement de logiciels que ce soit en C/C++ ou autre. Ils permettent une gestion efficace des projets en automatisant le processus de compilation, de nettoyage et de tests.

Dans cet article, nous explorerons les bonnes pratiques pour la création et l'utilisation de Makefiles dans des projets C quelque soit leurs complexites.

Make, ca sert a quoi ?

Make est un programme qui a pour but de générer des fichier. Il permet de générer des pdfs, des exécutables et bien plus.

Dans les années 1970, la compilation des programmes devient de plus en plus longue et complexe, nécessitant de nombreuses étapes interdépendantes. La plupart des systèmes alors utilisés reposent sur des script shell, nécessitant de répéter toutes les étapes lors de la moindre correction. C'est dans ce contexte que Make fut développé par le docteur Stuart Feldman en 1977. En gérant les dépendances entre fichiers sources et fichiers compilés, Make permet de ne compiler que ce qui est nécessaire à la suite de la modification d'un fichier source.

Il existe un makefile par défaut, qui définit un grand nombre de règles afin de générer la plupart des fichiers avec lesquels, vous serez amené a travailler.

Pour voir ce makefile, par défaut : make -p

Hello World

Pour débuter, nous allons prendre un cas très simple celui d'un fichier source unique, dans le même dossier que notre makefile.

.
└── main.c

Dans ce cas, il existe 2 facons de faire.

$ make main # Je souligne l'absence du .c

Dans cette commande, nous demandons a make de créer le fichier main. Mais comment sait-il qu'il doit utiliser le fichier main.c pour faire notre binaire ? Cela est défini dans les règles par défaut.

Nous pouvons aussi creer un fichier Makefile

# Makefile
my_compilation_rule: 
    gcc main.c

Une fois, le fichier crée, il suffit d'exécuter la commande make (qui, par défaut, exécute la première règle du fichier).
Nous pouvons aussi mettre en argument le nom de la règle que nous voulons exécuter make my_compilation_rule.

Plus on est de fou, plus on rit

Notre projet grossit, nous avons maintenant un deuxième fichier source.

.
├── foo.c
├── foo.h
└── main.c

Dans l'objectif de faire un makefile propre, nous allons déclarer une variable OBJ qui contiendra nos différents fichiers. On en profite pour déclarer un variable CC pour notre compilateur.

# makefile
CC = gcc
OBJ = main.o foo.o


# Cette variable sera utilisée dans la règle implicite qui compile les .o  
CFLAGS = # My C Flags for the compiler
LDFLAGS = # My linker flags
TARGET = a.out

all: $(OBJ)
    $(CC) $(OBJ) -o $(TARGET) $(LDFLAGS)

Cette fois-ci, nous avons ajouter des dépendances à notre règle all. Maintenant, make sait qu'il faut d'abord faire les fichiers .o avant de pouvoir faire le linkage de tous les fichiers en un binaire.

# makefile
SRC = $(wildcard *.c) # main.c foo.c
OBJ = $(SRC:.c=.o) # main.o foo.o

Dans ce makefile, nous avons choisi de ne pas récupérer, à la main, les différents fichiers source. Nous récupérons automatiquement les fichiers source via la fonction wildcard. Cette fonction agit comme le globbing d'un shell. Dans cette example, elle récupère tous les fichiers terminant par .c.

Nous les convertissons en .o via cette syntax $(NAME:old=new) qui n'est rien de moins qu'un replace. La suite de notre makefile reste néanmoins la même chose.

Clean

Comme vous avez pu le remarquer, un makefile peut facilement générer un grand nombre de fichiers. C'est pour cela que nous allons créer une nouvelle règle dans notre makefile qui a pour but de supprimer tous les fichiers issus de la compilation.


# ...

clean: 
    $(RM) $(OBJ)
    $(RM) $(TARGET)

Pour les petits curieux qui se demandent ce que signifie la variable RM. C'est un simple alias avec la commande rm -f. Il faut savoir que cette variable peut très bien override. On peut très bien voir RM = echo ou bien RM = mv to/path/ (à la place du remove), cela peut être très utile dans certains projets.

Phony

Nous l'avons dit au début de cet article, mais make est un utilitaire qui permet de générer des fichiers. Mais que se passe-t-il, si l'on appelle la règle clean et qui existe un fichier clean dans notre dossier.

make: 'clean' is up to date.

Pour éviter ce genre de problème, il faut spécifier dans notre makefile que notre règle n'a pas pour but de générer un fichier. Pour cela, nous utilisons le mot clé phony.

Il suffit d'écrire.

.PHONY: my_rule1 my_rule12 # ...

On range le repo

Maintenant, que nous avons réussi à faire un makefile propre, nous allons pouvoir faire évoluer notre projet en mettant nos fichiers dans un dossier src.

.
├── Makefile
└── src/
    ├── foo.c
    ├── foo.h
    └── main.c

Pour cela, il nous suffit de rechercher la liste de nos .c dans le dossier src/ puis de les transformer en .o. On peut modifier le code que nous avons fait ci-dessus.

SRCDIR = src
SRC = $(wildcard $(SRCDIR)/*.c)
OBJ = $(SRC:$(SRCDIR)/%.c=$(SRCDIR)/%.o)
# qui est équivalent à
# OBJ = src/main.o \
#       src/main.o

Where GDB ?

Il peut être utile d'avoir un règle debug, afin de ne pas avoir à mettre un -g dans nos CFLAGS par défaut.

Pour cela, il suffit de :

debug: CFLAGS += -g
debug: all

On remarque que la règle debug n'a pas de corps. Elle se contente d'ajouter un flag et d'appeler notre règle all.

Tester, c'est tricher

Pour cet article, nous allons voir comment faire un Makefile pour une test suite criterion.

.
├── Makefile
├── src/
...
└── tests/
    └── foo_test.c

Pour pouvoir lancer, nos tests, il va falloir que l'on trouve les fichiers source du dossier tests, puis linker tous nos fichiers en excluant le fichier main.o.

TEST_DIR = tests
SRC_TEST = $(wildcard $(TEST_DIR)/*.c)
OBJ_TEST = $(SRC:$(TEST_DIR)/%.c=$(TEST_DIR)/%.o)

# ... 

check: $(filter-out $(SRC_DIR)/main.o, $(OBJ)) $(OBJ_TEST)
$(CC) $^ -o $(TARGET) $(LDFLAGS)

On remarque que le fichier main.o est exclus en utilisant la fonction filter-out. On voit aussi l'appel d'une variable pour le moment inconnu. Il en existe un grand nombre.

$^ : La liste des dépendances de la règle
$< : Le nom de la première dépendance
$@ : Le nom de la règle

On teste les tests

Si l'on parle de test, nous devons forcément parler de coverage. Pour cela rien de plus simple, nous ajoutons les flags a nos variables puis exécutons GCOVR

coverage: CFLAGS += -fPIC --coverage
coverage: LDFLAGS += -lgcov -lcriterion
coverage: check
gcovr --print-summary

Like a pro

La création d'un dossier build est la cerise sur le gâteau. Elle permet au développeur de faire rm -rf build/ pour faire un clean.

Pour cela, nous allons devoir modifier notre variable OBJ et nous allons devoir créer un règle pour la compilation des .o. Nous ne pouvons plus utiliser les règles implicite.

BUILD_DIR = build
OBJ = $(SRC:$(SRC_DIR)/%.c=$(BUILD_DIR)/%.o)

# Compilation des fichiers source
$(BUILD_DIR)/%.o: $(SRC_DIR)/%.c | $(BUILD_DIR)
$(CC) $(CFLAGS) -c $< -o $@

# Creer le repertoire de build
$(BUILD_DIR):
mkdir -p $(BUILD_DIR)

Alors on remarque que cette fois-ci, nous n'avons pas défini une règle, mais avec une variable. Nous avons même utilisé une sorte de regex pour la définir.

Nous avons aussi dû mettre un prérequis en plus, la règle $(build_dir). Le fait de mettre un | signifie qu'il doit d'abord vérifier qu'il est nécessaire de faire cette règle.

Bonus

Bibliothèque statique

Pour créer une bibliothèque statique à partir des fichiers source, vous pouvez ajouter des règles au Makefile :

LIB_TARGET = libmylib.a
LIB_OBJS = $(filter-out $(BUILD_DIR)/main.o, $(OBJS))

$(LIB_TARGET): $(LIB_OBJS)
ar rcs $@ $^

Une fois, la librairie crée, vous pourrez simplement la link avec votre binaire.

Makefile récursif

Si votre projet comporte des sous-modules, vous pouvez utiliser un Makefile récursif. Imaginons un projet avec la structure suivante.

.
├── Makefile
└── src/
    ├── features1/
        ...
        └── Makefile
    ├── features2/
        ...
        └── Makefile
    ├── features3/
        ...
        └── Makefile
    ├── features4/
        ...
        └── Makefile
    ├── main.c
    └── Makefile

Pour cela, il y a deux approches possibles. La première serait de faire un seul makefile à la racine de notre projet et faire un find de nos fichiers .c. Nous verrons comment faire par la suite.

La deuxième, c'est de faire une structure récursif via le Makefile suivant.

# src/makefile 
SUBDIRS = $(wildcard */.)

.PHONY: subdirs $(SUBDIRS)

subdirs: $(SUBDIRS)

$(SUBDIRS):
    $(MAKE) -C $@

Avec ce fichier, nous allons pouvoir mettre un makefile dans chaque dossier features et lui et lui seul gérera la compilation de la features. Ils seront appelés par le src/Makefile via la règles subdirs.

# Makefile

export CFLAGS = -Wall -Werror -pedantic

# ...

N'oubliez pas d'export vos variables dans votre Makefile afin qu´elle s'applique sur les Makefiles suivants.

Ce genre d'architecture nécessite, la plupart du temps, de la combiner avec la création de librairie statique.

Répertoires infinis

Nous avons vu comment utiliser la fonction wildcard mais comment faire pour recuperer l'intégralité de nos fichiers sources ?

├── Makefile
└── src/
    └── foo/
        └── bar/
            ...
                └── foobar/
                    └── barfoo/
                        └── here.c

La prise en charge des répertoires "infinis" peut se faire via des règles génériques ou bien par l'intermédiaire d'un sub-shell.

Par exemple :

# Attention, il faut que votre systeme possede la command find

SRC = $(shell find $(SRC_DIR) -name "*.c")

ou bien

# Je laisse les plus aventureux d'entre vous dechiffrer ce code

rwildcard = $(foreach d, $(wildcard $(1:=/*)), $(call rwildcard,$d,$2) $(filter $(subst *,%,$2),$d))
SRC = $(rwildcard src,*.c)

ou encore

SRC = $(wildcard src/*.c) \
      $(wildcard src/*/*.c) \
      # ... # 
      $(wildcard src/*/*/*/*/*/*/*/*/*/*/.c)
# S'il vous plait, ne faites pas ca

$ make conclusion

En conclusion, l'utilisation judicieuse des Makefiles est cruciale pour la gestion efficace de projets. Il permet d'économiser énormément de temps lors du processus de développement. Ce n'est pas pour rien que la quasi-intégralité de l'industrie utilise cet outil.

Cette article n'étant bien entendu, pas exhaustif, je vous invite à vous renseigner par vous meme afin de découvrir les autres fonctionnalités de cet outil.