Cursed Earth: HOWTO для программистов

[IDoL]

Сразу оговорюсь - статья предназначена для тех, кто не работал со scons, git и gcc под Windows и хочет помочь в разработке. При желании продолжать разработку необходимо разобраться хотя бы с git, но лучше и со scons.

Итак, приступим.

Пункт первый. Получение исходного кода.
Для этого есть 2 пути:
скачать архив -src отсюда Cursed Earth Files
или получить код с последними изменениями и различными ветками кода из git-репозитория. Для этого у нас есть средство msysgit. Вы можете получить его отсюда: msysgit В комплекте предоставляется графическая оболочка пользователя а так же командная строка.
Если Вы собираетесь использовать GUI, то интерфейс довольно интуитивен. В GUI есть весьма удобный просмотрщик дерева git и истории комитов. Хотя GUI обладает, наверное, всеми возможностями git, рекомендую использовать консольный интерфейс. Таким образом Вы сможете заодно разобраться с этой прогрессивной системой управлениями версиями.
Если Вы будете пользоваться коммандной строкой — синтаксис одинаков с linux, основы описаны в файле документации от создателя проекта git.txt
В случае использования командной строки советую при установке выбрать опцию "Run from the Windows command prompt" которая позволит вызывать команды git из встроенной командной строки windows(cmd.exe).
Проверяем работоспособность git. В командной строке пишем

Код:

git --version

на выходе получаем:

Код:

git version 1.6.5.1.1367.gcd48

Получаем последний доступны исходный код основной ветки командой

Код:

git clone git://cursedearth.git.sourceforge.net/gitroot/cursedearth/cursedearth

из папки подготовленой под проект (пусть будет C:dev)
Так же стоит заметить несколько странное взаимодействие msysgit с репозиторием на sourceforge.net – сразу по получению кода команда git status выдает что некоторые файлы проекта были изменены и не закомичены почтовая рассылка.
В этом случае помогают команды:

Код:

git config core.autocrlf "false"
rm .git/index
git reset --hard

Не забываем устанавливать личную информацию и исключения для git (описано в документации к проекту).
Так или иначе мы получили исходный код в некоторой папке (допустим C:devcursedearth).

Пункт второй. Установка компилятора.
Мы будем использовать MinGW с gcc 4.4. Теоретически возможно использовать для сборки Visual C, но этот вариант не тестировался и не рекомендуется.
Не рекомендуется так же использование автоматического инсталятора MinGW-5.1.6, т.к. он устанавливает gcc 3.6, что может вызывать непредвиденные ошибки.
Установка MinGW элементарна.
Вы можете использовать мою сборку(включает freeglut) в таком случае вам необходимо будет разархивировать архив, расположить freeglut.dll(лежит в архиве) и измениить переменную среды - все это описано ниже.
Если решили собрать сами, то скачиваем все необходимые архивы:
binutils-2.19-1-mingw32-bin.tar.gz
gcc-c++-4.4.0-mingw32-bin.tar.gz
gcc-c++-4.4.0-mingw32-dll.tar.gz
gcc-core-4.4.0-mingw32-bin.tar.gz
gcc-core-4.4.0-mingw32-dll.tar.gz
gmp-4.2.4-mingw32-dll.tar.gz
make-3.81-20090914-mingw32-bin.tar.gz
mingwrt-3.17-mingw32-dev.tar.gz
mingwrt-3.17-mingw32-dll.tar.gz
mpfr-2.4.1-mingw32-dll.tar.gz
pthreads-w32-2.8.0-mingw32-dll.tar.gz
w32api-3.14-mingw32-dev.tar.gz
mingw-utils-0.4-1-mingw32-bin.tar.lzma

Распаковываем с совмещением каталогов в одну папку (допустим C:MinGW).
После этого нам необходимо установить freeglut.
Скачиваем, распаковываем в C:MinGW папки include и lib. Добавляем freeglut.dll в папку system32 находящуюся в папке WINDOWS.
После этого нам необходимо добавить

Код:

;C:mingwbin

в конец переменной среды PATH.
Проверяем — в командной строке выполняем

Код:

gcc -v

последние строки будут такими

Код:

Thread model: win32
gcc version 4.4.0 (GCC)

Из проблем тут можно сказать лишь о неправильной кодировке сообщений об ошибках. В английском они отсутствуют, так что решается удалением папки C:MinGWsharelocaleru (в моей сборке она уже отсутствует).

Пункт третий. Cистема сборки.
Рекомендуется использовать scons - систему сборки встроенную в проект.
Для этого необходимо установить Python 2.6.4 (Допустим в папку Cython26)
После этого устанавливаем scons
Добавляем в конец переменной стреды PATH

Код:

;C:Python26;C:Python26Scripts

Проверяем — в командной строке выполняем

Код:

python -V

Получаем

Код:

Python 2.6.4

На

Код:

scons -v

получим

Код:

SCons by Steven Knight et al.:
engine: v1.2.0.r3842,...

Итак система сборки и компилятор готовы. Через командную строку в папке C:devcursedearth выполним команду

Код:

scons

и получим готовые исполняемые файлы.
Насчет scons так же есть небольшой документ от создателя проекта scons.txt
Для редактирования в случае использования scons советую использовать, например, notepad++
Особенно удобно использовать с плагином Light Explorer (ставится через менеджер дополнений)

Так же мной была опробована разработка в Eclipse.
Сразу скажу, что данный метод хорош лишь тем, что довольно привычен после разработки в VC или (само собой) в eclipse. Возможны определенные проблемы в будущем в связи с изменением структуры каталогов и использованием дополнительных библиотек.
Если Вы все же решили использовать eclipse, советую устанавливать Eclipse IDE for C/C++ Developers
При запуске eclipse выбираем, что будем использовать папку C:dev(или любую другую папку) как WORKSPACE.
Тут можно выполнить проверку работоспособности, создав проект “hello world” на C и посмотреть на приветствие в консоли внизу экрана.
Итак приступим, создаем “C Project” → “Empty Project” c названием cursedearth. Убеждаемся что проект у нас будет располагаться в C:devcursedearth.
Первым делом лезем в настройки проекта “Project” → “Properties” → “C/C++ Build” → “Settings”
Выбираем “GCC C Compiler” добавляем в поле Command флаг компилятора -std=c99 - в итоге будет

Код:

gcc -std=c99

После этого переходим из “GCC C Compiler” в “MinGW C Linker” → “Libraries”
Добавляем в лист Libraries(-l) строчки

Код:

freeglut
opengl32
glu32

Применяем изменения нажав на кнопку Apply.
Далее из “C/C++ Build” мы переходим в “C/C++ General” → “Paths and Symbols”
Во вкладке “Includes” → “GNU C” у нас уже присутствуют директории ссылающиеся на MinGW. Добавим свою директорию “Add” → “C:/dev/cursedearth/game/include” или соответственно через WORKSPACE.
Перейдем во вкладку "Source Location" и добавим через “Add Folder” 3 папки с исходниками:

Код:

/game/src
/spikes/mprviewer/src
/spikes/texviewer/src

Удаляем из списка папку /cursedearth
Применяем изменения нажав на кнопку Apply. Закрываем настройки проекта.
В компилируемых исходниках (папка со значком C) game/src выбираем все файлы оканчивающиеся на _posix, а так же _opengl или _generic, которые дублируют друг друга, нажимаем правой кнопкой и выбираем “Exclude from build” → “Select All” → “OK”.
Тут стоит оговориться — мы можем за 1 раз собрать или texviewer или mprviewer.
В этом случае нам надо выбрать какой из main.c исключить и действовать аналогично.
Если Вы хотите подключить исходник к компиляции — в свойствах отключенного Правая кнопка → “Properties” → “C/C++ Build” снимаем галку “Exclude resource from build” и отключаем дублирующий исходник.
После всех этих манипуляций жмем Build(молоток) и Run(белый треугольник в зеленом круге).
Во вкладку Console внизу экрана высвечивается help по использованию запущеной программы.
Чтобы задать атрибуты запуска вызываем выпадающее меню (стрелочка справа от Run) “Run Configuration” → “C/C++ Application” → “*.exe” выбираем вкладку “Arguments”
для mprviewer надо добавить нечто вроде

Код:

-t C:/EI/Res/textures.res -f C:/EI/Maps/basegipat.mpr

для texviewer -

Код:

C:/EI/Res/textures.res

Не забываем добавить в C:devcursedearth.gitinfoexclude строчки:

Код:

.cproject
.project
Debug

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

[IDoL]

Есть дополнение — работа в Eclipse с использованием scons
Метод хорош тем же чем и предыдущий метод работы с Eclipse. Но, кроме того, использует систему сборки scons. Тем самым мы убираем проблемы с возможными изменениями структуры и добавлением файлов исходного кода.
Предпочтительно создать новый проект, если Вы использовали предыдущий способ работы с Eclipse.
Для этого метода Вам понадобится выполнить шаги по установке python и scons.
Для начала создаем новую переменную окружения — scons в которую запишем путь к scons.bat (например Cython26Scriptsscons.bat). После этого необходимо перезагрузить компьютер.
Некоторые шаги будут повторять предыдущий метод работы с Eclipse, но я, все же, продублирую весь необходимый текст.

Советую устанавливать Eclipse IDE for C/C++ Developers
При запуске eclipse выбираем, что будем использовать папку C:dev(или любую другую папку) как WORKSPACE.
Тут можно выполнить проверку работоспособности, создав проект “hello world” на C и посмотреть на приветствие в консоли внизу экрана.
Итак приступим, создаем “C Project” → “Empty Project” c названием cursedearth. Убеждаемся что проект у нас будет располагаться в C:devcursedearth.

Вместо шагов настройки проекта, Вы можете воспользоваться моим проектом — распакуйте файлы .cproject и .project в C:devcursedearth и замените существующие файлы созданые Eclipse. Обновите проект. Единственное что Вам осталось сделать — настроить запускаемые файлы (см. ниже) а также убедитесь что переменная окружения scons настроена.

Далее идут шаги настройки проекта
Первым делом лезем в настройки проекта “Project” → “Properties” → “C/C++ Build”
Следующие шаги необходимо будет выполнить для Release и Debug конфигураций.
Выбираем “Tool Chain Editon”, меняем состояние “Current builder” на “Gnu Make Builder”.
Переходим в “C/C++ Build”.
Убеждаемся что в "Builder Type" стоит “External Builder”. Снимаем флаги “Use default build command” и “Generate Makefiles automatically”. В поле “Build command” вводим
для Debug конфигурации

Код:

${scons} RELEASE=0

для Release

Код:

${scons}

В поле “Build directory” удаляем /Debug или /Release. В итоге получится нечто вроде

Код:

${workspace_loc:/cursedearth}

Переходим на вкладку “Behaviour”.
Очищаем поле “Build (Incremental build)”, заменяем команду в “Clean” на

Код:

-c

Применяем изменения нажав на кнопку Apply. Закрываем настройки проекта.
После всех этих манипуляций выбираем конфигурацию Debug или Release в “Project” → “Build Configuration → “Set Active”.
Жмем Build(молоток) и Run(белый треугольник в зеленом круге).

После этого идет настройка запускаемых собраных файлов.
Выбираем, допустим, mprviewer.exe, а в “Qualifier” - “/cursedearth/spikes/mprviewer/bin/mprviewer.exe” и жмем OK
Во вкладку Console внизу экрана высвечивается help по использованию запущеной программы.
Чтобы задать атрибуты запуска вызываем выпадающее меню (стрелочка справа от Run) “Run Configuration” → “C/C++ Application” → “mprviewer.exe”
Во вкладке Main устанавливаем поле “Build configuration” в состояние “Use active”. На вкладке “Arguments” для mprviewer надо добавить примерно следующее

Код:

-s 0.5 -b "C:EI" zone19

В этом же окне добавим дополнительную конфигурацию запуска для texviewer.
Жмем правой кнопкой на “C/C++ Application” → “New”.
Во вкладке Main вводим в поле “Name” – texviewer.exe, устанавливаем поле “Build configuration” в состояние Use active, а в поле “C/C++ Applicaton” вводим

Код:

spikes/texviewer/bin/texviewer.exe

.
На вкладке “Arguments” для texiewer надо добавить примерно следующее:

Код:

-d 100 "C:EIRestextures.res"

Применяем изменения и теперь мы можем выполнять последние собранные программы из Eclipse нажимая на Run.
Не забываем добавить в C:devcursedearth.gitinfoexclude строчки:

Код:

.cproject
.project
Debug

В eclipse под Linux настройка выполняется аналогично — разве что надо устанавливать плагин CDT. И выполнять только настройку проекта Eclipse.
Я полагаю пользователи Linux разберутся.

Интересно, было ли это HOWTO полезно кому то. Отпишитесь о своем опыте. И опять же при каких либо вопросах прошу обращаться.

[Sagrer]

мне будет полезно когда у меня руки дойдут таки собрать и изучить ).

Хотя вообще, имхо, всё должно быть проще - обычно прикладываются файлы для сборки проекта в какой-нить IDE для каждой поддерживаемой операционки а под linux-ами проект собирается каким-нить стандартным make-ом. Ещё есть такая классная штука как cmake - он, в частности, умеет делать мейкфайлы и файлы проектов для разных IDE.

З.Ы. я не спорю что система сборки - дело вкуса, мне вот например jam нравится.

З.Ы.¹2. Если ещё не - рекомендую заценить CodeBlocks - функционал сравним с VisualStudio и борландовскими IDE, кроссплатформ на основе wxWidgets - оно всё-таки не такое тормозное и монструозное как эклипс и изначально заточено чисто под разработку на си и си++, реально ей пользовался - остались очень приятные впечатления.

[IDoL]

CodeBlocks попробую. Сам монструозности Eclipse не рад совершенно. Да и на java кроме того...

А вот насчет нескольких систем сборки различных - не согласен. Настройки какието проекта для вызова системы сборки - это пожалуй(приложил свои файлы проекта eclipse). Но система сборки одна, чтобы какое IDE не использовали бы - не получили проблем. Поддерживать актуальными несколько систем сборок тоже - кто будет этим заниматься?

Сейчас используется scons.
Система сборки едина для win и linux поддерживает кросскомпиляцию, используется в профессиональном геймдеве. Так что думаю ее использование оправдает себя. Она конечно будет непривычна для многих. Например, т.к. я не знаю Python я разобрался с ней довольно поверхностно. Но это вообщемто не мешает работать с проектом(по крайней мере пока).

Если удастся использовать scons в CodeBlocks напишу еще пост

[Sagrer]

Но система сборки одна, чтобы какое IDE не использовали бы - не получили проблем.

фича в том что есть системы сборки - конкретно CMake - которые из себя не столько система сборки сколько генератор сценария для других систем сборки - уже под конкретный сборщик или IDE - т.е. имеется единый набор настроек, из которого уже генерится хоть makefile для make-а, хоть файлы проектов для VisualStudio или CodeBlocks (и там ещё какие-то есть)... может и для scons умеет генерировать.

[IDoL]

Да, я понял суть CMake`а. Для scons он не генерирует - у них разные, конкурирующие принципы работы.
Не имею ничего против него - лично с ним не сталкивался и не работал. Поисковик показывает, что и у той и у другой систем сборки есть свои плюсы и минусы. Так что не знаю есть ли смысл менять шило на мыло. На данный момент скрипты проекта для сборки scons уже отлажены под win и linux.
Да и вообще, полагаю, что предложения о смене системы сборки стоит писать v1s0r`у
Если уговорите - думаю напишу новую статью или эту поправлю

Более актуальный вопрос по теме на данный момент - для тех, кто работал в Code::Blocks.
Сборку спомощью scons настроил - довольно легко. Единственное что подозреваю, что дебаггер не будет работать.
Вопрос - как пускать.
Настроил запуск всех утилит через Tools, но это довольно криво.
В Build Target можно подставить путь только на один exe`шник (вставил путь к mprviewer), аргументы настроил. Но в проекте компилируется еще и texviewer, а после появятся и еще спайки. Хотя, наверное, в итоге это разделится на несколько таргетов сборки (ПОПРАВКА: уже разделено и можно собирать по 1 спайку), но проверять все спайки при сборке их всех разом не очень удобно - через tools разве что.
Может кто знает лучший способ?
Хотя вообщемто и так не плохо - разве что дублируются пути и аргументы для запуска.

PS Скоро выложу заметку по работе с Code::Blocks.

[Sagrer]

про CodeBlocks - просто сделай несколько проектов, отдельно для каждого исполняемого файла, и всё будет пучком. В одном Workspace там может быть несколько проектов. А таргеты - совсем другое вообще, это конфигурация сборки - либо собираем debug-версию либо release - обычно такое деление - т.е. там разные настройки линкера и компилера, но для одного набора сорцов.

Если scons сейчас собирает сразу всё - возможно стоит как-то разделить сборку чтобы каждый бинарник из scons-а собирался отдельной командой.

[IDoL]

Итак, проверил scons в Code::Blocks — решение волне работоспособное.
Однако Вам все же понадобится пройти шаги с получением исходного кода и установкой компилятора и scons.
Code::Blocks вы можете скачать по ссылке
Возможно также будет работать сборка со встроенным MinGW(без выполнения шага установки MinGW), но я не пробовал (если кто попробует и отпишется — было бы здорово).
Скачиваем, устанавливаем, выбираем workspace.

У нас 2 пути. Мы можем использовать несолько проектов (по совету Sagrer) или использовать таргеты. Эта заметка по использованию таргетов(т.к. большинство исходного кода едино), но Вы можете пойти другим путем через создание нескольких проектов по 1 для каждого спайка — это делается аналогично и в итоге получается примерно одинаково по удобству. Для scons [все же] присутствуют флаги для компиляции отдельных спайков.

Создаем новый проект “Empty Project” назовем его cursedearth. Подменяем путь “Folder to create project in” на C:dev. Убеждаемся, что “Resulting filename” будет содержать строку C:devcursedearthcursedearth.cbp. На самом деле, мы можем использовать для файла проекта любую директорию но так наиболее наглядно при работе с одним проектом. Next.
Тут мы создадим таргеты для релиза и дебага mprviewer`а. Конфигурации будут соответственно такими: mprviewer_debug и mprviewer_release. Очищаем опции с директориями результатов для обеих конфигураций. Finish.
В окне Management появился проект вложеный в наш workspace.

Вся последующая настройка уже выполнена для mprviewer и texviewer в моем проекте (файл проекта и Makefile). Вы можете разархивировать его в папку с созданым проектом замещая существующие файлы. Притом конфигурировать таргеты в этом случае не обязательно.
Однако аргументы для выполнения спайков расчитаны на то, что ресурсы игры лежат в папке “EI” в рабочей папке проекта (например C:devcursedearthEI — путь к EI относительный). Следовательно Вы можете или изменить аргументы или добавить ресурсы в папку EI. Еслы вы создаете папку EI не забудьте добавить ее в исключения git, в дополнение к остальным исключениям(см. ниже).

Выберем его и добавим файлы проекта Правая кнопка → “Add files recursively...”. Тут выберем папку в которой находятся все наши файлы (C:devcursedearth). По умолчанию выбрана папка проекта, так что если Вы создали проект в папке с исходном кодом жмем OK выбираем все файлы Select All, OK, выбираем все таргеты Select All, OK. Т. к. Code::Blocks не обращает внимание на то, какие файлы находятся в папке с проектом, нам будет необходимо выполнять эти действия каждый раз при появлении новых файлов с исходным кодом — или просто после обновления из git(частично будут бесполезно выполненые действия, но будет так же и уверенность что ничего не пропустили).
Лезем в настройки проекта “Project” → “Properties”.
Во вкладке “Project settings” установим флажок “This is a custom Makefile”.
Во вкладке “Build Targets” для mprviewer_debug установим “Output filename” во чтото вроде

Код:

spikesmprviewerbini386-win32-mingwdebugmprviewer.exe

в зависимости от архитектуры и платформы. Снимем флажки “Auto-generate filename prefix” и “Auto-generate filename extension”. Для mprviewer_release -

Код:

spikesmprviewerbini386-win32-mingwreleasemprviewer.exe

и снимем те же флажки.
Следующие действия необходимо будет выполнять при появлении новых спайков (если Вы выбрали работать с таргетами). Здесь будет рассмотрено создание таргетов для texviewer.
В панели “Build Targets” выбираем и создаем копии для mprviewer_debug и mprviewer_release кнопкой Duplicate, называя их texviewer_debug и texviewer_release. И подменим “Output filename” в дублированых таргетах на

Код:

spikestexviewerbini386-win32-mingwdebugtexviewer.exe

и

Код:

spikestexviewerbini386-win32-mingwreleasetexviewer.exe

соответственно. Жмем ОК.
Создадим в папке C:devcursedearth файл с именем Makefile(без расширения) со следующим содержанием:

Код:

all:
    scons

mprviewer_release:
    scons mprviewer
mprviewer_debug:
    scons RELEASE=0 mprviewer
cleanmprviewer_release:
    scons mprviewer -c
cleanmprviewer_debug:
    scons RELEASE=0 mprviewer -c

texviewer_release:
    scons texviewer
texviewer_debug:
    scons RELEASE=0 texviewer
cleantexviewer_release:
    scons texviewer -c
cleantexviewer_debug:
    scons RELEASE=0 texviewer -c

Для каждого нового спайка Вам понадобится создать новую секцию(при использовании таргетов). Для нескольких проектов Вы можете использовать несколько Makefile`ов а можете один, но тогда Вам придется называть таргеты примерно так же как в этой заметке.
Сейчас мы можем попробовать, что у нас получилось используя Build(шестеренка) и Run(синий треугольник) или сразу Build and Run(шестеренка с красным треугольником).
Нам покажется экран с помощью по спайку, где будут описаны правила использования и аргументы. Закрываем появившуюся командную строку.
Теперь нам необходимо передать аргументы для собраных файлов. “Project” → “Set programs' arguments...”. В появившемся окне для обоих таргетов mprviewer вставим в текстбокс “Program Arguments” нечто вроде

Код:

-s 0.5 -f -b "C:EI" zone13

Для таргетов texviewer -

Код:

-d 50 "C:EIRestextures.res"

Для новых спайков смотрите аргументы показаные в командной строке, при вызове без аргументов.
Учтите что после добавлении строки с аргументами для таргета необходимо нажать на ОК. После этого придется заново вызвать окно для задания аргументов.
Теперь спомощью Run вызывается спайк с необходимыми аргментами.
Сохраним проект.
Не забывайте закрывать командную строку после завершения работы спайка.
Так же не забываем добавить в C:devcursedearth.gitinfoexclude строчки:

Код:

Makefile
*.cbp
*.layout

Ну вот наверное и все.

[v1s0r]

Спасибо, я тоже попробую CodeBlocks. А то kate + konsole очень уж сурово

Пару слов по scons. Если бы мы делали игру с ресурсами (то бишь с художниками и моделерами), то без мощной скриптовой сборки не выжить. В ПЗ же у нас ресурсы готовы, нужно только написать программную часть. Я согласен с Sagrer, и make и cmake справятся. Я выбрал сконс по привычке и навязывать его не хочу.

И ничего не мешает использовать несколько систем сборки, лишь бы они работали на одних данных. Если кто захочет - ради бога! Я сам работал в сочетании VisualStudio + scons. VS собирал только бинарь, а scons и бинарь и компилировал все арт-данные в уровни (кучей питоновского кода, даже не представляю, кто-бы ещё смог с этим справиться).

[Sagrer]

всё это очень хорошо, но всё-таки я не понимаю одного - зачем заставлять каждого новичка-программера проделывать всю эту монструозную инструкцию если можно просто включить в состав исходника те же cbp-файлы проектов? Завязка на конеретные пути, по которым лежат исходники и зависимости обходится обычно с помощью переменных среды, а инструкция по сборке обычно сводится к нескольким пунктам вида "скачайте то-то и то-то", "пропишите путь куда вы распаковали то-то в переменную такую-то" и "откройте вон тот файлик, выбирайте таргет release и нажмите buid all".

Просто из опыта - мои инструкции по сборке из 3-6 пунктов порой серъезно мешали кое-кому нормально выполнить сборку (пусть эти кто-то были и не совсем программеры), и я их до сих пор считаю монструозными (но увы это не линух, автоматизации сборки до уровня configure - make - make install к сожалению нет).

Я сам работал в сочетании VisualStudio + scons. VS собирал только бинарь, а scons и бинарь и компилировал все арт-данные в уровни (кучей питоновского кода, даже не представляю, кто-бы ещё смог с этим справиться).

у меня с этим вполне справлялся набор скриптиков внутри bat-файлов %). Ну, там ещё было несколько самописных консольных утилиток для всяких вспомогательных целей (они выкладывались как GGBuildTools). Как ни странно - в bat-ах могут быть скрипты ничуть не менее изощрённые чем в баше %).

[v1s0r]

Завязка на конеретные пути, по которым лежат исходники и зависимости обходится обычно с помощью переменных среды, а инструкция по сборке обычно сводится к нескольким пунктам вида "скачайте то-то и то-то", "пропишите путь куда вы распаковали то-то в переменную такую-то" и "откройте вон тот файлик, выбирайте таргет release и нажмите buid all".
[right][snapback]40002[/snapback][/right]

Хм, мне видится инструкция в одну строчку

Код:

scons all

Реально, если установлен питон, сконс, GLUT, компилятор, всё соберётся. Если чего-то нет, будет вразумительное сообщение об ошибке. Возможно, сейчас и невразумительное, но будет)) Работа над сисемой сборки ещё предстоит.

[IDoL]

Я согласен инструкция не совсем простая. Однако взглянем критически - установка гит это крайне полезно и в итоге удобно, но можно работать и без него скачав src, хотя это будет, конечно, не самый новый код.

Установка MinGW - если пустится сборка через codeblocks со встроенным компилятором(не знаю какую версию использует, подцепит ли его scons) - будет отлично и ставится в 1 клик. сконс можно на VC компилятор завязать(по умолчанию так и есть), но это надо следить за тем, как это будет работать.

Scons и Python - устанавливается на самом деле вполне очевидными далее-далее.

Файлы проекта завязать на переменные окружения - это идея. Думаю попробую.
Их можно выложить как есть, но выкладывать их в гит это черезчур - тогда ктото должен будет их мэйнтэйнить.
Да и для всех IDE все равно проекты не насоздавать...
То же самое с несколькими системами сборки...

[Sagrer]

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

ну, вот мне приходилось более-менее ковырять исходники wxWidgets и StarDict - так вот, в StarDict для вендов приложены файлы проектов для DevCpp.

А в wxWidgets вообще целая куча проектных файлов под разные среды разработки и makefile-ов. VisualStudio и CodeBlocks в их числе. Они конечно не мэйнтэйнят их все, но всё-равно они подерживают в актуальном состоянии файлы CMake-а, а он уже всё остальное генерирует.

[IDoL]

Ну, CMake, как и scons, требует установки. Не знаю насколько интуитивна генерация проектов спомощью CMake и стоит ли заставлять тех же новичков генерировать их. Хотя автогенерация проектов это здорово.
Конечно писать заметку для каждого IDE конечно не получится. Но Makefile поддерживают думаю почти все IDE так что использование scons через него может иметь смысл.

Если есть опыт работы с CMake и желание помочь, то думаю все будут только за. И уж для CMake скрипты можно и в гит положить. Лично я конечно могу с ним поразбираться и чего то слепить но это займет какоето время. Насчет CMake скриптов от v1s0r могу сказать, наблюдая развитие проекта, что система сборки не самое приоритетное задание. На текущий момент существует не так много возможностей для начинающих программистов.
Надеюсь, что каждый сможет помочь с проектом через какое то время. Но на данный момент реальность такова, что только довольно усидчивые люди будут разбираться. И пройти довольно нудную инструкцию займет все же не так много времени особенно используя приложеные сборки и проекты и переходя по ссылкам из статьи

Думаю примерно так. Прошу заметить, что это не искуственный отсев недостойных, а просто приоритетное планирование

[Sagrer]

Не знаю насколько интуитивна генерация проектов спомощью CMake и стоит ли заставлять тех же новичков генерировать их.

в том и смысл чтобы новичкам вообще не требовалось вручную генерировать файлы проектов, составлять makefile-ы итд итп - т.е. вышепомянутая команда wxWidgets после изменений внутри конфигов cmake просто перегенерирует все проектные файлы для IDE и иже с ними, и заливается это одним коммитом, вот и всё ). Задача новичка - установить и настроить зависимости, прописать если надо что-то в переменные среды и запустить сборку проекта.

[IDoL]

Так, первое тут - не получилось подключить переменные среды в аргументы. Пробовал %EIPATH%(win-style), $EIPATH и $(EIPATH). Никаких дополнительных переменных проекта, кроме переменных сборки не нашел. Ну еще есть Global Variable Editor, но это похоже вообще не то. Требуется подсказка.
Насчет того что открыть проект проще - согласен.
Однако все так же остается вопрос. Допустим сгенерируем файлы проекта. Однако тогда мы должны проводить тесты сборки разными компиляторами. Тоесть, например, Microsoft не держит и похоже не собирается держать стандарт C99. Мы же используем его. Насколько много придется менять - вопрос. У всех компиляторов могут быть какието косяки которые приведут к каким то вопросам и (возможно) костыльным решениям. Если же использовать MinGW во избежание проблем, то мы например можем прикладывать такой вот Makefile и просто выбросить его в гит. Думаю все IDE работающие с MinGW могут работать и с make.

[Sagrer]

странно, должны работать пути вроде $(WX_DIR)/include

Я их прописывал на вкладке Search directories в Project build options.

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

необязательно. Пишем что, мол, "поддерживается только сборка gcc-ой" и всё. Если CMake умеет генерить vcproj-ы это же не значит что обязательно надо это использовать %).

С другой стороны - если движок, собранный мелкомягким компиллером под вендами будет иметь какие-то преимущества (быстрее работать например) - то почему бы и не добавить немного костылей в код.

[v1s0r]

Тоесть, например, Microsoft не держит и похоже не собирается держать стандарт C99. Мы же используем его. Насколько много придется менять - вопрос. У всех компиляторов могут быть какието косяки которые приведут к каким то вопросам и (возможно) костыльным решениям.
[right][snapback]40008[/snapback][/right]

На данный момент я использую много фич C99. Переписать на C89 будет тяжело.
С другой стороны, меня удивляет, почему VS не поддерживает его. 10 лет прошло с принятия стандарта!!! За это время GCC реализовал подавляющее количество нововведений (в версиях >= 4.2, по-моему).

[IDoL]

странно, должны работать пути вроде $(WX_DIR)/include
Я их прописывал на вкладке Search directories в Project build options.
[right][snapback]40009[/snapback][/right]

Нет, не получается. Но это все же не опции сборки. Тоесть нам нужно чтобы выполнилось нечто вроде 'mprviewer -f -d 0.1 "C:EI" zone12' и заменить "C:EI" на переменную окружения. Это уже не сборка а выполнение по сути.

На данный момент я использую много фич C99. Переписать на C89 будет тяжело.
С другой стороны, меня удивляет, почему VS не поддерживает его. 10 лет прошло с принятия стандарта!!! За это время GCC реализовал подавляющее количество нововведений (в версиях >= 4.2, по-моему).
[right][snapback]40010[/snapback][/right]

Честно говоря не особо слежу. Возможно какието окольные пути существуют... Но я подозреваю что это из-за особого отношения МС к стандартам. Да и им бы наверное хотелось чтобы как можно больше всего на чем нибудь вроде C# писалось с привязкой к Win. Но это уже холиварная тема и оффтоп по сути

[Sagrer]

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