Запрет включения h файла в другие модули кроме...

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

#error Ololoo

Multiple includes problem? ;) Решается по старинке очень просто:

/* whatever.h */
#ifndef WHATEVER_H
#define WHATEVER_H

/* some declarations */

__BEGIN_DECLS
/* some prototypes */
__END_DECLS

#endif
/* EOF */

Не, проблема не в multiple includes. Проблема в другом.

Вот есть поключаемый проект по работе с xlib. Сейчас он занимает один h и один с файл. В с файле есть функции типа int SmlGetScreenWidth (int * value); и int SmlGetScreenHeight (int * value); например. Но также в нем есть функции типа void setpixel(XImage * image, int color, int x, int y) например. Наружу (в h файле) торчат функции типа Sml*. setpixel не торчит. Так как с модуль уже разросся на 1330 строк, хочу его побить по функциональным частям - окна отдельно, эвенты отдельно, графика отдельно. А в проекте подключать только те h файлы, что требуются. Однако в таком случае мне нужно будет либо дублировать некоторые побочные функции в каждом с файле (типа void nullevent(XEvent * event) например) или иметь отдельный с/h файлы для побочных функций. Так вот, я пытаюсь придумать, как выдать ошибку/проигнорировать тот факт, если h модуль побочных функций будет подключен вне модулей, относящихся к проекту.

белый список

Что плохого в том, что кто-то подключит h-файл и не будет его использоваеть? Немножко времени на компиляцию пожалел?

Можно include path грамотно разрулить, если у тебя грамотно все разложено, то никто «левый» твой файл просто так не подключит.

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

нужно делать их недоступными для инклуда вне модулей. Например, кормить отдельную директорию с внутренними инклудами через -I или через симлинк.

Что плохого в том, что кто-то подключит h-файл и не будет его использоваеть?

Подключил - ок (но лучше бы ты этого не делал). Использование любой функции из него небезопасно. Я вызываю их из функций, в которых проводятся многочисленные проверки. Например тот же setpixel никто не мешает снаружи использовать так: (XImage *)&x, 0xFF00FF, 100, 150). Вот только в этот момент хорошо, если просто соседнюю переменную цепанет, а так по всей вероятности рухнет всё (хорошо, если сразу). Там ведь обычный memset без проверок.

Не распарсил. Пример можно?

По-моему слегка надуманная проблема: запретить все равно не выйдет, раз уж доступен исходный код.

Я бы, наверное, сделал отдельную папку, где будут лежать файлы, которые не нужно напрямую включать в другие проекты, либо действительно если не определена ALLOW_Y, выдать #warning или #error.

запретить все равно не выйдет, раз уж доступен исходный код.

Это скорее защита от дурака.

Делаем несколько директорий с инклудами в проекте, типа

  export/
     A.h
     B.h
     C.h
  local/
     X.h

CFLAGS += -Iexport -Ilocal

а для Y.с только -Iexport/. Как-то так.

Плюсую. Я у себя тоже разделяю интерфейсные и внутренние инклуды. Но это именно защита от дурака, для борьбы с этой проблемой на уровне DLL есть более кардинальное средство - dllexport/dllimport в __attribute__ или __declspec в зависимости от компилятора.