Что такое хорошая структура проекта в C

Question

Я работал над проектами Java / J2ee, в которых я следую структуре Maven. Я хочу разработать [скажем, интерпретатор командной строки в linux {ubuntu}] на C. Я никогда не занимаюсь разработкой проектов на C. Я хочу знать, какой структуре проекта я должен следовать.

Answer 1

Нет единого «стандарта» для проекта C в этом аспекте. Конечно, если ваш проект небольшой, то часто все будет помещаться в один каталог.

Вы можете попробовать скачать несколько популярных проектов на C с открытым исходным кодом и взглянуть на их код.

На более низком уровне код должен быть модульным. Каждый модуль (который в C обычно проявляется в структуре данных с набором функций для работы с ним) имеет свою собственную пару файлов .h и .c, причем файл .h является открытым интерфейсом, видимым для клиентов модуль, а файл .c является частной реализацией.

Answer 2

Как сказал Эли Бендерский, все зависит от того, насколько сложен ваш проект.

Стандарт предлагает разбить как можно больше на библиотеки. Дело в том, что вы можете использовать свои библиотеки в другом месте. Например, это мой проект:

├── AUTHORS
├── COPYING
├── ChangeLog
├── Makefile.am
├── NEWS
├── README
├── configure.ac
├── libs
│   ├── featsel
│   │   ├── Makefile.am
│   │   ├── commander.c
│   │   ├── featsel
│   │   │   ├── commander.h
│   │   │   ├── feattuple.h
│   │   │   └── types.h
│   │   ├── featsel.h
│   │   ├── feattuple.c
│   │   ├── headers
│   │   │   └── datatypes.h
│   │   └── tests
│   │       ├── Makefile.am
│   │       └── test00.c
│   ├── mbox
│   │   ├── Makefile.am
│   │   ├── README
│   │   ├── control.c
│   │   ├── error.c
│   │   ├── headers
│   │   │   ├── datatypes.h
│   │   │   ├── mail.h
│   │   │   ├── parse.h
│   │   │   ├── split.h
│   │   │   └── strings.h
│   │   ├── interface.c
│   │   ├── mail.c
│   │   ├── mbox
│   │   │   ├── descriptor.h
│   │   │   ├── error.h
│   │   │   ├── mail.h
│   │   │   └── types.h
│   │   ├── mbox.h
│   │   ├── parse.c
│   │   ├── split.c
│   │   └── strings.c
│   └── thread_queue
│       ├── Makefile.am
│       ├── thrdqueue.c
│       └── thrdqueue.h
├── reconf
└── src
    ├── Makefile.am
    └── main.c

Лично я предпочитаю помещать все библиотеки в каталог libs. Каждая библиотека, кроме тривиальных, имеет свой собственный каталог частных заголовков и экспортирует открытый заголовок посредством каталога с тем же именем библиотеки.

Исходный файл самой программы находится в каталоге src.

Answer 3

Отдельные функции в модулях: файлы .c с подробностями / определениями реализации в сочетании с файлами .h с объявлениями.

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

Создавайте библиотеки, если у вас есть функциональные возможности, которые можно инкапсулировать и использовать повторно.

Answer 4

Предложение:

/project
    README
    LICENCE
    Makefile 
    # mabe configure.am Makefile.am etc. 
    # see http://en.wikipedia.org/wiki/GNU_build_system
    /src
        Makefile
        a.h
        a.c
        b.h
        b.c 
        /subunit
            x.h
            x.c
            y.h
            y.c
        # each file.c has a header file.h but not necessarily
        ...

Посмотрите на Nginx на github и просмотрите структуру проекта онлайн.

Answer 5

Вы можете обратиться к OpenSSL структуре проекта. Это известный открытый исходный код и хорошая структура проекта.