¿Qué es una buena estructura de proyecto en C?

He estado trabajando en proyectos Java/J2ee, en los que sigo la estructura Maven. quiero desarrollar [say a command line interpreter in linux {ubuntu}] en C. Nunca desarrollo proyectos en C. Quiero saber qué estructura de proyecto debo seguir.

No hay un “estándar” para el proyecto C en este aspecto. Ciertamente, si su proyecto es pequeño, con frecuencia todo se colocará en un solo directorio.

Puede intentar descargar algunos proyectos C populares de código abierto y echar un vistazo a su código.

En un nivel inferior, el código debe ser modular. Cada módulo (que en C suele manifestarse en una estructura de datos con un conjunto de funciones para actuar sobre él) tiene su propio par de archivos .h y .c, siendo el archivo .h la interfaz pública visible para los clientes del módulo. módulo, y el archivo .c es la implementación privada.

Como dijo Eli Bendersky, depende estrictamente de cuán complejo sea su proyecto.

El estándar sugiere dividir tanto como sea posible en bibliotecas. El punto es que es posible que desee reutilizar sus bibliotecas en otro lugar. Por ejemplo, este es un proyecto mío:

├── 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

Personalmente prefiero poner todas las bibliotecas en un libs directorio. Cada biblioteca, excepto las triviales, tiene su propio directorio de encabezado privado y exporta un encabezado público por medio de un directorio que tiene el mismo nombre de la biblioteca.

El archivo fuente del programa en sí se coloca en el directorio src.

Una sugerencia:

/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
        ...

Mirar Nginx en github y explore la estructura del proyecto en línea.

Funcionalidades separadas en módulos: archivos .c con detalles/definiciones de implementación combinados con archivos .h con declaraciones.

Trate de no contaminar los espacios de nombres usando estático para funciones y un prefijo de módulo común para símbolos externos.

Cree bibliotecas si tiene funcionalidades que se pueden encapsular y reutilizar.

Puedes referirte a la OpenSSL Estructura del proyecto. Es un código abierto famoso y tiene una buena estructura de proyecto.