SD

[kika]

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

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

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

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

Comments

[rblaze.livejournal.com]

Как можно собрать в один проход статическую и динамическую библиотеки, если одни надо собирать с -fPIC, а другие без?
Если задача "один раз набрать make", то она успешно решена в BSD на обычном make, нет в этом ничего сложного. Сборка под винду будет отличаться не сильно: компиляторы по умолчанию вписать другие да расширения у библиотек.

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

[kika.livejournal.com]

Я SCM приписал потом, думая что так понятнее будет. Некоторые и GNU Make называют SCM.

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

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

[rblaze.livejournal.com]

Ну надо так надо :) В FreeBSDшной инфраструктуре это делается простым добавлением строчки "INSTALL_PIC_ARCHIVE=yes" в Makefile, в результате все объектники собираются два раза и на выходе получается .a и .so.
Перенос на другую платформу сведется к изменению имен бинарников и параметров сборки, если там нет каких-то кардинальных отличий типа взятия файлов из SQL вместо FS.

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

[kika.livejournal.com]

autotools решают очень много проблем в плане несовместимостей разных юниксов друг с другом. Напильничком может и надо пройтись, но это не сравнить с выпиливанием этим же напильником из цельной болванки. Другой вопрос что в общем и целом "разных юниксов" уже не осталось. Остался линукс и местами FreeBSD и (отчасти) MacOS/X. Усе. Если мы пишем енд-юзерский софт, то бсдей можно пренебречь, если серверный - то нельзя, ну или по крайней мере нежелательно.
А поддержка мульена экзотических юниксов нужна либо уже очень mature программным продуктам (когда мы сожрали 99% рынка и единственная цель в окошке - добирать по 0.1% каждый год) либо заказному софту.
Поэтому у нас автотулс получается просто генератором мейкфайлов под линукс и все.

[evolver.livejournal.com]

Поэтому у нас автотулс получается просто генератором мейкфайлов под линукс и все.

У нас примерно так и делается, только для генерации makefiles используется нечто основанное на Imake с кучей собственных расширений. В результате желаемая цель собирать все для всех платформ одним вызовом make достигается успешно. Сборка на нескольких платформах одновременно происходит на build server farm.

p4

[vvs2002.livejournal.com]

Perforce все-таки не build tool. Или подразумевался "условный" перфорс?

Re: p4

[kika.livejournal.com]

я с перфорсом не знаком особо, поэтому подразумевался именно условный, то есть некое дорогое проприетарное решение с хорошим потенциалом customer lock in :-)
Я вообще не шоплю в эту сторону, у меня ни бюджета на эти игрушки нет, ни желания lockinиться.

Re: p4

[vvs2002.livejournal.com]

"Неусловный" p4 как VCS очень неплох. У нас бюджета пока вообще ни на что нет, но уже подумываем купить его. Так как SVN заыбал уже.

Re: p4

[kika.livejournal.com]

А на что еще смотрели, кроме SVN?

Re: p4

[vvs2002.livejournal.com]

Из халявного? CVS. А из предыдущего combined experience с ClearCase, p4, StarTeam и прости-хоссподи pvcs, p4 вызывает самые положительные эмоции.

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

Re: p4

[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

[kika.livejournal.com]

У меня есть ощущение что оба недостатка SVN, которые ты перечислил, по порядку величины тянут примерно на разработку нового VCS.

Re: p4

[krotoff.livejournal.com]

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

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

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

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

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

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

Re: p4

[vvs2002.livejournal.com]

Несколько замечаний по p4:
- про переименования согласен
- перемещение в другое место настраивается через workspace
- насчет account'ов ты неправ. Можно под одним акаунтом иметь бесконечное количество воркспэйсов. Чем, когда лицензий не хватает, можно злоупотреблять.
- насчет diff'a не совсем понял. Если за время моего работы над файлом в репозитории появилась новая версия, как именно сравнение локальных файлов может помочь?
- оба гуя suck. Tortoise интегрируется с explorer'ом, что делает его совсем бесполезным для тех, кто им не пользуется в качестве файлменеджера.

Re: p4

[vadimchen.livejournal.com]

А что не так с SVN?

Re: p4

[vvs2002.livejournal.com]

репозиторий ломается подозрительно часто. Грубо говоря на его супорт времени тратиться подозрительно много. Где-то на порядок больше, чем на более серьезный проект в p4.

Re: p4

[pzz.livejournal.com]

Кстати, забыл спросить. Чем именно "заыбал" SVN?

[cherjr.livejournal.com]

аристов ваяет что-то на эту тему. могу выяснить статус

[kika.livejournal.com]

Узнай, интересно.

[cherjr.livejournal.com]

не совсем про то оказалось, но тоже может быть интересно:
http://www.termiit.com/termiit/
http://www.termiit.com/news/

[kika.livejournal.com]

Идея интересная, но, к сожалению, Java only. А я как раз, слава богу, живу в Java free мире.

[cherjr.livejournal.com]

аристов говорил, что "не только ява", но "я не продаю" (с) :)

[aristovich.livejournal.com]

да совсем не java only - то что в примерах - т под яву. а, вообще, можно любые другие процессы привинчивать.

да и вообще? неужели в 2006 году все еще существенно на чем именно писать? какая разница?

[p1r4nh4.livejournal.com]

*поздновато пешу, уже полгода прошло. :)

А всякие там scons? Или вопрос уже триста лет как неактуален?

[kika.livejournal.com]

SCons все же еще и make сам себе, а хочется билдить "стандартным" средством. В частности, CMake хорош тем что генерирует проекты для IDE, и позволяет работать "нативным" образом. Ну и еще я не понял как у SCons с out-of-source builds обстоят дела.