2012-06-14 2 views
11

Я хочу документировать библиотеку с помощью doxygen. Документация будет считываться двумя классами пользователей: пользователи, которые интересуются только внешним API и разработчиками, которые хотят видеть документацию для всех функций/структур.Отдельная «внутренняя» из «внешней» документации в doxygen

Я хотел бы использовать для разделения файлов doxy для создания документации. Есть ли какой-нибудь «тег», который я могу добавить в блок комментариев, чтобы отметить комментарий как внутренний/внешний?

+0

На каком языке представлена ​​библиотека? В C#, например, я считаю, что doxygen может смотреть на модификаторы функции 'public' vs' internal'. – Blorgbeard

+0

библиотека написана на C – timos

ответ

16

Set INTERNAL_DOCS:

# The INTERNAL_DOCS tag determines if documentation 
# that is typed after a \internal command is included. If the tag is set 
# to NO (the default) then the documentation will be excluded. 
# Set it to YES to include the internal documentation. 

INTERNAL_DOCS   = NO 

В документации, вы можете использовать \internal или @internal на то, что зернистость вы хотите (файл, функция и т.д.).

+0

Вы избавили меня от боли, пытаясь получить cond или если вы делаете то же самое. –

+0

the \ internal почти никогда не делает то, что вы думаете. Он скрывает документацию, а не классы или функции, с которыми она связана. Я бы настоятельно рекомендовал использовать \ cond /\ endcond, упомянутый Mad Physicist в другом ответе. – gnash117

9

Используйте команду \ дир:

\internal (@internal) имеет только степень детализации для текущего комментария блока. Это не позволяет вам каким-либо образом, чтобы скрыть определение структуры в C.

Самый простой способ сделать это поместить

\ конд ВНУТРЕННЕГО

в верхней части внутреннего заголовка файла и

\ endcond

внизу. Затем, в файле конфигурации, добавьте

ENABLED_SECTIONS = ВНУТРЕННЯЯ

, чтобы внутренние элементы, которые будут включены в документацию.

Этот способ также рекомендуется пользователями Doxygen, например. here

0

Это простое решение, которое использует тот факт, что вы можете обычно отличать внутреннюю и внешнюю части вашего кода от файлов.

Вы можете просто ограничить входные файлы только те файлы заголовков, которые вы хотите выставить на внешней документации:

# For internal, we parse all files 
INPUT = ./ 
# For external, we parse only the files containing the public interface 
INPUT = include/header1.hpp include/header2.hpp 

Это имеет то преимущество, что исходные файлы не должны быть изменены (с \internal или @internal).

Смежные вопросы