Здравствуйте, 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ы заняться изучением...
Функционал -- это как пословица: "Были бы кости, мясо наростет". Кости есть.
