Здравствуйте, CreatorCray, Вы писали:

C>>Коллеги, я правильно понял, что precompiled headers вы не используете?
CC>На ручнике нет, при правильной организации include (каждый header первым включает master header в котором собраны основные FW + SDK includes) нормальный промышленный компилер разруливает это всё сам.

Прости, пожалуйста: 1. "на ручнике" — имеется в виду "явно не прописываются"? 2. под "промышленным", в данном контексте, что следует понимать?

Здравствуйте, Zhendos, Вы писали:

C>>Коллеги, я правильно понял, что precompiled headers вы не используете?

Z>Я использую. clang/gcc не накладывают никаких ограничений на то как должен
Z>писать код программист при использовании "precompiled headers".
Z>Можно передавать "-include" параметр gcc/clang, можно рядом с каждым заголовчным
Z>файлом положить ".pch" / ".gch" файл, и gcc/clang если их увидят, будут использовать их,
Z>а не парсить исходники.

Вопрос в данном случае о работоспособности концепции "проверка самодостаточности инклудника". Я сам gcc (ну и опосредованно clang) использую + cmake + ninja, и получается, что при включении какого-либо инклудника в precompiled используемые в нем инклудники на автомате становятся видны остальным.

Здравствуйте, Conductor, Вы писали:

C>Здравствуйте, Zhendos, Вы писали:

C>Вопрос в данном случае о работоспособности концепции "проверка самодостаточности инклудника". Я сам gcc (ну и опосредованно clang) использую + cmake + ninja, и получается, что при включении какого-либо инклудника в precompiled используемые в нем инклудники на автомате становятся видны остальным.

Ну здесь два рубежа защиты,
во-первых cmake'овском target_precompile_headers есть опция PRIVATE,
и значит за пределах библиотеки этот заголовочный файл не вылезет,
во-вторых CI, которая собриает без "precompile headers",
уж там-то все ошибки вылезут.

Здравствуйте, Zhendos, Вы писали:

C>>Вопрос в данном случае о работоспособности концепции "проверка самодостаточности инклудника". Я сам gcc (ну и опосредованно clang) использую + cmake + ninja, и получается, что при включении какого-либо инклудника в precompiled используемые в нем инклудники на автомате становятся видны остальным.

Z>Ну здесь два рубежа защиты,
Z>во-первых cmake'овском target_precompile_headers есть опция PRIVATE,
Z>и значит за пределах библиотеки этот заголовочный файл не вылезет,
Z>во-вторых CI, которая собриает без "precompile headers",
Z>уж там-то все ошибки вылезут.

Да понятно, что всё можно сделать, используя как технические методы, так и организационные. Вопрос только в стоимости овчинки и выделки, целесообразности и важности этих мероприятий. Один случай, когда либа отдаётся на сторону как продукт (особенно в исходниках), тогда да, API-хедера должны быть вылизаны по полной. И другой случай если это внутренние компоненты, рамки продукта не покидающие. Понятно, что единообразие приводит к меньшему бардаку, но преувеличивать значение и рассматривать самодостаточность всех хедеров как архиважный и архипринципиальный вопрос я бы не стал. Всё же в рамках большого продукта достаточное количество более существенных проблем.

Здравствуйте, Conductor, Вы писали:

C>1. "на ручнике" — имеется в виду "явно не прописываются"?
Имеется в виду не надо производить какие то специальные действия, типа копирования файлов или прописывание конкретного файла в опции компилятора.
Компилятор сам анализирует где и что можно reuse

C>2. под "промышленным", в данном контексте, что следует понимать?
Тот же ICC например.

Здравствуйте, Zhendos, Вы писали:

П>>2) #include без путей. Вот везде в сорцах инклуды практически везде без путей — чисто имя файла без всего вот такого "somelib/impl/helpers/bla-bla-helper.h", а тупо #include "bla-bla-helper.h" или даже <bla-bla-helper.h>, но компилятору зато подсовываются все всевозможные пути поиска инклудов. Есть аргумент за то, чтобы ничего не менять — всё же собирается и работает. Но это какое-то гавно

Z>Наоборот, очень важно не использовать или ограниченно использовать пути
Z>в "больших" проектах. В "больших" проектах очень важно контролировать граф зависимостей
Z>на уровне системы сборки, а не на уровне исходников. И не использование путей в include,
Z>заставляет прописывать зависимости в системе сборки.
Z>Например:

Z>

Z>add_library(foo OBJECT foo.cpp foo.hpp)
Z>target_include_directories(foo PUBLIC libfoo/includes)

Z>target_link_libraries(otherlib PRIVATE foo) # (1)
Z>

Z>Без строчки (1) include foo.hpp выдаст ошибку, а вот если путь указать то работать будет,
Z>но отсутствие явно прописанных зависимостей не позволяет ускорить сборку.

Есть такая практика — собирать каждый таргет в своей песочнице. Тогда забытая зависимость — неважно, укажешь абсолютный путь или относительный — сразу вылезет. Симлинков на нужные папки с хедерами не окажется в песочнице.
Правда, я не знаю, как это можно сделать в голом симейке.
В ниндзе и базеле это решается с помощью магии. (Я эту магию сам не настраивал, но вовсю пользуюсь).