VScode clangd - widoczność makr

Pytanie do osób, które korzystają z clangd.
Wiecie może czy da się jakoś go skonfigurować tak, aby był świadom istnienia
makr zdefniowanych w cmake'u?

Przykład, mam w cmake'u takie coś:

add_compile_definitions(RESOURCES_DIR="sciezka/do/plikow")

W main.cpp takie coś:

const std::string resources_dir{RESOURCES_DIR};

I chciałbym, żeby clangd nie podświetlał mi wykorzystania makra w mainie na czerwono.

Używam windowsa, więc wygenerowanie compile_commands.json jest niemożliwie z tego co czytałem.

[1]
jak nie musisz to nie używaj globalnych funkcji
lepiej bedzie
target_compile_definitions(app_name PRIVATE RESOURCES_DIR="sciezka/do/plikow")

[2]
u mnie na Windows generuj sie plik compile_commands.json, a masz ustawione ?
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

@Marius.Maximus: A jakiego kompilatora używasz?

Clang 18.1.1 x86_64-w64-windows-gnu (mingw64)

@Marius.Maximus: To chyba wiem dlaczego u ciebie działa - cmake korzysta z generatora makefile albo ninja.

@Marius.Maximus: Jak skonfigurowałeś tego clanga pod windowsem?
Pobrałem go przez VS installera, ale nadal pod spodem używa on generatora MSVC.

SOA #1

cmake_minimum_required(VERSION 3.10.0)
project(aaaaaaaaa VERSION 0.1.0 LANGUAGES C CXX)

add_compile_definitions(RESOURCES_DIR="sciezka/do/plikow")

add_executable(aaaaaaaaa main.cpp)

#include <iostream>

int main(int, char**){
    std::cout << "Hello, from aaaaaaaaa!\n";
    std::cout << RESOURCES_DIR;
    return 0;
}

zaraz po otwarciu projektu mam

ale trącam plik (na konsoli clang pojawiają sie komunikaty) i po chwili

Ja używam clangd: https://packages.msys2.org/package/mingw-w64-clang-x86_64-clang-tools-extra?repo=clang64
w komplecie z tym kompilatorem: https://packages.msys2.org/package/mingw-w64-clang-x86_64-clang?repo=clang64

moze to jest sekret ?

@Marius.Maximus: Podajesz normalnie ścieżki do kompilatora w CMakeLists czy wtyczka sama to wykrywa?

@Eldorad O.:

jezeli chodzi o cmake to kompilator ustawia "CMake: select kit" cmake-tools-kits.json (plik konfiguracyjny cmake-tools)

  {
    "name": "Clang 18",
    "compilers": {
      "C": "C:\\msys64\\clang64\\bin\\clang.exe",
      "CXX": "C:\\msys64\\clang64\\bin\\clang++.exe"
    },
    "isTrusted": true
  },

clangd nie wiem dlaczego ale ustawil sobie na start inny kompilator (zauważalnym na kosoli c:\mingw64\mingw64\bin\clang++.exe) i miałem nawet bledy na #include <vector>
odinstalowałem drugi kompilatoror i wtedy już działa normalnie

IMHO definiowanie mark za bardzo nieporęczne. To rozwiązanie przyszło z C jest idiomatyczne dla C++.
Przykładowo zmienna konfiguracji automatycznie powoduje przebudowanie całego projektu.

Jeśli trzeba przekazać konfigurację do kodu C++ jako stałe, to wolę stosować configure_file.
Tworzę plik nagłowkowy o. rozszerzeniu .h.in

Demo.h.in

#pragma once

#include <string_view>

namespace config {
constexpr std::string_view RESOURCES_DIR="@RESOURCES_DIR@";
}

CMakeLists.txt

configure_file(Demo.h.in "${CMAKE_CURRENT_BINARY_DIR}/Demo.h" ESCAPE_QUOTES @ONLY)

target_sources(SomeTarget PUBLIC "${CMAKE_CURRENT_BINARY_DIR}/Demo.h")
target_include_directories(SomeTarget PUBLIC "${CMAKE_CURRENT_BINARY_DIR}")

Zaleta jest taka, że

• nie ma makr
• zmiana konfiguracji nie powoduje przebudowanie wszystkiego, a jedynie przebuduje to co robi #include <Demo.h>
• wszystkie narzędzia to ogarną
• można stosować namspace lub inne bardzej zaawansowane rozwiązania z C++.

@MarekR22: O, fajnie, nawet nie wiedziałem że istnieje taka opcja.