LINUX.ORG.RU

C++20 modules + gnu make — поделитесь success story?

 , ,


0

5

Нашёл у себя в makefile камент:

# После перехода на gcc:11 попробовал заюзать модули (объявил модуль test_MyClass_module в файле test_MyClass.cpp),
# но в .d-файлах генерируется что-то невразумительное, e.g.:
#     main.o: test_MyClass_module.c++m
#     CXX_IMPORTS += "test_MyClass_module.c++m"
# Да и QtCreator модуль не находит. Независимо от того, пихаю я gcm.cache в корень проекта или в target
# (для чего вызывал makefile из target, подкрутив в нём все пути).

Что делать с этими *.c++m и CXX_IMPORTS, откуда брать *.c++m и как всё это юзать в makefile? Хрен бы с ним с QtCreator пока что.

★★★★★
Ответ на: комментарий от fsb4000

нашёл такую бумагу:

Гы, она у меня открыта в браузере, как и предыдущая. Первую щас перечитываю, со второго раза идею понял. Авось как вторую перечитаю, что-то прояснится.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от fsb4000

Но что-то ветка у меня не собирается:

Ага, вспомнил, только начав перечитывать бумагу: это пропозал по добавлению фичей в сам make. Пока что моя чуйка говорит, что пробовать все эти сырые костыли ещё слишком рано. :(

UPD: И как раз в этой второй бумаге он описывает, как должны выглядеть правила для *.c++m. Не вполне допонял при чём тут патченый make… может на обычном попробовать?… А, блин, туплю: интеграция с mapper-server же… Короче всё плохо.

// По первой бумаге (p1184r1) нашёл у себя на системе:

/usr/libexec/gcc/x86_64-pc-linux-gnu/11.2.0/g++-mapper-server
/usr/libexec/gcc/x86_64-w64-mingw32/11.1.0/g++-mapper-server

и сходу от них видна только одна польза (если запустить их вручную и добавить опцию –mapper-server как в бумаге написано): у них есть параметр, указывающий расположение кеша модулей, т.е. можно перекинуть gcm.cache внутрь target.

// Эх, сделать бы свой make с блекджеком и шлюхами у которого makefile был бы сорцом на плюсах – т.е. с внутренним DSL возможностью нормально императивно генерить правила внутри самого makefile. Короче, воспоминания о sbt для скалы покоя не дают. UPD: Надо бы глянуть на suckless.org: может там уже есть какой-нибудь suckless make?

dimgel ★★★★★
() автор топика
Последнее исправление: dimgel (всего исправлений: 4)
Ответ на: комментарий от dimgel

императивно
makefile

Выбери что-то одно.

возможностью нормально императивно генерить правила внутри самого makefile

GNU Make умеет перечитывать зависимые вложенные make-файлы и перестраивать дерево целей.

LamerOk ★★★★★
()
Ответ на: комментарий от kawaii_neko

На языке общего назначения не надо было бы в стотыщпятьсотый раз реализовывать ни строковые функции, ни прочие функции общего назначения, ни интерпретаторы, ни eval. Собственно работа с графом зависимостей – это малая часть кода make, и при этом – единственная его существенная фича. И API к этому графу на высокоуровневом языке дало бы на выходе гораздо более гибкий и мощный инструмент. Всё упирается в выразительность языка общего назначения для написания внутренних DSL. На скале это можно сделать на ура (да собственно и сделано в sbt), но jvm – не наш метод; а на плюсах я хз как нынче DSL-и модно писать и на что они годятся. Впрочем, синтаксис правил всё равно будет более громоздким чем у makefile; да и влом. Так что не выёживаюсь и продолжаю жрать чё дают.

dimgel ★★★★★
() автор топика
Последнее исправление: dimgel (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.