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

Question

Я собираюсь начать работу над кроссплатформенной библиотекой, которая будет написана на C ++. В будущем я собираюсь реализовать привязки для других языков, таких как 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.

Answer 1

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

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

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

Answer 2

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

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

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

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

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

---

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

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

Структура папок повышения:

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 - вас не будет беспокоить структура папок build и bin.

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

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

Answer 3

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

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

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

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

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

Answer 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

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