Вышла версия 1.1 build-системы Mxx_ru

Что такое Mxx_ru?

Mxx_ru -- это кросс-платформенный инструмент управления компиляцией и сборкой проектов, реализованный на языке Ruby. Ориентирован, в первую очередь на C/C++, но может быть адаптирован для других языков. Mxx_ru построен как набор шаблонов для наиболее распространенных типов целей. Например, проектный файл для сборки HelloWorld в Mxx_ru выглядит как:

require 'mxx_ru/cpp'

Mxx_ru::Cpp::exe_target( 'hello_world.rb' ) {
  target 'hello_world'

  cpp_source 'hello_world.cpp'
}

На RSDN о Mxx_ru можно прочитать в статье Структура проектов на C++ с использованием Subversion и Mxx_ru

Автор(ы): Евгений Охотников
Дата: 22.05.2005
Данная статья описывает предложения по организации файловой структуры проектов на C++ и компиляции проектов с помощью Mxx_ru (http://eao197.narod.ru/mxx_ru), а так же показывает, как использовать систему контроля версий Subversion (http://subversion.tigris.org) не только в качестве инструмента для управления версиями исходных текстов, но и для отслеживания зависимостей между проектами.

Кому может быть полезен Mxx_ru

Mxx_ru предназначен для C/C++ разработчиков, которым необходимо разрабатывать кросс-платформенные проекты. Проекты, которые приходится компилировать разными компиляторами на разных платформах. В этом случае Mxx_ru позволяет использовать один и тот же проектный файл на всех платформах и для всех компиляторов.

Где взять и как установить Mxx_ru

Mxx_ru оформлен в виде RubyGem-а. Поэтому для его загрузки и инсталляции достаточно всего лишь дать команду:

gem install -r mxx_ru

После этого нужно настроить Mxx_ru для своей платформы/компилятора, установив соответствующим образом переменную среды MXX_RU_CPP_TOOLSET. Например:

set MXX_RU_CPP_TOOLSET=vc7

или

export MXX_RU_CPP_TOOLSET=gcc_linux

Более подробную информацию о Mxx_ru можно получить в Mxx_ru User Manual

Новое в версии 1.1

Методы composite_target, exe_target, dll_target, lib_target.
Возможность устанавливать значения по умолчанию для runtime_mode, rtti_mode, rtl_mode, threading_mode.
Изменены правила управления PDB-файлами при компиляции Visual C++ в DEBUG-режиме.
Улучшено удаление промежуточных результатов компиляции Visual C++ (.exp-файлы).
Добавлена поддержка манифестов Visual C++ 8.0.

Благодарности

Огромное спасибо Михаилу Лёсину за неоценимую помощь в переводе Mxx_ru на английский язык и подготовку версии 1.1.

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

E>Вышла версия 1.1 build-системы Mxx_ru

Такой вопрос: чем он лучше scons, cmake, ..., autotools наконец? Сейчас выбираю систему для сборки проекта и пока остановился на autotools, т.к. в сумме он мне кажется более приемлемым вариантом, чем прочие, вышеперечисленные.

E>>Вышла версия 1.1 build-системы Mxx_ru

А>Такой вопрос: чем он лучше scons, cmake, ..., autotools наконец? Сейчас выбираю систему для сборки проекта и пока остановился на autotools, т.к. в сумме он мне кажется более приемлемым вариантом, чем прочие, вышеперечисленные.

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

Здравствуйте, Аноним, Вы писали:

E>>Вышла версия 1.1 build-системы Mxx_ru

А>Такой вопрос: чем он лучше scons, cmake, ..., autotools наконец? Сейчас выбираю систему для сборки проекта и пока остановился на autotools, т.к. в сумме он мне кажется более приемлемым вариантом, чем прочие, вышеперечисленные.

С autotools ты будешь хорошо себя чувствовать только в Unix-овом окружении. Как только потребуется работать с Windows не через GNU/Cygwin инструменты, то...

CMake, насколько я знаю, это генератор makefile. Он сам не управляет процессом сборки.

SCons -- это да, серьезная альтернатива. Но, мне показалось, что сложные проекты (включающие в себя несколько композитных подпроектов) описывать в mxx_ru проще. Кроме того, в mxx_ru специально закладывались для C++ такие фишки, как:
— upspread опции (т.е., если какой-то проект требует, чтобы все, кто его используют определяли define SOME_PROJECT_IN_DLL, то такой define объявляется как upspred-опция и автоматически устанавливается для всех проектов, которым это действительно нужно);
— централизованный контроль за такими режимами, как multithreading, rtl (shared/static) и rtti (enabled/disabled);
— имхо, расширяется mxx_ru проще (за счет Ruby), чем Python-овский SCons.

Пока mxx_ru менее наворочен, чем SCons или Boost.Build.v2, предоставляет меньше готовых настроек. Но, он и гораздо моложе. А так же у mxx_ru русскоязычные разработчики, с которыми проще обсудить проблемы и высказать замечания/предложения. Так что обращайтесь

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

E>>>Вышла версия 1.1 build-системы Mxx_ru

А>>Такой вопрос: чем он лучше scons, cmake, ..., autotools наконец? Сейчас выбираю систему для сборки проекта и пока остановился на autotools, т.к. в сумме он мне кажется более приемлемым вариантом, чем прочие, вышеперечисленные.

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

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

--
чесс слово не догоняю чем это

require ’mxx_ru/cpp’
Mxx_ru::Cpp::lib_target( "say.rb" ) {
  target( "say" )
  cpp_source( "say.cpp" )
}
---
require ’mxx_ru/cpp’
Mxx_ru::Cpp::exe_target( "prj.rb" ) {
  target( "exe_and_lib" )
  required_prj( "say.rb" )
  include_path( "." )
  cpp_source( "main.cpp" )
}

проще чем это

lt_LIBRARIES = say
bin_PROGRAMS = prj
say_SOURCES = say.cpp
prj_SOURCES = main.cpp
prj_LDADD = libsay.la

---
кроме того (простите доку читал по диагонали -- мож чо и пропустил -- поправьте еси я ошибаюсь):
*) ничо не заметил про создание tarballов из сорцов
*) а также про инсталляцию
*) а также про эмуляцию какоголибо подобия autoconf (или интеграцию с последним) -- рулить странными переменными окружения не зачот! (это и пользователь пакета тоже должен делать??)
*) где (тяжело ли сделать) аналог `make check`? -- я привык юнит-тесты компилять in that way... -- make distcheck потом сделает комплексную проверку моего дистра
*) ну и наконец руби не мега распространенная весчь -- требует доп инсталляции и неопределенного числа телодвижений -- а пользователю чтоб собрать мой пакет тоже нада руби иметь???
*) как бы вы не хотели скрипты не выглядят "интуитивно понятно"... -- после беглого просмотра складывается ощющение что читать таки придется и много... но функционал не подрывает все бросить и забив на autotoolsы заняться изучением...

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

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

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

require 'mxx_ru/cpp'

module    Ace
    class    Base < Mxx_ru::Cpp::Lib_or_dll_target
        TAG = "ace/prj.rb"
        def    initialize( a_alias = TAG )
            super( a_alias, TAG )

            threading_mode( Mxx_ru::Cpp::THREADING_MULTI )

            target( "ACE.5.4" )

            init_dll_block(
                Proc.new {
                    rtl_mode( Mxx_ru::Cpp::RTL_SHARED )
                    implib_path( "lib" )
                    define( "ACE_BUILD_DLL" )
                    define( "ACE_OS_BUILD_DLL" )
                })
            init_lib_block(
                Proc.new {
                    target_root( "lib" )

                    define( "ACE_AS_STATIC_LIBS", OPT_UPSPREAD )
                })

            setup_platform_flags()

            setup_sources()
        end

        def    setup_platform_flags()
            if toolset.tag( "target_os" ) == "mswin"
                define( "MXX_RU_ACE__PLATFORM_WIN32", OPT_UPSPREAD )
                define( "WIN32", OPT_UPSPREAD )

                if "vc" == toolset.name ||
                        "bcc" == toolset.name
                    define( "MXX_RU_ACE__ACE_HAS_STANDARD_CPP_LIBRARY",
                            OPT_UPSPREAD )
                end

                lib( "user32.lib" )
                lib( "advapi32.lib" )

                if "bcc" == toolset.name
                    lib( "ws2_32.lib" )
                end

            elsif toolset.tag( "target_os" ) == "unix"
                if toolset.tag( "unix_port" ) == "cygwin"
                    define( "MXX_RU_ACE__PLATFORM_CYGWIN32", OPT_UPSPREAD )
                elsif toolset.tag( "unix_port" ) == "linux"
                    define( "MXX_RU_ACE__PLATFORM_LINUX", OPT_UPSPREAD )
                    lib( "pthread" )
                    lib( "dl" )
                    lib( "rt" )
                end 
            elsif toolset.tag( "target_os" ) == "tandem_oss"
                define( "MXX_RU_ACE__PLATFORM_TANDEM_OSS", OPT_UPSPREAD )

                compiler_option( "-Wextensions", OPT_UPSPREAD )
                compiler_option( "-D _XOPEN_SOURCE_EXTENDED=1", OPT_UPSPREAD )

                lib( "zsptsrl" )
            end
        end

        def setup_sources()
# Здесь перечисление исходников
        end
    end
end

Z>--
Z>чесс слово не догоняю чем это
<...skipped...>
Z>проще чем это
<...skipped...>

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

require 'mxx_ru/cpp'

require 'oess_1/util_cpp_serializer/gen'

Mxx_ru::setup_target(
    Mxx_ru::Cpp::Dll_target.new( "aag_3/smpp_smsc/prj.rb" ) {

    required_prj "ace/dll.rb" 

    required_prj "cls_2/prj.rb" 
    required_prj "smart_ref_3/lib.rb" 

    required_prj "threads_1/dll.rb" 

    required_prj "libpcre++/prj.rb"

    required_prj "oess_1/defs/prj.rb" 
    required_prj "oess_1/io/prj.rb" 
    required_prj "oess_1/stdsn/prj.rb" 
    required_prj "oess_1/db/prj.rb" 

    required_prj "so_4/prj.rb" 
    required_prj "so_sysconf_2/prj.rb" 
    required_prj "so_log_1/prj.rb" 

    required_prj "mbapi_3/prj.rb" 
    required_prj "mbapi_3_mbox/core/prj.rb" 
    required_prj "mbsms_2/prj.rb" 

    required_prj "gemont_1/prj.rb" 
    required_prj "smpp_pdu_1/prj.rb" 

    required_prj "aag_3/defs/prj.rb"
    required_prj "aag_3/sms_data_type/prj.rb"
    required_prj "aag_3/safe_sms_history/prj.rb"

    target "aag.smpp_smsc" 

    ddl = generator Oess_1::Util_cpp_serializer::Gen.new( self )

    cpp_source "trx_id.cpp"
    ddl.ddl_file "trx_id.ddl"

    sources_root( "impl" ) {
        cpp_source "registered_delivery_checker.cpp"

        cpp_source "send_trx_map.cpp" 
        cpp_source "receive_trx_map.cpp" 
        cpp_source "delivery_receipt_map.cpp" 

        cpp_source "oess_send_trx_map.cpp"
        ddl.ddl_file "oess_send_trx_map.ddl"

        cpp_source "oess_receive_trx_map.cpp"
        ddl.ddl_file "oess_receive_trx_map.ddl"

        cpp_source "oess_delivery_receipt_map.cpp"
        ddl.ddl_file "oess_delivery_receipt_map.ddl"
    }

    cpp_source "cfg.cpp"
    cpp_source "delivery_receipt_msg_parser.cpp"
    cpp_source "a_channel.cpp"
    cpp_source "a_send_history.cpp"
    cpp_source "a_receive_history.cpp"
    cpp_source "a_delivery_receipt_history.cpp"
    cpp_source "coop_maker.cpp"
    cpp_source "coop_factory.cpp"
})

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

И еще один момент, в таком скрипте mxx_ru проконтролирует совместимость выставленных режимов компиляции.

И еще один момент, сменить расположение результатов компиляции/линковки ничего не изменяя ни в самом проекте, ни в одном из подпроектов.

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

А вот это пока авторам mxx_ru не нужно было, поэтому и не сделали.
Если расскажите, что к чему и как бы вам хотелось это видеть -- то почему бы и не реализовать?

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

Рулить нужно только одной переменной
И, например, мне приходится много работать под Windows, сразу с несколькими компиляторами. autoconf здесь отдыхает по полной.

А вот на счет интеграции с autoconf мысли есть.

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

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

#!/usr/local/bin/ruby
require 'mxx_ru/cpp'

Mxx_ru::setup_target(
    Mxx_ru::Cpp::Composite_target.new( "test/build_tests.rb" ) {

        required_prj( "test/active_group/prj.ut.rb" )

        required_prj( "test/demand_priority/prj.ut.rb" )

        required_prj( "test/disp_bug_chstate/prj.ut.rb" )

        required_prj( "test/timer/clean_on_shutdown/prj.rb" )
        required_prj( "test/timer/periodic/prj.rb" )

        required_prj( "test/dyn_reg_restart/prj.rb" )
        required_prj( "test/dyn_reg_restart_ao/prj.rb" )

        required_prj( "test/evt_queue_cleanup/prj.ut.rb" )

        required_prj( "test/inheritance/derive_fail_inherit_overrided_evt/prj.ut.rb" )
        required_prj( "test/inheritance/fail_inherit_overrided_evt/prj.ut.rb" )
        required_prj( "test/inheritance/inherit_event/prj.ut.rb" )
        required_prj( "test/inheritance/multi_indirect_inherit_evt/prj.ut.rb" )
        required_prj( "test/inheritance/multi_indirect_inherit_msg/prj.ut.rb" )
        required_prj( "test/inheritance/multi_inherit_evt/prj.ut.rb" )
        required_prj( "test/inheritance/multi_inherit_evt_conflict/prj.ut.rb" )
        required_prj( "test/inheritance/multi_inherit_msg/prj.ut.rb" )
        required_prj( "test/inheritance/multi_override_msg/prj.ut.rb" )
        required_prj( "test/inheritance/multi_unknown_base/prj.ut.rb" )
        required_prj( "test/inheritance/smsg_fail/prj.ut.rb" )
        required_prj( "test/inheritance/smsg_ok/prj.ut.rb" )
        required_prj( "test/inheritance/override_evt/prj.ut.rb" )
        required_prj( "test/inheritance/state/prj.ut.rb" )

        required_prj( "test/insend/broadcast/prj.ut.rb" )
        required_prj( "test/insend/chstate/prj.ut.rb" )
        required_prj( "test/insend/conflict/prj.rb" )
        required_prj( "test/insend/delayed/prj.ut.rb" )
        required_prj( "test/insend/global/prj.rb" )
        required_prj( "test/insend/simple/prj.ut.rb" )

        required_prj( "test/parent_coop/first/prj.ut.rb" )
        required_prj( "test/parent_coop/second/prj.ut.rb" )

        required_prj( "test/send_msg_lock_2/prj.rb" )
        required_prj( "test/send_msg_lock_3/prj.rb" )

        required_prj( "test/state_merge/exclude_ok/prj.ut.rb" )
        required_prj( "test/state_merge/merge_fail1/prj.ut.rb" )
        required_prj( "test/state_merge/merge_fail2/prj.ut.rb" )
        required_prj( "test/state_merge/merge_fail3/prj.ut.rb" )
        required_prj( "test/state_merge/merge_fail4/prj.ut.rb" )
        required_prj( "test/state_merge/merge_ok/prj.ut.rb" )

        required_prj( "test/subscr/prj.ut.rb" )

        required_prj( "test/traits/prj.ut.rb" )

        required_prj( "test/unknown_state_evt/unknown_evt/prj.ut.rb" )
        required_prj( "test/unknown_state_evt/derived_from_incorrect/prj.ut.rb" )

    }
)

Нужно скомпилировать и проверить? Нет проблем:

ruby test/build_tests.rb

Файлы с расширением .ut.rb -- это unit-тесты, mxx_ru их после компиляции запускает и останавливает процесс, если какой-то unit-тест завершается не нормально.

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

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

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

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

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

Здравствуйте, 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 котоыре имеют довольно разные к этому подходы...

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

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

Можно посмотреть?

Z>мне ничо не нада никому указывать??? -- еси так, тада вы гении ребята!

За такие слова при личном общении мог последовать прямой правый в голову.
Вы здесь поерничать собрались? Или же поговорить нормально? На нормальном русском языке, с нормальными вменяемыми коллегами. Если так, то давайте так и разговаривать.

По поводу приведенного примера. Нет, фишка в другом:

// Библиотека libbase.a
void do_something_low_level() { ... }

// Библиотека libuseful.so
void do_something_useful() { ...; do_something_lowlevel(); ... }

// Библиотека libpowerful.so
void do_something_powerful() { ...; do_something_useful(); ... }

// Исполнимый файл superpuper
int main() { ...; do_something_powerful(); ... }

В проектном файле для superpuper нужно указать только require_prj 'powerful/prj.rb'. И все, к superpuper будут прилинкованы libbase.a, libuseful.so, libpowerful.so.

Z>или всетки require_project это оно и есь?? -- тада разочарую вас -- открытый вами велосипед уже давно применяется даже в автотулайзнутых пакетах... (хотите знать больше?

Да. С примерами пожалуйста. Собственными.

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

В каждом подкаталоге при каждой сборке -- это подход make, если не ошибаюсь. mxx_ru позволяет не задавать общий конфиг для проекта. Он позволяет каждому подпроекту настроить параметры не задумываясь, с кем придется дружить в одном общем проекте. А тому, кто объединяет все это дело в одном месте не придется делать общий конфиг. Зато он будет уверен, что либы, скомпилированные в режиме single threading не будут слинкованы с либами, скомпилированными в multi threading.

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

Кому сомнительная, а кому-то очень нужная. Например, иметь в одном каталоге проект, скомпилированный в RELEASE и в DEBUG режимах.
Речь сейчас не о make install и не об исталляции чужой либы на своем компьютере, а о разработке своего проекта.
А еще бывают разработчики, кому нужно одновременно иметь скомпилированные версии в RELEASE и DEBUG, с поддержкой UNICODE и без нее, с оформлением собственных библиотек в виде DLL или в виде статических библиотек.

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

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

Понятно.

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

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

Да.

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

А вы знаете, что берет на себя mxx_ru?
Может сначала попробуете?

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

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

А если какие-то нужно запретить для построение и запуска?
И если результаты компиляции нужно куда-то в другое место складывать?

Кроме того, это же язык программирования! Продвинутый язык.

require 'mxx_ru/cpp'

Mxx_ru::Cpp::composite_target( 'test/build_tests.rb' ) {
  Dir.glob( "test/**/prj.ut.rb" ).each { |ut| required_prj ut }
}

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

Вот интересно, autotools и make уже давно существуют, стандарт практически. А все равно кого-то не устраивает. Настолько не устраивает, что одни пишут, а другие используют инструменты вроде SCons, CMake, MPC, Boost.Build, Ant, A-A-P и Mxx_ru. Может не все так ладно в датском королевстве?
И, если посмотерть внимательно, компиляция проекта в Windows через ruby (или даже через SCons или Boost.Build) -- это совсем даже не Windows-way.

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

Ну посмотрите со временем на такие вещи, как SCons, Boost.Build, MPC и, я надеюсь, mxx_ru.
Что-то из этого обязательно получится.

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

E>Вышла версия 1.1 build-системы Mxx_ru

E>Что такое Mxx_ru?..

...А чем оно лучше Rake? По виду — несколько сложнее

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>...А чем оно лучше Rake? По виду — несколько сложнее

У них разные подходы к проблеме.
Какой из них удобнее — выбирать Вам. =)
Rake основан на формировании правил, по сути таких же, как и в make файлах, с разницей только в более удобном(возможно) синтаксисе.
Mxx_ru же предлагает совсем другой подход к проблеме — шаблонно-ориентированый. И хотя в нем тоже есть возможность задавать простые правила — это скорее мера для преодоления возможных непредусмотренных шаблонами действий, чем основной инструмент.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>...А чем оно лучше Rake?

Тем, что Rake -- это тот же make, только в Ruby синтаксисе
А Mxx_ru -- это набор шаблонов для описания проектов. Что-то вроде Ant, только в виде Ruby программ. Соответственно, в make нужно описывать, что из чего и как нужно получить. А в mxx_ru -- что и из чего. А вот как -- это уже задача mxx_ru.

ЗХ>По виду — несколько сложнее

А давай сравним
Пример из tutorial-а Rake:

require 'rake/clean'

CLEAN.include('*.o')
CLOBBER.include('hello')

task :default => ["hello"]

SRC = FileList['*.c']
OBJ = SRC.ext('o')

rule '.o' => '.c' do |t|
  sh "cc -c -o #{t.name} #{t.source}"
end

file "hello" => OBJ do
  sh "cc -o hello #{OBJ}"
end
  
# File dependencies go here ...
file 'main.o' => ['main.c', 'greet.h']
file 'greet.o' => ['greet.c']

При этом мы привязаны к конкретному компилятору, к конкретному режиму компиляции (выше используется и не RELEASE (нет -O2) и не DEBUG (нет -g)) и сами должны перечислять зависимости для main.c.
А вот так тот же самый пример выглядел бы на mxx_ru:

require 'mxx_ru/cpp'

Mxx_ru::Cpp::exe_target( 'hello.rb' ) {
  target 'hello'

  c_source 'greet.c'
  c_source 'main.c'
}

Все. Этот проектный файл пойдет и для Visual C++, и для Borland C++, и для GNU C++ и ...(ну ты понимаешь ).
Для компиляции в RELEASE:

ruby hello.rb --mxx-cpp-release

для компиляции в DEBUG:

ruby hello.rb --mxx-cpp-debug

для CLEANUP:

ruby hello.rb --mxx-clean

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>По виду — несколько сложнее

Кстати, о том, что Mxx_ru может предоставить C/C++ проекту, можно прочитать здесь

Автор(ы): Евгений Охотников
Дата: 22.05.2005
Данная статья описывает предложения по организации файловой структуры проектов на C++ и компиляции проектов с помощью Mxx_ru (http://eao197.narod.ru/mxx_ru), а так же показывает, как использовать систему контроля версий Subversion (http://subversion.tigris.org) не только в качестве инструмента для управления версиями исходных текстов, но и для отслеживания зависимостей между проектами.

. А есть ли такой же готовый функционал в Rake для C/C++ проектов?

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

E>А вот так тот же самый пример выглядел бы на mxx_ru:
E>

E>require 'mxx_ru/cpp'

E>Mxx_ru::Cpp::exe_target( 'hello.rb' ) {
E>  target 'hello'

E>  c_source 'greet.c'
E>  c_source 'main.c'
E>}
E>

Несколько смущает синтаксический оверхед:

require 'mxx_ru/cpp'

т.к. в основном я буду пользовать mmx_ru для сборки С++ проектов, то было бы удобно если бы данный модуль подгружался автоматов,
конечно -rlibrary спасает, но это костыль.

Mxx_ru::Cpp::exe_target

Тоже давольно устрашающе выглядет, на мой взгляд имя для таргета могло бы быть и по дружелюбней, например build_program,
конечно зная ruby костыли и подпорки прикрутить не сложно, но все же.

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

M>Несколько смущает синтаксический оверхед:

M>require 'mxx_ru/cpp'

M>т.к. в основном я буду пользовать mmx_ru для сборки С++ проектов, то было бы удобно если бы данный модуль подгружался автоматов,
M>конечно -rlibrary спасает, но это костыль.

От этого можно избавиться только одним способом: запускать ruby-скрипт (который где-то в PATH-е валяется), а уже ruby скрипт будет искать файл с нужным именем и запускать его. По аналогии с подходом SCons.
Например, само описание проекта:

Mxx_ru::Cpp::exe_target( 'hello.rb' ) { ... }

запускается как:

$ mxx_ru hello.rb --mxx-cpp-release

Но мне больше нравится запускать компиляцию вообще вот так:

$ hello.rb --mxx-cpp-relese

а для этого как раз require 'mxx_ru/cpp' писать нужно.

Ну и кроме того, такой явный require может со временем позволить более спокойно переходить на новые версии Mxx_ru. Скажем:

require 'rubygems'
require_gem 'mxx_ru', '> 1.2.0'
....

и использовать в одном проекте разные проектные файлы, которые требуют разные версии Mxx_ru.

M>Mxx_ru::Cpp::exe_target

M>Тоже давольно устрашающе выглядет, на мой взгляд имя для таргета могло бы быть и по дружелюбней, например build_program,
M>конечно зная ruby костыли и подпорки прикрутить не сложно, но все же.

Имхо, разница между exe_target и build_program -- это дело вкуса. К тому же, с точки зрения реальной работы Mxx_ru, exe_target более точно отражает суть происходящего: описание цели, которая будет являтся исполнимым файлом. Само простроение цели не выполняется, поэтому название build_program не точно.

Забавно, что настоящий оверхед, который пока существует, ты и не указал. У меня require 'mxx_ru/cpp' и Mxx_ru::Cpp::*_target() пишутся уже на автомате. А вот необходимость указывать в качестве псевдонима цели само имя файле -- вот это действительно и оверхед и просчет. Но, надеюсь, скоро можно будет писать так:

# Файл hello.rb
....
Mxx_ru::Cpp::exe_target { # Псевдоним цели не указывается.
  target 'hello'
  c_source 'hello.c'
}
...
# Файл build.rb
...
Mxx_ru::Cpp::composite_target( BUILD_ROOT ) { # Псевдоним нужен.
  ...
}

Здравствуйте, Зверёк Харьковский, Вы писали:

E>>Вышла версия 1.1 build-системы Mxx_ru

ЗХ>...А чем оно лучше Rake?

Кстати еще по поводу лучше/хуже. Вот небольшая статистика об объемах проектов, в которых Mxx_ru применяется для управления компиляцией. Это три самых крупных проекта:

В первом 872 *.cpp файла и 74 проектных (prj.rb) файла (проект портирован под Window, Linux, NonStop).
Во втором 1124 *.cpp файла и 121 проектный (prj.rb) файл (только под Windows).
В третьем, самом крупном, 1181 *.cpp файл и 188 проектных (prj.rb) файлов (проект портирован под Windows, Linux, Solaris).

В каждом из проектов есть один build.rb из которого прямо или косвенно подгружаются практически все проектные файлы в проекте. И на все подпроекты таким образом распространяются общие глобальные настройки, а так же проверяется согласованность настроект подпроектов. Так же Mxx_ru отслеживает include-зависимости у всех *.cpp файлов.

Так что, не знаю, как Rake на подобных объемах
А вот Mxx_ru может не только HelloWorld компилировать, это проверено

ЗХ>По виду — несколько сложнее

Сейчас в svn-репозитории в branches/1.1.1 следующая версия готова (тестируется перед релизом), так в ней использование Mxx_ru еще больше упрощено. Например, файл какой-нибудь проектный файл fast/renderer/prj.rb может выглядеть так:

require 'mxx_ru/cpp'

Mxx_ru::Cpp::dll_target { # Не нужно больше указывать псевдоним проектного файла.
  target( 'fast.renderer' )

  # Все C++ файлы из fast/renderer с подкаталогами одним движением руки.
  cpp_sources Dir.glob( 'fast/renderer/**/*.cpp' )
}

А запуск компиляции всех подпроектов какого-то проекта (файл build.rb):

require 'mxx_ru/cpp'

Mxx_ru::Cpp::composite_target( Mxx_ru::BUILD_ROOT ) {
  # Все подпроекты компилируются через свои prj.rb файлы.
  required_prjs Dir.glob( '**/prj.rb' )
}

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

E>Вышла версия 1.2 build-системы Mxx_ru

Что нового

Исправлено несколько ошибок в работе с MinGW и Borland C++.


Аргумент prj_alias для методов exe_target, lib_target, dll_target, composite_target теперь опциональный и выводится автоматически из имени проектного файла. Это позволило избавится от дублирования имени проектного файла внутри самого проектного файла. Т.е. вместо:

Mxx_ru::Cpp::dll_target( 'fast/renderer/prj.rb' ) { ... }

теперь можно писать проще:

Mxx_ru::Cpp::dll_target { ... }

Добавлены методы required_prjs, c_sources, cpp_sources, который получают в качестве аргумента Enumerable (т.е. сразу несколько значений). Это позволяет писать так:

Mxx_ru::Cpp::exe_target {
  target 'hello'
  c_sources [ 'greeting.c', 'main.c' ]
}

или использовать результаты работы Dir.glob (рекурсивного поиска имен по маске):

Mxx_ru::Cpp::dll_target {
  target 'fast.renderer'
  cpp_sources Dir.glob( 'fast/renderer/**/*.cpp' )
}

А с учетом того, что мы находимся в рамках настоящего языка программирования, то можно делать вот такие вещи:

Mxx_ru::Cpp::composite_target {
  required_prjs Dir.glob( "test/**/prj.ut.rb" )

  required_prjs Dir.glob( "test/**/prj.rb" ).find_all { |f|
    !File.exists?( f.gsub( /\.rb$/, '.ut.rb' ) )
  }
}

Это модифицированный вариант файла test/build_tests.rb показанный ранее здесь

Автор: eao197
Дата: 10.04.06

. Этот проектный файл сначала находит все файлы unit-тестов и добавляет их в список проектов для построения, а затем находит проекты, которые не являются unit-тестами (для таких проектов есть prj.rb, но рядом нет prj.ut.rb).


Добавлены аргументы --mxx-brief-show, --mxx-brief-hide, которые включают/выключают печать краткого описания выполняемого действия (т.к. 'Compilling hello.c...', 'Building hello.exe...').

Установка и/или обновление

Для обновления уже установленной версии Mxx_ru нужно воспользоваться командой:

gem update Mxx_ru

Для установки новой версии Mxx_ru (когда предыдущей копии не было) нужно воспользоваться командой:

gem install -r Mxx_ru

Благодарности

Константину Назарову (rut at users dot sourceforge dot net)

И всем, кто в обсуждении Mxx_ru высказывался по поводу синтаксического оверхеда

Наверное имеет смысл предоставить пользователю возможность переопределения расширения таргета в Mxx_ru. Сейчас такой нет. Например при компиляции плагинов для Maya компилятся обычные dllки, но расширение у них должно быть — mll.
Предлагаю ввести переменные с областью действия ограниченной текущим проектом (без наследований, и заполненные автоматом самим mxx_ru по дефолту) типа exe_ext, dll_ext, lib_ext, которые пользователь может изменить если захочет.

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

M>Наверное имеет смысл предоставить пользователю возможность переопределения расширения таргета в Mxx_ru. Сейчас такой нет. Например при компиляции плагинов для Maya компилятся обычные dllки, но расширение у них должно быть — mll.
M>Предлагаю ввести переменные с областью действия ограниченной текущим проектом (без наследований, и заполненные автоматом самим mxx_ru по дефолту) типа exe_ext, dll_ext, lib_ext, которые пользователь может изменить если захочет.

В branches/1.3 реализован метод target_ext, который позволяет изменять расширение цели. Для примера с Maya его использование может выглядеть так:

Mxx_ru::Cpp::dll_target {
  target 'some_plugin'
  target_exe '.mll'
  ...
}

В branches/1.3 реализован еще один тип CustomSubdirObjPlacement -- позволяет задать отдельно каталог для расположения финальных результатов компиляции (exe/dll/lib/so/a) и отдельно каталог для промежуточных (obj/o/res).

Например, если в проекте указать:

Mxx_ru::Cpp::composite_target {
  global_obj_placement Mxx_ru::Cpp::CustomSubdirObjPlacement.new(
    # Final resuls going here.
    'bin32',
    # All intermediate files going here.
    'tmp/output32' )

  required_prj ...
}

и файловая структура проекта имела вид:

prj_1/
`- src/
prj_2/
`- module_1/
`- module_2/

то после компиляции она примет вид:

prj_1/
`- src/
prj_2/
`- module_1/
`- module_2/
bin32/
tmp/
`- output32/
   `- prj_1/
   |  `- src/
   `- prj_2/
      `- module_1/
      `- module_2/

В branches/1.3 реализован дополнительный режим обработки C/C++ проектов.
Если в командной строке указать аргумент --mxx-cpp-extract-options, то вместо построения цели будет распечатаны опции компилятора/линкера, которые будут использоваться при компиляции/линковки. Эта возможность предназначена для случаев, когда результат компиляции через Mxx_ru нужно использовать в другой build-системе: другой build-системе придется явно указывать все опции, неявно вычисляемые Mxx_ru.

Например, если взять пример из дистрибутива SObjectizer

Автор: Евгений Охотников
Дата: 30.12.05

и запустить его с опцией --mxx-cpp-extract-options:

ruby sample/high_traffic/prj.rb --mxx-cpp-extract-options

то на стандарный поток вывода будет напечатано (для случая MinGW):

C Compiler Options:
    
C++ Compiler Options:
    
Compiler options:
    -DMXX_RU_ACE__PLATFORM_WIN32
    -DWIN32
    -DSO_4_DLL
    -I.
    -Iso_4/zlib
    -mthreads
Defines:
    MXX_RU_ACE__PLATFORM_WIN32
    WIN32
    SO_4_DLL
Include Paths:
    .
    so_4/zlib
Librarian Options:
    
Linker Options:
    --shared-libgcc
    -mconsole
MSWindows Resource Compiler Defines:
    
MSWindows Resource Compiler Include Paths:
    
MSWindows Resource Compiler Options:
    -D MXX_RU_ACE__PLATFORM_WIN32
    -D WIN32
    -D SO_4_DLL
    --include-dir=.
    --include-dir=so_4/zlib
MSWindows Resource Linker Options: