SD

Dec. 15th, 2006 04:19 pm
kika: (Default)
[personal profile] kika
Обнаружил оппортюнитю. В мире, оказывается, нету нормальной широко распространенной build system/SCM. Замечательные в своей непостижимости autotools просто непригодны ни на чем кроме юникса, не менее замечательный CMake просто халтурно сделан - у него отличная идея и где-то примерно на треть хороший дизайн, а две трети дизайна и реализация просто мусор. qmake пригоден для использования только в коммерческой версии Qt и кроме того весьма ограничен в возможностях.
Я сильно подозреваю что купив за десять тыщ мильенов фунтов долларов какой-нибудь перфорс я получу такую же помойку, только еще и без исходников.

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

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

Мы в результате остановились на CMake + autotools для того, на что CMake просто непригоден.
Page 1 of 3 << [1] [2] [3] >>

Date: 2006-12-15 01:23 pm (UTC)
From: [identity profile] rblaze.livejournal.com
Как можно собрать в один проход статическую и динамическую библиотеки, если одни надо собирать с -fPIC, а другие без?
Если задача "один раз набрать make", то она успешно решена в BSD на обычном make, нет в этом ничего сложного. Сборка под винду будет отличаться не сильно: компиляторы по умолчанию вписать другие да расширения у библиотек.

Смешивать систему сборки и систему управления конфигурациями вообще вредно, у них разные задачи. А причем тут autotools вообще непонятно, у них совершенно другая задача.

Date: 2006-12-15 01:38 pm (UTC)
From: [identity profile] kika.livejournal.com
Я SCM приписал потом, думая что так понятнее будет. Некоторые и GNU Make называют SCM.

Ну а что мне делать если мне надо собрать обе библиотеки? Ну вот надо и все, потом один таргет собирается со статикой, а второй - с .so Ну жизнь такая.

Обычный make всем хорош, кроме того что его надо писать вручную. И когда понадобится (а понадобится) добавить MacOS таргеты, придется написать все опять.
Ну а последний гвоздь в гроб обычного мейка - это невозможность интеграции с MS VS. CMake и qmake это обеспечивают (с кучей непересекающихся оговорок, к сожалению).

Date: 2006-12-15 01:51 pm (UTC)
From: [identity profile] rblaze.livejournal.com
Ну надо так надо :) В FreeBSDшной инфраструктуре это делается простым добавлением строчки "INSTALL_PIC_ARCHIVE=yes" в Makefile, в результате все объектники собираются два раза и на выходе получается .a и .so.
Перенос на другую платформу сведется к изменению имен бинарников и параметров сборки, если там нет каких-то кардинальных отличий типа взятия файлов из SQL вместо FS.

А вот "автомагической" сборки под очередную платформу увы, не достичь. autotools в этом, на мой взгляд, не помогают: всё равно надо напильником затачивать. Дождаться, когда эту работу сделают другие, да еще под все мыслимые платформы, жизни не хватит.

Date: 2006-12-15 02:01 pm (UTC)
From: [identity profile] kika.livejournal.com
autotools решают очень много проблем в плане несовместимостей разных юниксов друг с другом. Напильничком может и надо пройтись, но это не сравнить с выпиливанием этим же напильником из цельной болванки. Другой вопрос что в общем и целом "разных юниксов" уже не осталось. Остался линукс и местами FreeBSD и (отчасти) MacOS/X. Усе. Если мы пишем енд-юзерский софт, то бсдей можно пренебречь, если серверный - то нельзя, ну или по крайней мере нежелательно.
А поддержка мульена экзотических юниксов нужна либо уже очень mature программным продуктам (когда мы сожрали 99% рынка и единственная цель в окошке - добирать по 0.1% каждый год) либо заказному софту.
Поэтому у нас автотулс получается просто генератором мейкфайлов под линукс и все.

p4

Date: 2006-12-15 03:08 pm (UTC)
From: [identity profile] vvs2002.livejournal.com
Perforce все-таки не build tool. Или подразумевался "условный" перфорс?

Re: p4

Date: 2006-12-15 03:13 pm (UTC)
From: [identity profile] kika.livejournal.com
я с перфорсом не знаком особо, поэтому подразумевался именно условный, то есть некое дорогое проприетарное решение с хорошим потенциалом customer lock in :-)
Я вообще не шоплю в эту сторону, у меня ни бюджета на эти игрушки нет, ни желания lockinиться.

Re: p4

Date: 2006-12-15 03:22 pm (UTC)
From: [identity profile] vvs2002.livejournal.com
"Неусловный" p4 как VCS очень неплох. У нас бюджета пока вообще ни на что нет, но уже подумываем купить его. Так как SVN заыбал уже.

Date: 2006-12-15 03:27 pm (UTC)
From: [identity profile] cherjr.livejournal.com
аристов ваяет что-то на эту тему. могу выяснить статус

Re: p4

Date: 2006-12-15 03:30 pm (UTC)
From: [identity profile] kika.livejournal.com
А на что еще смотрели, кроме SVN?

Date: 2006-12-15 03:33 pm (UTC)
From: [identity profile] kika.livejournal.com
Узнай, интересно.

Re: p4

Date: 2006-12-15 04:30 pm (UTC)
From: [identity profile] vvs2002.livejournal.com
Из халявного? CVS. А из предыдущего combined experience с ClearCase, p4, StarTeam и прости-хоссподи pvcs, p4 вызывает самые положительные эмоции.

Основные плюсы - стабилен, быстр, интегрируется со всем, поддерживает branching, atomic commits.

Re: p4

Date: 2006-12-15 05:01 pm (UTC)
From: [identity profile] kika.livejournal.com
Ну а какой-нибудь git скажем?

Re: p4

Date: 2006-12-15 05:14 pm (UTC)
From: [identity profile] pzz.livejournal.com
В SVN'е по сравнению с p4 не хватает очень немногого. А именно:
- нормальных меток (а не копий дерева)
- changeset'ов как отдельных объектов, с которыми можно делать всякие полезные штуки. Например, выгрузить changeset в виде списка файлов и diff'а, разложить файлы, которые уже модифицированны в рабочей копии по нескольким changeset'ам прежде, чем субмитить их в репозиторий и т.п.

У P4 есть свои недостатки в сравнении с SVN'ом. Например:
- переименование файлов и директорий теряет старую history (вернее, ее можно посмотреть по старому имени объекта, но жизнь нового начинается с момента переименования). В SVN'е этого не происходит
- P4 хранит метаданные для рабочей копии неизвестно где, а SVN - в директориях .svn прямо в рабочей копии. В результате, у P4 рабочую копию не переместишь просто так на другое место
- каждая рабочая копия регистрируется у P4 на сервере. В результате, если у меня 2 компутера, я вынужден держать 2 аккаунта. Кроме очевидных неудобств, надо еще понимать, что деньги P4 берет именно per-account.
- svn diff очень быстрая команда, т.к. сравнивает локальные файлы на диске. У перфорса и CVS'а эта команда требует слазить на сервер
- P4 не очень хорош для offline'овой работы, когда файл сначала поменяешь, а потом когда-нибудь выложишь, когда доберешься до интернета
- виндовая гуйня (TortoiseSVN) у SVN'а по-моему дружелюбнее, чем то страшилище, которое прилагается к P4

Может быть, кто-нибудь возбудится, и доделает к SVN'у недостающую функциональность? :-)

Re: p4

Date: 2006-12-15 06:02 pm (UTC)
From: [identity profile] kika.livejournal.com
У меня есть ощущение что оба недостатка SVN, которые ты перечислил, по порядку величины тянут примерно на разработку нового VCS.

Re: p4

Date: 2006-12-15 06:17 pm (UTC)
From: [identity profile] krotoff.livejournal.com
О!
Все лучше люди здесь у Кирилла собрались ;-)

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

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

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

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

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

Re: p4

Date: 2006-12-15 06:33 pm (UTC)
From: [identity profile] vadimchen.livejournal.com
А что не так с SVN?

Re: p4

Date: 2006-12-15 06:41 pm (UTC)
From: [identity profile] 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'е для этого уже есть...

Re: p4

Date: 2006-12-15 07:01 pm (UTC)
From: [identity profile] vvs2002.livejournal.com
Несколько замечаний по p4:
- про переименования согласен
- перемещение в другое место настраивается через workspace
- насчет account'ов ты неправ. Можно под одним акаунтом иметь бесконечное количество воркспэйсов. Чем, когда лицензий не хватает, можно злоупотреблять.
- насчет diff'a не совсем понял. Если за время моего работы над файлом в репозитории появилась новая версия, как именно сравнение локальных файлов может помочь?
- оба гуя suck. Tortoise интегрируется с explorer'ом, что делает его совсем бесполезным для тех, кто им не пользуется в качестве файлменеджера.

Re: p4

Date: 2006-12-15 07:05 pm (UTC)
From: [identity profile] vvs2002.livejournal.com
репозиторий ломается подозрительно часто. Грубо говоря на его супорт времени тратиться подозрительно много. Где-то на порядок больше, чем на более серьезный проект в p4.

Re: p4

Date: 2006-12-15 07:21 pm (UTC)
From: [identity profile] 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

Date: 2006-12-15 07:28 pm (UTC)
From: [identity profile] pzz.livejournal.com
Про сравнения: самый частый случай, это сравнение рабочей копией с последней версией, взятой из репозитория. SVN хранит эту последнюю версию у себя за щекой локально, поэтому такой diff работает очень быстро. Конечно, diff между абстрактными версиями M и N требует обращения к серверу, и работает медленнее.

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

Перемещение в другое место через workspace, если не ошибаюсь, настраивается только через полный checkout проекта в новое место. Я работал в проекте, в котором полных чекаут занимал сутки. С точки зрения такого проекта в перфорсе нет возможности переместить файлы в другое место.

Про аккаунты мне уже объяснили.

Все гуи suck, но в виндовсе и консоль sucks, да еще и с причмокиванием - приходится пользоваться гуем хотя бы иногда :-)

Re: p4

Date: 2006-12-15 07:30 pm (UTC)
From: [identity profile] pzz.livejournal.com
Кстати, забыл спросить. Чем именно "заыбал" SVN?

Re: p4

Date: 2006-12-15 07:34 pm (UTC)
From: [identity profile] pzz.livejournal.com
Это странно. А вы его часом не на NFS'е держите? :-)

Я работал год в проекте с репозиторием в SVN'е. За это время он не сломался не разу. Т.е., доступ к серверу иногда пропадал на некоторое время (видимо, до перезагрузки системы), но нарушений информации не разу не случалось.

SVN, правда, был не свой, а вот этот вот: http://cvsdude.com/

Кстати, SVN научился вроде уже держать свой репозиторий не только в Berkley DB, так что есть шанс, что эта проблема уже починилась. Если это единственное, чем не устраивает SVN, я бы посмотрел на свежие версии прежде чем платить бешенные бабки за P4.

Re: p4

Date: 2006-12-15 07:51 pm (UTC)
From: [identity profile] krotoff.livejournal.com
В-общем почти целиком согласен, с двумя поправочками:
- опечатку в log message исправить таки-можно в p4.
- насчет merge изменений - по-моему тоже не совсем точно. В этом плане p4 - лучшее, что я трогал. Он помнит историю предыдущих merge по p4 integrate и помнит ее достаточно хорошо. Можно даже mergить на уровне отдельного changelistа, опустив часть промежуточной истории. Что опять-таки удобно.

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

Re: p4

Date: 2006-12-15 08:05 pm (UTC)
From: [identity profile] vvs2002.livejournal.com
А. В некоторые IDE уже встраивают local vcs, так что там сравнения с предыдущими версиями (и даже не версиями, а локальными снэпшотами) тоже без обращения на сервер. Поэтому я и удивился.

По поводу перемешения, step by step instructions сейчас не дам, но я точно делал через модификацие workspace. По тем же причинам - из-за проблем с сетью full checkout was not an option.
Page 1 of 3 << [1] [2] [3] >>

Profile

kika: (Default)
kika

January 2017

S M T W T F S
1234567
89 1011121314
151617181920 21
22232425262728
293031    

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Feb. 17th, 2026 01:58 pm
Powered by Dreamwidth Studios