SD

[kika]

Обнаружил оппортюнитю. В мире, оказывается, нету нормальной широко распространенной build system/SCM. Замечательные в своей непостижимости autotools просто непригодны ни на чем кроме юникса, не менее замечательный CMake просто халтурно сделан - у него отличная идея и где-то примерно на треть хороший дизайн, а две трети дизайна и реализация просто мусор. qmake пригоден для использования только в коммерческой версии Qt и кроме того весьма ограничен в возможностях.
Я сильно подозреваю что купив за десять тыщ мильенов фунтов долларов какой-нибудь перфорс я получу такую же помойку, только еще и без исходников.

Либо это никому не надо, либо до сих пор никто не нагнулся и не поднял с земли деньги.

Compliance test для любой билдовой системы: напишите "makefile" в ней, который позволит собрать из одних исходников в один проход статическую и динамическую библиотеку под линукс. А отдельный проход под виндами соберет статическую и динамическую библиотеку под венды. Если тест пройден, сделайте тоже самое, но со сборкой промежуточной convenience library.

Мы в результате остановились на CMake + autotools для того, на что CMake просто непригоден.

Comments

Re: p4

[pzz.livejournal.com]

Я так не думаю. И то и другое означает лишь добавление интерфейса к той функциональности, которая в SVN'е уже есть.

Метки я-ля перфорс это именованные объекты (кажется даже версионированные), состоящие из комментария и списка пар {имя файла; версия}. Такую штуку можно добавить в SVN, даже не модифицируя сервера, если договориться, что метки хранятся в виде файлов в определенном (желательно текстовом) формате и в определенном месте.

Мне бы лично хватило бы и более простой конструкции, а именно метка содержащая не список файлов, а ссылку на директорию (с указанием версии), ко всем файлам которой она рекурсивно относится.

По сравнению с перфорсовскими ченжсетами в SVN'е не хватает следующего:
- в SVN'е нет команды, позволяющей получить список файлов, которые поменялись в релизе N (в SVN'е, как и в P4 релиз это чиселка, характеризующая версию репозитория в целом, а не конкретного файла). Но есть команда, позволяющая получить diff между версиями N и M (в частности, между N-1 и N - почти то, что нужно). Поскольку diff имплицитно :-) содержит список файлов, осталось только отломить тело diff'а, чтобы сделать эту команду немного побыстрее. Это потребует изменения на стороне сервера.
- svc ci пытается засубмитеть все измененные файлы, которые он нашел, от текущей директории и дальше по дереву. Как и в CVS'е, тебя отправляют поредактировать текстовый файл, в котором сверку можно написать log, а снизу - список измененных файлов. P4 делает практически то же самое, но только я могу еще поредактировать список файлов - удалить из него файлы, и это будет означать, что они не будут засубмиченны в этот раз. Это удобно, когда делаешь сразу несколько изменений в проекте, но оформить их хочется отдельными субмитами.
- P4 позволяет поредактировать log и список файлов, но в репозиторий пока ничего не сохранять, а отложить на попозже. При этом создается объект по фамилии changeset, который по существу представляет не что иное, как текстовый файл с log message и списком файлов. Хранится он, правда, на сервере, и тем самым виден другим пользователям, но по-моему, его с таким же успехом можно было бы хранить локально и другим пользователям не показывать.
- diff между версиями N-1 и N можно получить из P4 в точно таком же формате, в котором создаются changeset'ы. Это делает changeset не write-only объектом. Кстати, поредактировать можно только еще не засубмиченный changeset, что вполне логично.

Я не думаю, что это сложно реализовать. Почти все запчасти в SVN'е для этого уже есть...