Estrutura de diretório para uma biblioteca C++

Question

Estou trabalhando em uma biblioteca C++.Em última análise, gostaria de disponibilizá-lo publicamente para múltiplas plataformas (pelo menos Linux e Windows), juntamente com alguns exemplos e Pitão ligações.O trabalho está progredindo bem, mas no momento o projeto está bastante confuso, construído exclusivamente em e para Visual C++ e não é multiplataforma.

Portanto, sinto que uma limpeza é necessária.A primeira coisa que gostaria de melhorar é a estrutura de diretórios do projeto.Eu gostaria de criar uma estrutura que seja adequada para o Automake ferramentas para permitir fácil compilação em múltiplas plataformas, mas nunca as usei antes.Como ainda estarei fazendo (a maior parte) codificação no Visual Studio, precisarei de um lugar para manter meu projeto do Visual Studio e também os arquivos de solução.

Tentei pesquisar no Google termos como "estrutura de diretórios da biblioteca C++", mas nada de útil parece surgir.Encontrei algumas diretrizes muito básicas, mas nenhuma solução cristalina.

Ao examinar algumas bibliotecas de código aberto, descobri o seguinte:

\mylib
    \mylib <source files, read somewhere to avoid 'src' directory>
        \include? or just mix .cpp and .h
    \bin <compiled examples, where to put the sources?>
    \python <Python bindings stuff>
    \lib <compiled library>
    \projects <VC++ project files, .sln goes in project root?>
    \include? 
    README
    AUTHORS
    ...

Não tenho pouca/pouca experiência anterior com projetos de desenvolvimento multiplataforma/código aberto e estou bastante surpreso por não conseguir encontrar boas diretrizes sobre como estruturar tal projeto.

Como se deveria estruturar geralmente tal projeto de biblioteca?O que pode ser recomendado para ler?Existem alguns bons exemplos?

Answer 1

Uma coisa que é muito comum entre as bibliotecas do UNIX é que elas são organizadas de modo que:

./         Makefile and configure scripts.
./src      General sources
./include  Header files that expose the public interface and are to be installed
./lib      Library build directory
./bin      Tools build directory
./tools    Tools sources
./test     Test suites that should be run during a `make test`

Reflete um pouco o sistema de arquivos UNIX tradicional em /usr Onde:

/usr/src      Sometimes contains sources for installed programs
/usr/include  Default include directory
/usr/lib      Standard library install path
/usr/share/projectname   Contains files specific to the project.

Claro, estes podem acabar em /usr/local (que é o prefixo de instalação padrão para o GNU AutoConf) e eles podem não aderir a essa estrutura.

Não há regra dura e rápida. Pessoalmente, não organizo as coisas dessa maneira. (Eu evito usar um ./src/ Diretório, exceto os maiores projetos, por exemplo. Eu também não uso o AutoTools, preferindo cmake.)

Minha sugestão para você é que você deve escolher um layout de diretório que faz sentido para você (e sua equipe). Faça o que for mais sensato para o ambiente de desenvolvimento escolhido, construir ferramentas e controle de origem.

Answer 2

Eu não acho que haja realmente boas diretrizes para isso. A maior parte disso é apenas preferência pessoal. Certos IDEs determinarão uma estrutura básica para você, no entanto. O Visual Studio, por exemplo, criará uma pasta bin separada que é dividida em subpastas de depuração e liberação. No VS, isso faz sentido quando você está compilando seu código usando alvos diferentes. (Modo de depuração, modo de liberação.)

Como Greyfade diz, use um layout que faça sentido para você. Se alguém não gostar, eles terão que reestruturá -lo. Felizmente, a maioria dos usuários ficará feliz com a estrutura que você escolheu. (A menos que seja realmente bagunçado.)

Answer 3

Acho que a biblioteca WxWidgets (código aberto) é um bom exemplo. Eles suportam muitas plataformas diferentes (Win32, Mac OS X, Linux, FreeBSD, Solaris, Wince ...) e compiladores (MSVC, GCC, CodeWarrior, Watcom, etc.). Você pode ver o layout da árvore aqui:

https://svn.wxwidgets.org/svn/wx/wxwidgets/trunk/

Answer 4

Existe uma convenção incrível que descobri recentemente que pode ser útil: O layout do forcado (também em GitHub).

Resumindo, subseção 1.3 afirma que:

O PFL prescreve vários diretórios que devem aparecer na raiz da árvore do projeto.Nem todos os diretórios são necessários, mas eles têm uma finalidade designada e nenhum outro diretório no sistema de arquivos pode assumir a função de um desses diretórios.Ou seja, esses diretórios devem ser os utilizados caso sua finalidade seja necessária.

Outros diretórios não devem aparecer na raiz.

build/:Um diretório especial que não deve ser considerado parte da fonte do projeto.Usado para armazenar resultados de compilação efêmeros.não deve ser verificado no controle de origem.Se estiver usando o controle de origem, deve ser ignorado usando listas de ignorados do controle de origem.

src/:Local principal da fonte compilável.Deve estar presente para projetos com componentes compilados que não utilizam submódulos.Na presença de include/, também contém cabeçalhos privados.

include/:Diretório para cabeçalhos públicos.Pode estar presente.Pode ser omitido para projetos que não fazem distinção entre cabeçalhos privados/públicos.Pode ser omitido para projetos que utilizam submódulos.

tests/:Diretório para testes.

examples/:Diretório para amostras e exemplos.

external/:Diretório para pacotes/projetos a serem usados ​​pelo projeto, mas não editados como parte do projeto.

extras/:Diretório contendo submódulos extras/opcionais para o projeto.

data/:Diretório que contém aspectos do projeto que não são do código-fonte.Isso pode incluir gráficos e arquivos de marcação.

tools/:Diretório contendo utilitários de desenvolvimento, como scripts de construção e refatoração

docs/:Diretório para documentação do projeto.

libs/:Diretório para os principais submódulos do projeto.

Além disso, acho que o extras/ diretório é onde suas ligações Python deve ir.

Answer 5

Eu realmente posso recomendar você usando o cmake ... é para desenvolvimento de plataformas cruzadas e é muito mais flexível que o automóvel, use o cmake e você poderá escrever código de plataforma cruzada com sua própria estrutura de direção em todos os sistemas.