маке, cmake и модули из С++ 20

И тишина-а-а… только количество отслеживающих потихоньку подрастает…

Насколько я знаю, там конь не валялся. Т.е. даже протокол взаимодействия компилятора и билд-системы ещё не утверждён (статья автора поддержки модулей в gcc, хз как отслеживать связанные документы и развитие ситуации). В тикете в cmake последний камент – появилась экспериментальная реализация.

Известно, что в build2 поддержку модулей завезли уже давно. Но популярность этого build2 – прямо скажем…

Какой генератор используется и компилятор?

Для Visual C++ в Cmake 3.21(вышла неделю назад 🙂) добавили поддержку: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5926

(в MSBuild поддержка была ещё раньше, просто жмёшь добавить файл, и выбираешь C++ Module Interface Unit https://imgur.com/a/9FTrByo ничего делать не нужно, просто пишешь код)

А вот статья про build2 и gcc: https://build2.org/blog/build2-cxx20-modules-gcc.xhtml

Cmake не поддерживает пока модули в gcc.

В рукописном Makefile можно заставить работать модули и с Visual C++ и с gcc…

ересь эти модули, собирай автотулзами, как великие диды делали

Ура. Осталось указатели запретить и можно пользоваться

зачем он такой нужен будет

ты один такой модный

Вроде ещё в 3.20 завозили экспериментальную поддержку для Ninja – https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5562

Но всё руки не доходят пощупать.

А если build2 сравнить с Cmake, в чем его приемущество?

Берёшь и запрещаешь на уровне требований к коду твоего проекта. При желании, можно даже для С проекта легко провернуть что-то такое. Просто сделав свою минимальную базовую библиотеку без указателей и на уровне требований к коду запретить использование указателей и прочих «опасных» вещей.

Но вот надо ли оно кому-то? С++ без всех тех возможностей, которые он унаследовал от С будет чем-то очень странным. Плохо портируемой Java? Ну уж тогда та же Java по лучше будет, или C# или Javascript. На них тоже же можно писать максимально просто, без монструозности, если хочется.

На них тоже же можно писать максимально просто, без монструозности, если хочется

На них можно. На плюсах нельзя

Просто надо использовать модные указатели из std и все будет хорошо.

вот введение по использованию модулей Visual C++ в консоли:

(может быть полезно если используете make, или хотите добавить поддержку модулей в вашу сборочную систему)

https://devblogs.microsoft.com/cppblog/using-cpp-modules-in-msvc-from-the-command-line-part-1/

Там для этой фичи надо накладывать патч на gcc, чтобы он выдавал данные в формате удобном для cmake. На мой взгляд это слишком сложно для того, чтобы просто поиграться. Проще нагородить голый Makefile, чтобы с модулями поиграться.

В рукописном Makefile можно заставить работать модули и с Visual C++ и с gcc…

Как бы вот заставить этот самый gcc создавать/искать каталог gcm.cache внутри target?.. Хрен разбери в этом егойном module mapper и его command line опциях.

ересь эти модули, собирай автотулзами, как великие диды делали

import std - 0.08s
#include all headers  - 3.43s

These are figures from my laptop, a modest Intel i-7 running windows, not so different from what a 
student or a casual programmer might use.  I used the Microsoft compiler. Each run was done 4 times 
and averaged. There were no dramatic outliers.

I was asked to point out that the numbers I present are from a yet-unoptimized implementation. I hope 
and expect to see even better performance in the future. Knowing the work on program representation 
by Gaby Dos Reis and me [IPR], I am not very surprised by these spectacular improvements. I also hope 
and expect to see similar spectacular results from the other module implementations.

Stroustrup 

http://open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2412r0.pdf

а как насчёт всех остальных сторонних библиотек

а как насчёт всех остальных сторонних библиотек

авторы этих библиотек должны будут написать модули, если хотят тоже получить ускорение компиляции.

Вот тут тип показал свои опыты с рефакторингом tinyxml2 на С++20 модули: https://youtu.be/KVsWIEw3TTw?t=943

авторы этих библиотек должны будут написать модули,

а если им влом будет

можно иметь в одном проекте и #include и import. Даже в стандартной библиотеке С++, заголовчные файлы C не включаются в модули, потому что модули не экспортируют макросы, так что всякие #include <cassert> // или <assert.h> и так будут совместно использоваться с модулями.

да — в своем проекте уже можно легко делать модулями — и в них же инклудить старым способом — никто не запрещает. — единственно прирост от модулей в таком случае будет менее заметен, чем если бы все было на модулях, но все равно надо в любом случае переводить.

По-моему модули больше не про производительность, а про контроль над видимостью/экспортом, никаких namespace details {} костылей. Да и внутри некоторой логической единицы - либы или жирного куска чего-то, нет никакого желания переходить на модули, старые инклуды ведь много мощнее (всякие X macro трюки над конфиг файлом, например).

Я так понимаю, что такая схема работать не будет (ну хотябы потому, что модуль гцц и шланга - два разных модулях из-за разного AST)? Есть либа_1 - «обычная» с нексолькими .cpp, и есть либа_2 - header only либа. Обе я могу собрать в модуль (один файл на выходе без всякого прицепа), и установить их в некий /usr/include?

PS: может появиться вопрос - для чего либе_1 модуль вместо статической либы? LTO из коробки.