Подтвердить что ты не робот

Лучшая структура папок для кросс-платформенной библиотеки С++ и привязок

Я собираюсь начать работу над кросс-платформенной библиотекой, которая будет написана на С++. В будущем я намерен реализовать привязки для других языков, таких как Python, Java и т.д. Библиотека должна быть доступна на основных платформах: win32, Linux и Mac OSX.

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

Я хотел бы создать оптимальную структуру папок, прежде чем я начну хранить вещи в Subversion.

Я думаю о чем-то вроде:

/project                    //Top level folder

        /bin                //Binaries ready for deployment
            /linux_amd64    //Linux AMD64 platform
                  /debug    //Debug build - duplicated in all platforms
                  /release  //Release build - duplicated in all platforms
            /linux_i386     //Linux 32-bit platform
            /macosx         //Mac OS X
            /win32          //Windows 32-bit platform
                  /cygwin   //Windows 32-bit platform compiled with Cygwin
                  /vs.net   //Windows 32-bit platform compiled with Visual Studio .NET
            /win64          //Windows 64-bit platform

        /build              //Make and build files, IDE project files
            /linux_amd64    //Linux AMD64 platform
            /linux_i386     //Linux 32-bit platform
            /macosx         //Mac OS X
            /win32          //Windows 32-bit platform
            /win64          //Windows 64-bit platform

        /config             //Configuration files that accompany the binaries

        /data               //Data files that accompany the binaries

        /doc                //Documentation

        /lib                //External or third-party libraries
            /platforms      //Platform-specific code for ...
                      /linux_amd64    //Linux AMD64 platform
                      /linux_i386     //Linux 32-bit platform
                      /macosx         //Mac OS X
                      /win32          //Windows 32-bit platform
                      /win64          //Windows 64-bit platform
            /src            //Available library source code in subfolders

        /src                //Source code tree - this will contain main.cpp
            /bindings       //Bindings to other languages such as ...
                      /python
                      /java
            /h              //Header files
            /modules        //Platform-independent modules, components or subprojects
            /platforms      //Platform-specific code for ...
                      /linux_amd64 //Linux AMD64 platform-specific code
                      /linux_i386  //Linux 32-bit platform-specific code
                      /macosx
                      /win32       //Windows 32-bit platform-specific code
                      /win64       //Windows 64-bit platform

        /test               //Automated test scripts

Если у вас есть предложения, я бы хотел их услышать. Интересно, есть ли инструмент, который может помочь создать эту структуру.

Я планирую использовать CMake и Subversion.

4b9b3361

ОТВЕТЫ

Ответ 1

Структура выглядит хорошо для меня, но есть несколько моментов:

  • нормально ли отделять заголовок С++ и исходные файлы в разных каталогах, или, может быть, есть структура в каталоге модулей, который вы не показываете?
  • вы, вероятно, хотите, чтобы каталоги помещали промежуточные файлы, такие как *.obj в
  • вам понадобятся разные каталоги для отладки и выпуска выходных файлов
  • может быть полезен каталог для инсталляторов, таких как InnoSetup, и их установочные файлы. Вы должны принять философское решение о том, следует ли управлять версиями этих

Что касается инструментов для создания структуры, то вам понадобится всего несколько минут, потраченных на создание bash script, поэтому для всех платформ необходимо иметь одинаковые инструменты (например, bash).

Ответ 2

Почему вам нужны разные папки для папок для двоичных файлов? Вы собираетесь создать этот исходный код в разных форматах, но с одинаковой файловой системой?

Если да, я думаю, что вам нужны также специальные папки для компилятора.

Почему вы не используете разные папки для сборки отладки и выпуска, возможно, unicode и не-unicode, однопотоковые или многопоточные сборки?

Посмотрите на bjam или Scons, замените их. Возможно, вам не нужны разные папки в каталоге сборки.

Я думаю, будет лучше, если все модули из каталога "modules" будут содержать "test" каталог для проверки self.

И последний - см. boost library, эта платофременная независимая библиотека, которая имеет приятную структуру.

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

Создание структуры папок:

boost - root dir
- boost - library header lib ( for users )
- libs - library source dir ( one dir per lib )
    - build - library build files ( if they are needed )
    - doc - documentation files
    - example - sample programs
    - src - library source files
    - test - programs and srcipts for testing module
- bin - created by bjam build system
    - libs
        - <lib-name>
            for all compiled folders from libs [example|test|build]
                - <compiler-name>/<[static|dynamic]-link>/<[debug|release]>/<[threading mode]>
                    contain builded [obj|dll|lib|pdb|so|o|etc] files see detailed information in bjam build system

- doc
- tools

Если вы выберете bjam - вы не будете беспокоиться о структуре сборки и корзины bin.

Кроме того, ваш libs/src/dir может содержать собственные для всех файлов платформы и пару dir для файлов платформы.

Я не вижу серьезных проблем в ваших папках structre, возможно, вы увидите их при запуске прототипа проекта.

Ответ 3

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

Вы собираетесь обслуживать Win64? Это станет все более важной целью.

Не помещайте свои промежуточные файлы сборки где-нибудь под деревом, проверяемым в svn. Если вы это сделаете, в зависимости от ваших клиентских инструментов svn, они будут генерировать много шума в виде файлов, которые не находятся в репозитории. Это затрудняет просмотр файлов, которые вы добавили, которые должны находиться в репозитории.

Вместо этого, если ваш компилятор позволяет это, поместите промежуточные каталоги в одну сторону.

В противном случае убедитесь, что вы добавили все промежуточные каталоги в свои свойства исключения svn. Некоторые GUI делают это проще, чем другие (черепаха в Windows, Cornerstone или версии на OS/X).

Ответ 4

Могу ли я предложить не использовать архитектуру для категоризации файлов сборки?

Я пытался применить предлагаемую структуру папок, но я не мог найти правильное место для размещения общих определений Makefile Linux и файлов свойств Visual Studio. Как насчет следующего:

/project
   /build
      /linux
      /macosx
      /win32 (or win)

И пример может включать:

/project
   /build
      /linux
         Make.defs
         Makefile  [i386, amd64]
      /win32
         /VC8
            /<project>
               <project>.vcproj
            <solution>.sln  [Win32, x64]
         /VC11
            /<project>
               <project>.vcxproj
            <solution>.sln  [Win32, x64, ARM]

Если вы не хотите определять сборки архитектуры через конфигурации, как насчет другого слоя папок под типами плат?

/project
   /build
      /linux
         /linux_amd64
         /linux_i386
      /macosx
         /?
      /win32 (or win)
         /win32
         /win64

Если у данного проекта не будет общих файлов сборки для платформы, исходной структуры будет достаточно.