KISS — ничего не генерить, а держать, что нужно, в «exported.h».

KISS — ничего не генерить, а держать, что нужно, в «exported.h».

Два чая этому вот.

Или если это разные модули твоей либы - пусть у них отдельные хедеры так и остануться.

Ты не понял проблемы - поправил хедер в либке, а юзеровский файл остался как был - из-за разницы сигнатур функция больше не работает.

Это ты не понял.

Хедеры в либке можно изначально разделить на экспортируемые и неэкспортируемые. Дублировать ни к чему. Пример - ffmpeg. Есть много всяких .h, почти все экспортируемые, а есть такие, как internal.h, которые не экспортируются.

Нет, таки понял. Юзверь и пользует твою «exproted.h», или как ты его там назовёшь. Да хоть «lib.h»

Смысл в общем в том, что у тебя по 2 .h на модуль — внешний и внутренний. Или один внешний и куча внутренних. Но из одного в другой ничего не перетекает. Т.ч. и генерить ничего не надо.

Просто, дубово, удобно.

Нет, таки понял. Юзверь и пользует твою «exproted.h», или как ты его там назовёшь. Да хоть «lib.h»

Смотри:

a.h, a.c - сорцы
b.h, b.c - сорцы

сорцы содержат пометки, тудушки, комменты и пр.

я компиляю либу, получаю lib.so

теперь юзер чтобы использовать какую-то функцию из либы должен подключить к проекту lib.h

Вопрос про синхронизацию сигнатур в a.h + b.h и lib.h

Ещё примеры — widgets в X11 (athena).

Пользователь использует, наример, Intrinsic.h. А для своих дел есть ещё IntrinsicI.h и IntrinsicP.h.

Есть сорцы: a.h, a.c, b.h, b.c и(!) lib.h, в котором и лежит, то, что должен видеть пользователь. Содержания lib.h в a.h и b.h нет.

У меня автоматически сгенеренный lib.h 803 строки. Апдейтить его руками пытаясь найти enum или сигнатуру того что нужно поправить неудобно.

Ну, что сказать? Примеры, как это делается IRL, тебе привели. Меняй подход или мучайся дальше.

По крайней мере я не припомню ниодного проекта, где бы были авто-сгенерённые шапки.

К тому же — юзьверьская шапка — это чать документации API с комментариями и пояснениями.

Так ты один раз оперделись что у тебя там экспортируемо. Ты же архитектуру какую никакую придумывал, не? Ато выглядит как: «посоны я тут понаписал чего-то, а теперь понять не могу нахрена я этого понаписал и куда это все рассовывать».

У меня автоматически сгенеренный lib.h

Но зачем? Либо выноси (а не переноси) публичное API в отдельный хедер, либо пиши модульно (man static function), тогда проблема не возникает.

Либо выноси (а не переноси) публичное API в отдельный хедер

803 строки. Апдейтить его руками пытаясь найти enum или сигнатуру того что нужно поправить неудобно.

либо пиши модульно (man static function), тогда проблема не возникает.

Модулей сейчас 32, ожидается больше. задолбается юзер по одному их прописывать.

Зачем тащить все экспорты в один хеадер? Вот пусть каждый модуль имеет свой хеадер и за него отвечает.

А в ему они все сразу в одном месте нужны? От прописывания пары хеадеров ещё никто не умирал, и заодно есть чёткое представление, что конкретно ты ииспользуешь.

задолбается юзер по одному их прописывать.

В GTK+ 3 смотрел?

Я смотрел на его внешний вид, мне хватило, спасибо.

Тебе нужен umbrella header. Делаешь mylib/mylib.h, который только и делает, что инклудит mylib/mod1.h, mylib/mod2.h, mylib/types.h, etc. А все приватные объявления кладешь в modN-internal.h, которые можно не показывать юзеру при необходимости.

А посмотрел бы не спрашивал, кого наказываешь-то?

Гордый он.

KISS — ничего не генерить, а держать, что нужно, в «exported.h».

Поддерживаю.

Для C++ есть http://www.lazycplusplus.com/. Возможно, оно подойдёт и для C.

Оно?

https://github.com/andik/makeheaders (дока на сайте)

Я такую уже написал, с единственной разнице что я у меня он ищет по /* E */, /* E+ */ и /* E- */.