SD

[kika]

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

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

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

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

Comments

Re: p4

[krotoff.livejournal.com]

О!
Все лучше люди здесь у Кирилла собрались ;-)

С p4 живу последние четыре года. Очень даже удачная штука. Но с SVN сравнить не могу, ибо не знаком.

Как build-систему его использовать никак нельзя. Как ее часть, ответственную за извлечение требуемого из репозитория - очень даже можно (так и делаем).

С аккаунтами по-моему ты что-то не так делаешь. Один P4USER может существовать на произвольном количестве компьютеров и иметь произвольное количество P4CLIENTs.По крайней мере до сих пор мы в ограничения вписываемся без проблем (полсотни юзеров с несколькими клиентами каждый).

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

Графический клиент - очень на любителя. Юниксовый - так вообще на мазохиста-любителя. command-line удобный.

Re: p4

[pzz.livejournal.com]

Те же ребята, что сделали P4, сделали бесплатный Jam - более дружелюбную замену make.

Я примерно понимаю, что Кириллу не нравится в Jam'е. Jam это по сути make, а Кириллу хочется тулзу, которая для его любимой Visual Studio генерит проекты.

Кстати, на Jam'е сидит PalmOne. Я в свое время всласть натрахался с их билдовой системой, когда мне понадобилось что-то собрать немного не так, как они привыкли.

С аккаунтами - да, немного напутал. Я уже забыл, что P4USER != P4CLIENT. Но необходимость иметь несколько клиентов меня лично напрягала. Мне больше нравится ad hoc способ создания клиента в стиле CVS/SVN.

Что до гуйни, меня в этом вопросе можно смело не слушать, т.к. я гуйней почти не пользуюсь. Но все же P4'я гуйня по-моему крайний пример неудобства :-)

Очень удачной штукой P4 я назвать не могу. По-моему, это очередной "CVS better that CVS". P4, наверное, лучший из тех, кого я видел в этом классе. На вскидку не хватает:
- в P4 нет нормального rename. В CVS'е тоже нет. Более-менее есть только в SVN'е
- Многие команды в P4 и CVS'е лазают на сервер без нужды, и от этого работают слишком медленно (и вообще не работают без интернета)
- за время, которое CVS'у надо, чтобы поставить метку на исходники линуксного ядра, можно успеть пообедать. У SVN'а с этим хорошо. Про P4 не помню.
- Branch system в CVS'е, конечно, brain damaged, но в P4/SVN'е нету и такой :-(
- Никто из них не умеет при merge изменений из бранча A в бранч B учитывать, какие изменения были уже раньше помержены
- Мне бы очень хотелось иметь иерархию репозиториев, чтобы я мог, скажем, работать некоторое время в своем локальном репозитории, а проталкивать изменения в общий репозиторий лишь когда изменения достаточно созрели. Меня бы на худой конец устроил бы и приватный бранч, если бы не см. выше. Но локальный репозиторий лучше - с ним можно работать в оффлайне.
- Никто из них не поддерживает концепцию shared files а ля VSS. Эта штука очень полезна, чтобы шарить сишные хидеры между несколькими проектами.
- Никто из них не поддерживает легкого способа перенести приект из одного репозитория в другой (хорошо бы еще чтобы другой системы) с сохранением всей истории.
- Никто из них не позволяет легко получить версию того кода, который у меня лежит в рабочей копии в виде, пригодном для вставления в сишную программу - чтобы потом можно было написать эту чиселку в лог, и сопоставить лог с версией исходников. У P4 есть что-то подобное, но ему надо слазить на сервер, что вносит раздражающую задержку в процесс сборки программы. В CVS'е такого в принципе не может быть, т.к. у каждого файла своя версия. Про SVN не помню, но меня тоже что-то не устроило :-)
- Опечатку в log message совершенно невозможно исправить
- Ошибочный submit нельзя просто удалить
- Если файл случайно ушел не с тем changeset'ом, эту ошибку исправить нельзя. К CVS'у это не относится за неимением changeset'ов

Re: p4

[krotoff.livejournal.com]

В-общем почти целиком согласен, с двумя поправочками:
- опечатку в log message исправить таки-можно в p4.
- насчет merge изменений - по-моему тоже не совсем точно. В этом плане p4 - лучшее, что я трогал. Он помнит историю предыдущих merge по p4 integrate и помнит ее достаточно хорошо. Можно даже mergить на уровне отдельного changelistа, опустив часть промежуточной истории. Что опять-таки удобно.

Относительно идеологии и возможности ad hocов, для разработчика, конечно, не очень удобно, но для построения build-системы - самое то.

Re: p4

[pzz.livejournal.com]

Насчет merge ты по-моему не прав.

Я имею ввиду следующее. У меня есть 2 параллельные ветки. Скажем, current и stable. Изменения вносятся в обе, причем часто независимо. Время от времени надо перенести изменения (часто кучкой) из одной ветки в другую.

Я хочу, чтобы source control понимал, какие изменения уже перенесены, а какие нет.

Насколько я понимаю, P4 так не умеет. А умеет он вместо того следующее: перенести изменения из ветки A в ветку B от версии 1.0 до версии 1.2, и запомнить, что B теперь уже отбранчена от 1.2, а не от 1.0, как было раньше.

Я не прав?

P.S. Вот Git, насколько я понимаю из его описания, делает это именно таким методом, как я описал. Насколько я понимаю его устройство, в Git'е по большому счету вообще нет такого объекта как файл. А первичным является именно изменение. Файл как таковой - это не более чем точка в истории файла (последовательность изменений, которая довела файл из небытия до такой жизни). Поэтому именно в плане работы с изменениями Git очень гибок.

Но это все мои домыслы - я его сам не щупал, только пару статей про него прочитал :-)

Re: p4

[krotoff.livejournal.com]

Не прав.

Тут, что называется, show me the code:
http://www.finnov.net/~ank/p4.txt
Проще, чем описывать словами.

Коротко, если я во время интеграции что-то подправил руками, или изменения были сделаны в отдельной ветке, то в следующий раз они для интеграции предлагаться не будут. Что удобно.
Интеграцию отдельного changelist показывать не стал, но там все очень похоже.