Здравствуйте, eao197, Вы писали:

E>Здравствуйте, zaufi, Вы писали:

Z>>а можно пример "весьма продвинутого скрипта"??

E>Например, вот таким скриптом настраивается компиляция ACE.
<skip>

УЖОС! -- мои Makefile.am даже в очень сложных случаях (чего тока не было за 6 лет) выглядят куда проще и интуитивно понятнее

E>Ну это и не проще. А вот, например:
<skip>

E>Уже проще. Т.к. я нигде не указываю, от каких конкретно библиотек зависит моя DLL-ка. И от каких библиотек зависят библиотеки, от которых зависит моя DLL. При компиляции под Windows ко мне будут прилинкованны только непосредственно используемые мной статическе библиотеки и библиотеки импорта. А под Unix-ом будет прилинкованы все библиотеки, нужные моей DLL. Вне зависимо от уровня косвенности.
??? смишно! -- тоесь еси я пишу:

extern try_to_find_this_megafunction_at_link_stage(int);
int main()
{
  try_to_find_this_megafunction_at_link_stage(123);
  return 0;
}

мне ничо не нада никому указывать??? -- еси так, тада вы гении ребята!
или всетки require_project это оно и есь?? -- тада разочарую вас -- открытый вами велосипед уже давно применяется даже в автотулайзнутых пакетах... (хотите знать больше?
насчет UNIXовой фичи (про библы) -- c `man libtool`

E>И еще один момент, в таком скрипте mxx_ru проконтролирует совместимость выставленных режимов компиляции.
не нужно просто разбрасывать флаги компиляции по всем мэйкам -- если сделать один конфигурационный скрипт который определит какие нужно флаги (и библы за одно) и пробъет их во все мэйкфайлы таких проблем не буит... (автоконфовский подход в этом месте куда более удобен на мой взгляд) -- конфигурационная инфа вычисляется 1 раз! а не в каждом подкаталоге при каждой сборке...


E>И еще один момент, сменить расположение результатов компиляции/линковки ничего не изменяя ни в самом проекте, ни в одном из подпроектов.
сомнительная фича. я не догоняю зачем менять расположение результата компиляции? кому какая разница как оно умя там компилица -- главное куда все это проинсталлица после `make install` -- и что собсно проинсталлица...

Z>>кроме того (простите доку читал по диагонали -- мож чо и пропустил -- поправьте еси я ошибаюсь):
Z>>*) ничо не заметил про создание tarballов из сорцов
Z>>*) а также про инсталляцию

E>А вот это пока авторам mxx_ru не нужно было, поэтому и не сделали.
E>Если расскажите, что к чему и как бы вам хотелось это видеть -- то почему бы и не реализовать?
хочется как во всех нормальных пакетах иметь аналог `make install` -- который пройдясь по подкаталогам пакета проинсталлит (чо там описано куда инсталлить) все необходимые файлы... а по `make uninstall` снесет все это...

Z>>*) а также про эмуляцию какоголибо подобия autoconf (или интеграцию с последним) -- рулить странными переменными окружения не зачот! (это и пользователь пакета тоже должен делать??)

E>Рулить нужно только одной переменной
E>И, например, мне приходится много работать под Windows, сразу с несколькими компиляторами. autoconf здесь отдыхает по полной.
смишно! -- хотите знать больше? (c)


E>А вот на счет интеграции с autoconf мысли есть.
главное что хотелось бы видеть чтоб mxx не брал на ся слишком много... -- пусь он доверит автоконфу задачу определения того в каком окружении мы запускаемся, какие тулзы нам нужны для работы (компиляции) -- где они находятся и как их запускать
задача mxx сводится к трэканию зависимостей внутри пакета и обеспечению сборки его компонент (позволя лишь тюнить то что наопределял автоконф) стремясь предоставить пользователю гибкость (и простоту) настройки данной сборки а также установки этого пакета (и создание тарбола -- ибо исходники из VCS будучи заархивированными не всегда (а зачастую никогда) не являются тем что должен получать пользователь пакета для последующей компиляции)

Z>>*) где (тяжело ли сделать) аналог `make check`? -- я привык юнит-тесты компилять in that way... -- make distcheck потом сделает комплексную проверку моего дистра

E>Вот пример того, как у меня строятся тесты для SObjectizer: отдельный файл test/build_tests.rb:
<skip>

я предпочитаю иметь _маленькие_ (а чего там может быть большого описать построение бинарника из нескольких cpp файлов) Makefile.am _рядом_ с кодом юниттестов (который в свою очередь находится _рядом_ с тестируемым кодом) -- меньше теложвижений... а будучи рекурсивным targetом по `make check` мне построятся все тесты где бы они не находились вглубь от места запуска...

Z>>*) ну и наконец руби не мега распространенная весчь -- требует доп инсталляции и неопределенного числа телодвижений -- а пользователю чтоб собрать мой пакет тоже нада руби иметь???

E>Да.
E>А если в качестве build-системы использовать SCons, то Python.
E>И делу мегараспространения Ruby я (и не только я) здесь активно способствую. Так что со временем Ruby уже не будет экзотикой.

E>И вообще, в исходном сообщении было сказано, что mxx_ru нужен разработчикам, которые занимаются кросс-платформенной (не Unix-only) разработкой. Если кому-то вполне устраивает использование только GNU инструментов (ну повезло, можно позавидовать только), то нет проблем -- GNU make/GNU autotools уготована еще долгая жизнь.

да ради Бога... смущает только то что например в проекте для Lunix, Solaris, Windows система сборки должна следовать Windows-way (тоесь в основном наследовать странности этого подхода) а не более традиционному ./configure && make && make install ... -- *NIX like систем тут 2 а винда тока одна

Z>>*) как бы вы не хотели скрипты не выглядят "интуитивно понятно"... -- после беглого просмотра складывается ощющение что читать таки придется и много... но функционал не подрывает все бросить и забив на autotoolsы заняться изучением...

E>Функционал -- это как пословица: "Были бы кости, мясо наростет". Кости есть.

можит тут и есь мегапотенциал в расширяемости... но все это смахивает пока на overkill (т.е. из пушки по воробьям) -- нада делаться проще... даже проще чем автотулзы!!! -- уж не спрашивайте как

тогда есь какойта шанс завоевать разработчиков -- а пока я не встречал таких проектов в которых нельзя былоб обойтись автотулзами... единстно чо раздражает чо в бальших проектах конфигурение занимает раздражающе долгое время... и либтул при инсталляции хотелось бы пошустрее чтоб все это делал...

а вообще я чесно гря слабо представляю как можно сделать единую среду для управления пакетами в Win и *NIX котоыре имеют довольно разные к этому подходы...