При разработке сего либо, нужна удобная среда для разработки и взаимодействия с проектом. А тогда были времена когда код писали в блокноте, собирали проект из командной строки, а отлаживали проект по записям в логах. Дикое было время.

Проект был многоплатформенным, и он должен был собираться и работает как на винде так и на линуксе, и на фрибсд. И у каждой из этих систем были некоторые тонкости. Конечно очень хорошо, что в ядре SMAUG изначально предусмотрели это, и в коде уже были нужные IFDEF конструкции. Но были несколько проблем, которые не так просто было победить. Одной из таких проблем была кодировка в файлах. Так как ядро русифицировалось, из-за этого возникали проблемы. Изначально, и я считаю что это была ошибка, кодовая страница для русских букв была KOI8. Нужно было выбрать CP-1251. Во первых, в 1251 в отличии от KOI8, был правильный порядок русских букв, что бы позволило не извращаться с кодом и не делать дополнительные костыли. Во вторых было бы меньше проблем для девелоперов которые сидели на виндовс машинах, хотя с этими проблемами вполне успешно поборолись. В основном это были проблемы с редакторами. И в третьих, сейчас было бы проще ковыряться в истории коммитов, и смотреть, а что же там раньше была за строка и на что её заменили.

Весь проект собирался GCC 2.95. Под линуксом и фрёй никакхи проблем с этим небыло. А вот со сборкой под вин32 пришлось немного помучатся с ним. Виндовая версия компилятора вообще отказывалась что-то делать, похоже с ней нужно было предварительно совершать танцы с бубном, но как это делать никто не знал. Оставалось два варианта, собирать по GygWin или MinGW. Под MinGW проект почти собирался, но нужно было ещё доводить напильником. А вот под GygWin всё собиралось, запускалось и была полная обвеска, которая была нужна для полноценной работы.

Но были проблемы со сборщиком кода. Make. Как выяснилось, их несколько, и у каждого есть свои особенности с форматом файла, и тот make который был на FreeBSD был не совместим с make на Linux и в CygWin. А так как проект собирался и работал на FreeBSD пришлось как-то выкручиваться. Сервер админил в то время Эрлис, и он не хотел устанавливать нужную версию make, считая что это будет как то влиять на его сервер, и он станет не стабильным. Я не знаю, что именно его пугало, вполне возможен вариант, что у него просто небыло времени установить нужную версию make.

Для контроля версий использовали CVS. На тот момент это было гораздо лучше, чем хранить все файлы в разных папках и в ручную сравнивать, кто и какие делал изменения. И использование CVS мне очень понравилось. :) Правда была одна проблема, и заключалась она в том, что ченж логи при комитах приходили у разных людей в разных кодировках. И это было крайне не удобно, когда смотришь кто и что сделал. Я эту проблему исправил, когда сервер переехал на другой хостинг, и как систему контроля версия я решил использовать SVN. В процессе конвертации истории комитов, я вручную сконвертировал все ченж логи в нужную кодировку. Автоматически это сделать не получилось, так как в некоторых ченж логах кодировка была дважды изменена. А работать в SVN было несколько удобней чем в CVS. Правда я так и не освоил там таги, я считал в то время, что они были нам просто не нужны. Так как у нас небыло никакой структуры или системы по которой мы работали, то у нас небыло и версий продукта. Но в какой-то момент я начал экспериментировать с кодом, и это ох как плохо аукнулось в последствии. По хорошему, нужно было сделать несколько веток разработки, одну - экспериментальную, а вторую - стабильную. И не вносить в стабильную версию свои эксперименты, так как они в какой-то момент сделали ядро совершенно не стабильным, а откатить эти изменения я уже не мог, так как на них наложились изменения других участников проекта. А сейчас, с появлением GIT это стало в разы проще делать, и вести сразу несколько веток одного кода, а в стабильную ветку вносить только проверенные изменения.

Вот с IDE была вообще печаль, и сильная. Так как в то время небыло таких редакторов как Notepad++ или Sublime Text или Brackets. Был только обычный блокнот и Вижуал Студия. Конечно были ещё разные редакторы, но у них небыло одной важной функции, они не умели переходить от места использования функции к месту её определения. Это было наверное самое важное, что мне требовалось от редактора кода. С вижуалстудией к сожалению у меня не сложилось взаимопонимание. Да и к тому же я не смог её заставить собирать проект, а так бы было очень удобно, к тому же полезно. А кроме того, нельзя было изменить кодовую страницу у файла, чтоб корректно отображать KOI8 в винде. Поэтому я не нашёл ничего лучшего, чем использовать редактор файл менеджера FAR с плагином, который умел переходить к определению функции, и у которого была нормальная подсветка кода. И мне этого вполне хватало. Хотя с начала было не очень удобно. А вот сейчас я бы заставил собираться проект в Вижуал Студии, или использовал другой нормальный редактор. Вообще, хороший редактор значительно ускоряет разработку. Благодаря удобствам редактора меньше времени тратится на редактирование кода и поиск ошибок.

А вот сколько времени может сэкономить хороший отладчик... Но это я в другой раз расскажу.

Оглавление.

http://longot.livejournal.com/356404.html