Re[2]: [ANN] Mxx_ru v.1.1 - Средства разработки

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

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

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

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

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

Так все-таки target_ext или target_exe? (код в примере сбивает с толку).

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

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

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

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

M>Так все-таки target_ext или target_exe? (код в примере сбивает с толку).

target_ext, я очепятался

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

Не знаю... Мне кажется, что менять еще и расширение для import_lib -- это вообще overkill. Поэтому вариант, когда кому-то может потребоваться поменять еще и имя библиотеки импорта пока не рассматривается (до поступления описаний реальных случаев необходимости оного). Опять же, import_lib -- это специфика Windows и OS/2.

Я же исходил из того, что один метод target_ext будет проще использовать и он менее череват ошибками, чем отдельные методы для каждого типа целей. Ведь тогда человек сможет написать, например, так:

Mxx_ru::Cpp::exe_target {
  dll_ext '.mll' # Oops! А ведь строим exe.
  ...
}

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

E>Не знаю... Мне кажется, что менять еще и расширение для import_lib -- это вообще overkill. Поэтому вариант, когда кому-то может потребоваться поменять еще и имя библиотеки импорта пока не рассматривается (до поступления описаний реальных случаев необходимости оного). Опять же, import_lib -- это специфика Windows и OS/2.

E>Я же исходил из того, что один метод target_ext будет проще использовать и он менее череват ошибками, чем отдельные методы для каждого типа целей. Ведь тогда человек сможет написать, например, так:
E>

E>Mxx_ru::Cpp::exe_target {
E>  dll_ext '.mll' # Oops! А ведь строим exe.
E>  ...
E>}
E>

Согласен, если принять как правило один таргет — один файл, то никаких проблем возникнуть не должно.

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

M>Согласен, если принять как правило один таргет — один файл, то никаких проблем возникнуть не должно.

Вот и я о том же.

Оставляем существующий вариант с Target#target_ext?

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

E>Оставляем существующий вариант с Target#target_ext?

Ага. Только я его еще не тестировал..

В branches/1.3 реализована новая обработка имен библиотек, перечисляемых в проектном файле через метод Target#lib. Теперь для платформы mswin не обязательно указывать расширение '.lib'. Если это расширение не указано, то тулсеты для Visual C++ добавляют его автоматически. Т.о. появляется возможность указывать одинаковые имена на разных платформах, например:

lib( "Foundation", "#{API_PATH}/lib" )
lib( "OpenMaya" )
lib( "OpenMayaFX")

Небольшое пояснение: расширение '.lib' требовалось указывать для компилятора Visual C++ (единственный поддерживаемый Mxx_ru компилятор, который не имел специальной опции линкера для отделения имени библиотеки от имени объектного файла). Поэтому потребовалось немного модифицировать тулсет VC для того, чтобы проверять имена библиотек на наличие/отсутствие расширения '.lib'.

В Mxx_ru сейчас нет возможности задавать имена библиотек с нестандартными расширениями. Например, если указать:

lib( 'somelib.static' )

то для VC это имя будет преобразовано к somelib.static.lib, а под Unix-ом будет искаться библиотека libsomelib.static.a.

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

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

E>В branches/1.3 реализована новая обработка имен библиотек, перечисляемых в проектном файле через метод Target#lib. Теперь для платформы mswin не обязательно указывать расширение '.lib'. Если это расширение не указано, то тулсеты для Visual C++ добавляют его автоматически. Т.о. появляется возможность указывать одинаковые имена на разных платформах, например:

E>lib( "Foundation", "#{API_PATH}/lib" )
E>lib( "OpenMaya" )
E>lib( "OpenMayaFX")

Супер. Теперь бы к этому всему еще и методы lib_path, lib_paths добавить, и будет вообще красота =)

E>В Mxx_ru сейчас нет возможности задавать имена библиотек с нестандартными расширениями. Например, если указать:

 E>lib( 'somelib.static' )

E>то для VC это имя будет преобразовано к somelib.static.lib, а под Unix-ом будет искаться библиотека libsomelib.static.a.

E>Нестандартные расширения для библиотек это вообще очень спорный вопрос и не понятно, нужна ли эта поддержка вообще. Т.к. большинство компиляторов придерживаются строгих правил о том, какие имена/расширения должны быть у библиотек. Поэтому поддержка нестандартных расширений имен библиотек может быть добавлена в Mxx_ru только если такая необходимость действительно возникнет.

Я лично встречал в mentalray API под линуксом библиотеку, названную как shader.34.lib (без префикса) и мне пришлось ее линковать как объектный файл,

 obj_file( "#{MAYALOC}/devkit/mentalray/shaders/public-baseshaders/shader.34.lib")

А как ее динамически прицепить с таким именем, под линуксом, я вообще не понял =( Там же компилятор всегда сам префикс (и постфикс) lib добавляет...

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

M>

E>>lib( "Foundation", "#{API_PATH}/lib" )
E>>lib( "OpenMaya" )
E>>lib( "OpenMayaFX")
M>

M>Супер. Теперь бы к этому всему еще и методы lib_path, lib_paths добавить, и будет вообще красота =)

Добавил.
Причем BinaryTarget#lib_path (BinaryTarget#lib_paths) являются синонимами к уже существовавшему методу BinaryTarget#mxx_add_required_lib_path. Отсюда следующий побочный эффект: если в проекте какой-то DLL-ки прописать lib_path, то этот lib_path будет распространнен на все проекты, которые используют данную DLL. Что для Unix-а правильно. Для Windows, в принципе, возможны варианты...

Но, опять таки, будем решать проблемы по мере их поступления.

E>>Нестандартные расширения для библиотек это вообще очень спорный вопрос и не понятно, нужна ли эта поддержка вообще. Т.к. большинство компиляторов придерживаются строгих правил о том, какие имена/расширения должны быть у библиотек. Поэтому поддержка нестандартных расширений имен библиотек может быть добавлена в Mxx_ru только если такая необходимость действительно возникнет.

M>Я лично встречал в mentalray API под линуксом библиотеку, названную как shader.34.lib (без префикса) и мне пришлось ее линковать как объектный файл,

 obj_file( "#{MAYALOC}/devkit/mentalray/shaders/public-baseshaders/shader.34.lib")

M>А как ее динамически прицепить с таким именем, под линуксом, я вообще не понял =( Там же компилятор всегда сам префикс (и постфикс) lib добавляет...

Да за такие вещи чего-нибудь отрывать нужно

Единственный способ, который я вижу -- symbolic link создать на эту библиотеку, но с корректным библиотечным именем.

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

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

А следом первый bug-fix и версия 1.2.1

В branches/1.3 реализовано два новых метода для BinaryTarget: lib_static и lib_shared. На платформе Windows они являются аналогами метода lib. А вот на платформе Unix они предназначены для указания линкеру какой именно вариант библиотеки (статический/динамический) нужно линковать к программе.

В Unix-е применяется практика, когда одна и та же библиотека A существует как статическая (с именем libA.a) и динамическая (с именем libA.so). Когда имя библиотеки A передается линкеру в опции -l (-lA), то линкер сам выбирает, какой из вариантов библиотеки ему нужно взять. Так, по умолчанию, в Linux-е GCC выбирает динамическую библиотеку (т.е., libA.so). Но, если GCC передать опцию -static, то -lA будет указывать линкеру на использование libA.a.

В некоторых случаях программист может захотеть явно указать линкеру под Unix-ом, что требуется взять именно статическую (или именно динамическую) библиотеку. В этом случае Mxx_ru не мог оказать помощи программисту. Для того, чтобы все же дать пользователю Mxx_ru подобную возможность, в версии 1.3 добавлены методы lib_static, предписывающий линкеру использовать только статическую версию библиотеки, и lib_shared, предписывающий линкеру использовать только динамическую версию библиотеки:

require 'mxx_ru/cpp'

Mxx_ru::Cpp::exe_target {
  target 'some_target'
  ...
  lib 'engine' # Линкер может выбрать либо libengine.a, либо libengine.so.
  lib_static 'config' # Линкер обязан выбрать libconfig.a даже если есть libconfig.so.
  lib_shared 'gui' # Линкер обязан выбрать libgui.so даже если есть libgui.a.
  ...
}

Для GCC под Unix-ом обращение к методу lib('A') раскрывается в -lA. Обращение к lib_static('A') по умолчанию раскрывается в -Wl,-Bstatic,-lA,-Bdynamic (это если по умолчанию линкер использует режим -Bdynamic). Соответственно, обращение к lib_shared('A') раскроется в -Wl,-Bdynamic,-lA,-Bstatic, если по умолчанию линкер использует режим -Bstatic.

Для GCC под Unix-ом Mxx_ru v.1.3 считает, что по умолчанию линкер всегда отдает предпочтение динамическим библиотекам (т.е. работает в режиме -Bdynamic). Если же требуется, указать Mxx_ru, что режимом по умолчанию для GCC является -Bstatic, то при конфигурировании тулсета нужно задать тег lib_linking_mode равный static:

export MXX_RU_CPP_TOOLSET='gcc_linux lib_linking_mode=static'

Кстати вопрос к читающим это сообщение Unix-оидам: могут ли они привести примеры платформ, на которых GCC по умолчанию ищет статические библиотеки, а не динамические?

Если Mxx_ru обнаруживает, что одна и та же библиотека указана для цели и как статическая, и как динамическая (т.е. в одном месте она указана как lib_static, а в другом как lib_shared), то Mxx_ru выдает ошибку и останавливается.

После добавления lib_static/lib_shared в Mxx_ru появился следующий побочный эффект. Теперь, подключение через required_prj проекта, описывающего статическую библиотеку, эквивалентен указанию имени этой библиотеки через lib_static. Соответственно, подключение через required_prj динамической библиотеки эквивалентно использованию lib_shared. Т.е.:

# A/prj.rb
Mxx_ru::Cpp::lib_target { target 'A' ... }

# B/prj.rb
Mxx_ru::Cpp::dll_target { target 'B' ... }

# C/prj.rb
Mxx_ru::Cpp::exe_target { target 'C'; required_prj 'A/prj.rb'; required_prj 'B/prj.rb'; ... }

эквивалентно:

# C/prj.rb
Mxx_ru::Cpp::exe_target { target 'C'; lib_static 'A'; lib_shared 'B'; ... }

В данное время не решенным остался следующий вопрос: если пользователь хочет, чтобы его приложение слинковалось только со статическими версиями библиотек, то в Mxx_ru пока нет отдельного метода для указания этого намерения. Единственный вариант -- указать в link_option значение '-static'. Но в этом случае Mxx_ru не сможет выдать предупреждение, если где-то был использован метод lib_shared. Здесь как раз вопрос к пользователям Mxx_ru: нужна ли такая функциональность в Mxx_ru вообще и, если нужна, как она должна выглядеть?

В branches/1.3 добавлена поддержка новой возможности RuCodeGen 0.2.0 по использованию встроенных описаний кодогенерации. В генератор Mxx_ru::Cpp::RuCodeGen добавлен метод add_embeded для того, чтобы перечислять файлы со встроенными описаниями:

require 'mxx_ru/cpp'
require 'mxx_ru/cpp/rucodegen'

Mxx_ru::Cpp::exe_target {
    target "host_config"

    rucodegen = generator Mxx_ru::Cpp::RuCodeGen.new( self )

    cpp_source "host_config.cpp"
    rucodegen.add_embeded "host_config.cpp"

    sources_root( "impl" ) {
        cpp_source "conn_params.cpp"
        rucodegen.add "conn_params.rb"
    }
}

Похоже, что это последняя фича, которая была добавлена в branches/1.3. Далее планируется провести некоторый внутренний рефакторинг кода Mxx_ru и внести в Mxx_ru User Manual описания изменений из 1.2 и 1.3. После чего 1.3 будет официально выпущена.

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

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

А вы не могли бы кратко сравнить свое детище с luntbuild, если я правильно понял, — ваш продукт метит в ту же нишу?

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

X>А вы не могли бы кратко сравнить свое детище с luntbuild, если я правильно понял, — ваш продукт метит в ту же нишу?

Могу попробовать, только для этого документацию по luntbuild придется прочитать.
По первому впечатлению могу сказать, что mxx-ru в эту нишу не метит (пока?). mxx-ru находится в одной категории со SCons, Boost.Build и, возможно, Ant/Nant/MSbuild. Однако то, что в mxx-ru проектные файлы -- это программы на Ruby, может позволить со временем развить mxx-ru в совершенно неожиданных направлениях.

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

X>>А вы не могли бы кратко сравнить свое детище с luntbuild, если я правильно понял, — ваш продукт метит в ту же нишу?

E>Могу попробовать, только для этого документацию по luntbuild придется прочитать.
E>По первому впечатлению могу сказать, что mxx-ru в эту нишу не метит (пока?). mxx-ru находится в одной категории со SCons, Boost.Build и, возможно, Ant/Nant/MSbuild.

Действительно, так и оказалось. luntbuild -- это инструмент совсем другого уровня. Он может использовать mxx-ru в качестве инструмента для выполнения build-а, но mxx-ru не может быть заменой luntbuild. Имхо, их взаимоотношения лучше всего представить видоизменив абзац из manual-а по luntbuild:

Basic unit of work in Luntbuild is a build. Build execution is triggered either by a schedule or it can be started manually. A build in Luntbuild performs following steps:

1. Checks out source code from the Version Control System(s) (VCS).

2. Labels the current source code based on the current build version.

3. Runs an Ant/Maven/Command/Rake/Mxx_ru build script in the source tree.

4. Runs an Ant/Maven/Command/Rake/Mxx_ru post build script in the source tree.

5. Publishes the build log and other build artifacts.

Build configuration, monitoring, and access to the build artifacts are all done using an intuitive web interface.

Надеюсь, у меня получилось ответить на ваш вопрос.

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

Загрузка и обновление

Загрузить можно с RubyForge и затем происталлировать Gem из локальной копии:

gem install Mxx_ru.1.3.0.gem

либо же воспользоваться системой обновлений RubyGem (если Mxx_ru уже проинсталлирован):

gem update Mxx_ru

Примечание. В случае gem update на машине окажется две версии Mxx_ru -- последняя 1.3.0 и предыдущая. Хотя по умолчанию будет использоваться последняя. Если в предыдущих версиях нет необходимости (т.е. в проектных файлах не было привязки к конкретной версии Mxx_ru), то вместо обновления можно просто удалить старую версию и загрузить новую:

gem uninstall Mxx_ru
gem install Mxx_ru -r

Что нового

Добавлен метод MxxRu::Cpp::Target#target_ext (обсуждение см. здесь);

Добавлен еще один тип obj_placement -- CustomSubdirObjPlacement.

Добавлен новый режим --mxx-cpp-extract-options.

Добавлен новый режим --mxx-rebuild (--mxx-clean и последующий build за один заход).

При указании имен библиотек под Windows не обязательно указывать расширение (подробности).

Добавлена возможность явно указывать тип необходимой библиотеки (статичекая или динамическая) через методы BinaryTarget#lib_static, BinaryTarget#lib_shared (подробности).

Добавлена поддержка RuCodeGen 0.2.0 (подробности).

Добавлены методы BinaryTarget#lib_path, BinaryTarget#lib_paths для упрощения задания путей поиска библиотек.

Добавлен метод QtGen#uic_result_subdir, что позволяет размещать результаты работы uic из состава Qt в отдельных подкаталогах.

Именена система именования классов и модулей в Mxx_ru -- теперь она соответствует стандартным соглашениям Ruby. Все старые имена поддерживаются для обеспечения полной совместимости с предыдущими версиями.

О грусном

Задержка в несколько недель с выходом официального релиза 1.3 была вызвана необходимостью написания документации, которая бы отражала изменения в версиях 1.2 и 1.3 (теперь Mxx_ru серьезно отличается от того, что было в версии 1.1). Но, к сожалению, в последний момент наш переводчик был вынужден на время оставить проект. Поэтому сейчас документация оставлена в варианте, где все новые возможности описаны на русском среди англоязычного текста

Поэтому мы пока решили выпустить релиз без документации. А документация... Как нибудь потом. Если только кто-нибудь не поможет

	От:	mlesin
	Дата:	24.04.06 08:24
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	24.04.06 08:33
Оценка:

	От:	mlesin
	Дата:	24.04.06 14:57
	Оценка:	+1

От:	eao197	http://eao197.blogspot.com
Дата:	24.04.06 15:02
Оценка:

	От:	mlesin
	Дата:	24.04.06 15:07
	Оценка:

	От:	xtile
	Дата:	18.05.06 19:37
	Оценка: