Структура проектов на C++ с использованием Subversion и Mxx_ - Средства разработки

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

A>Tag — закреплённое состояние некоторых исходников, в общем-то просто синоним некоторой ревизии для SVN (в других системах это ессно не так). Используется для идентификации состояния исходников в других системах аля bugtracking, testing, integration и т.п. Чем хорош этот синоним — тем, что он собственно может использоваться и без SVN и находится где угодно и при этом его состояние в любой момент будет таким же как и в SVN (Будь это zip архив или даже Version Сontrol другой системы). Следить за тагом не требуется, ведь он никогда не изменяется.

Понятно. Но скажи, ведь выделение tag не означает фиксацию абсолютно безошибочной версии. Обязательно будут находится ошибки, которые будут исправляться в branch-ах и куда-то затем должны помещаться. Т.е. выделяем tags/1.0.0. Правим первый баг, делаем новый tags/1.0.1. Затем исправляем следующий, получаем tags/1.0.2, и т.д. Допустим, исправляем пять багов и получаем пять тегов 1.0.<N> в tags. Это только для одного проекта. Правильно ли я понимаю, что ты предлагаешь (предпочитаешь) этот путь?

Теперь представим, что мы исправляли ошибки в подпроекте (например, oess_1), который, в свою очередь входит в подпроект so_4, который в свою очередь входит в подпроект aag_3. Итак, есть oess_1/tags/1.0.0, oess_1/tags/1.0.1 и т.д., oess_1/tags/1.0.5. Есть so_4/tags/4.3.2, который был построен на oess_1/tags/1.0.0. Что нужно сделать с so_4, чтобы перейти на oess_1/tags/1.0.5? Просто сменить externals в so_4/tags/4.3.2 или же создать новый тег so_4/tags/4.3.3? Наверное, создать новый тег, т.к. не факт, что исправление ошибки в oess_1/tags/1.0.5 не выявило какую-то скрытую ошибку в so_4. Итого, получается, что как только мы выделяем новый тег с bugfix-ом в подпроекте so_4, мы должны делать новый тег в so_4. Если so_4 зависит не только от oess_1, а еще от четырех подпроектов, то новый тег в so_4 будет создаваться при появлении нового тега в любом из подпроектов. И то же самое будет происходить в aag_3. Т.е. исправление на самом нижнем уровне пирамиды взаимосвязей проектов будет приводить к каскадному росту числа тегов к вершине пирамиды.

Так это представляется мне. Или же ты пользуешься какой-то другой схемой?

А впечатление от самой статьи есть какие-нибудь?

ЕО>Статья:
ЕО>Структура проектов на C++ с использованием Subversion и Mxx_ru

Я в статье описываю идею добавления в имя верхнего пространства имен номера версии (т.е. oess_1, so_4, smart_ref_3 и т.д.). Но нигде больше подобных вещей не видел. До недавнего времени. В мартовском выпуске "ACE News and Tips Newsletter" говорится буквально следующее:

ACE's popularity is growing by the day it seems, and with the increased popularity, it's becoming more common for multiple applications on a system to require ACE. This can cause problems because:

* Different ACE releases can have API differences
* Rebuilding ACE with a different compiler version can change the name mangling
* Some applications may require different features or settings than others

Prior to ACE 5.5, these issues often forced developers to build and use ACE as a statically linked library or to take some other nonstandard approach to isolating the needed version of ACE.

Beginning with ACE 5.5, there is a new feature designed to help alleviate these difficulties. The ACE Namespace Versioning provides a means for ACE-based application developers to avoid symbol conflicts by using versioned namespaces. This is an optional feature and its default setting is off (disabled) equivalent to all prior versions of ACE. When enabled, ACE's versioned namespace support causes all ACE symbols (classes, free functions, etc.) to be placed within a C++ namespace of the form namespace ACE_<ACE-version>. For example, at ACE 5.5, the default namespace name is ACE_5_5_0. The ACE_Reactor would end up being placed in the versioned namespace like this:
       namespace ACE_5_5_0
       {
         class ACE_Reactor
         {
           ...
         };
       }
       using namespace ACE_5_5_0;

Вот, теперь и они додумались

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

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

ЕО>>Статья:
ЕО>>Структура проектов на C++ с использованием Subversion и Mxx_ru

E>Я в статье описываю идею добавления в имя верхнего пространства имен номера версии (т.е. oess_1, so_4, smart_ref_3 и т.д.). Но нигде больше подобных вещей не видел. До недавнего времени.

Я вообще-то не удивлён, что такие пространства имён не используются, потому как это скорее напоминает заплатку для версионности АПИ, чем для реального разделения по пространствам имён (как я понимаю делается это для того, чтобы избавится от несовместимостей АПИ в разных версиях библиотеки), какие проблемы будет решать такая конвенция наименования? .

1) В COM помнится я видел уже подобное аля IClassFactory2, IProvideClassInfo2, INavigate2 и т.п. не сказал бы что это мне понравилось, скорее даже наоборот. При этом тут, кстати, всё намного лучше, то есть пока не реализован новый интерфейс, то объекты пользуются старым, а здесь же простая смена пространства имён может приводить к гораздо более существенным проблемам с несовместимостью внутреннего АПИ.
2) При переходе с одной версии на другую, что предполагается делать? Есть ли вариант, что somenamespace_1::MyAPIFunction будет отличаться от somenamespace_2::MyAPIFunction порядком параметров, типом параметров, типом результата и т.п. (выбрасываемыми исключениями например

).
3) Что произойдёт если я просто поменяю using namespace somenamespace_1 на using namespace somenamespace_2, могут ли при этом возникать ошибки логического плана, которые не так просто отследить в большом проекте?

Больше всего в такой конвенции меня смущает именно последняя проблема, ошибки компиляции легко определятся компилятором, но вот маскировка несовместимости в логике вызова АПИ пространством имён ...

С Уважением, Andir!

using( RSDN@Home 1.2.0 alpha rev. 635 ) { /* Работаемс ... */ }

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

Продолжаем разговор, извиняюсь, но в дело вмешался случай и я видно не отправил ответ в прошлый раз.

A>>Tag — закреплённое состояние некоторых исходников, в общем-то просто синоним некоторой ревизии для SVN (в других системах это ессно не так). ...
E>Понятно. Но скажи, ведь выделение tag не означает фиксацию абсолютно безошибочной версии. Обязательно будут находится ошибки, которые будут исправляться в branch-ах и куда-то затем должны помещаться. Т.е. выделяем tags/1.0.0. Правим первый баг, делаем новый tags/1.0.1. Затем исправляем следующий, получаем tags/1.0.2, и т.д. Допустим, исправляем пять багов и получаем пять тегов 1.0.<N> в tags. Это только для одного проекта. Правильно ли я понимаю, что ты предлагаешь (предпочитаешь) этот путь?

Таги не делаются так часто, таг это просто отметка какой-то логической точки в проекте (milestones, alpha, beta, gamma и т.п.). Баги в тагах не правятся, они правятся в основной ветке и когда достигается следующая логическая точка, то создаётся новый таг.

E>Теперь представим, что мы исправляли ошибки в подпроекте (например, oess_1), который, в свою очередь входит в подпроект so_4, который в свою очередь входит в подпроект aag_3. Итак, есть oess_1/tags/1.0.0, oess_1/tags/1.0.1 и т.д., oess_1/tags/1.0.5. Есть so_4/tags/4.3.2, который был построен на oess_1/tags/1.0.0. Что нужно сделать с so_4, чтобы перейти на oess_1/tags/1.0.5? Просто сменить externals в so_4/tags/4.3.2 или же создать новый тег so_4/tags/4.3.3? Наверное, создать новый тег, т.к. не факт, что исправление ошибки в oess_1/tags/1.0.5 не выявило какую-то скрытую ошибку в so_4. Итого, получается, что как только мы выделяем новый тег с bugfix-ом в подпроекте so_4, мы должны делать новый тег в so_4. Если so_4 зависит не только от oess_1, а еще от четырех подпроектов, то новый тег в so_4 будет создаваться при появлении нового тега в любом из подпроектов. И то же самое будет происходить в aag_3. Т.е. исправление на самом нижнем уровне пирамиды взаимосвязей проектов будет приводить к каскадному росту числа тегов к вершине пирамиды.
E>Так это представляется мне. Или же ты пользуешься какой-то другой схемой?

В общем в этом случае уже используются brunches. Ты же не станешь использовать в проекте нестабильную библиотеку (аля trunk, tags), а вот стабильная на некоторый момент версия (в некотором роде) и должна выносится в новую ветку, ака 'alpha 0.29', 'release 1.0' ... практически все изменения в этих ветках должны попасть потом и в основную ветку (trunk).

E>А впечатление от самой статьи есть какие-нибудь?

Если закрыть глаза на неочевидность приёмов, а рассматривать применимость именно данной схемы, то очень неплохо. И её очень хорошо рассматривать как один из вариантов гайдлайнсов для разработки, на базе которого можно построить более подходящий (ср. RSDN Coding Conventions GuideLines).

C Уважением, Andir!

using( RSDN@Home 1.2.0 alpha rev. 635 ) { /* Работаемс ... */ }

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

E>>Понятно. Но скажи, ведь выделение tag не означает фиксацию абсолютно безошибочной версии. Обязательно будут находится ошибки, которые будут исправляться в branch-ах и куда-то затем должны помещаться. Т.е. выделяем tags/1.0.0. Правим первый баг, делаем новый tags/1.0.1. Затем исправляем следующий, получаем tags/1.0.2, и т.д. Допустим, исправляем пять багов и получаем пять тегов 1.0.<N> в tags. Это только для одного проекта. Правильно ли я понимаю, что ты предлагаешь (предпочитаешь) этот путь?

A>Таги не делаются так часто, таг это просто отметка какой-то логической точки в проекте (milestones, alpha, beta, gamma и т.п.). Баги в тагах не правятся, они правятся в основной ветке и когда достигается следующая логическая точка, то создаётся новый таг.

Если я правильно понимаю, ты предлагаешь, зная про наличие багов в каком-то tag-е, не изменять его до тех пор, пока не подойдет какая-нибудь очередная логическая точка. Т.е., мы оказываемся в ситуации, когда говорим заказчику: да, проблема у нас есть, но мы ее исправим в ближайшей версии.

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

Но, если речь идет не о прикладных проектах, а о библиотеках, то это далеко не всегда так. Особенно, если мы попробуем говорить о библиотеках для "внутреннего" пользования или OpenSource проектов (у которых нет жесткого графика развития и реализации). Вот, например, у меня есть библиотеки cls_2 и smart_ref_3, которые давно дошли до некой точки замерзания и уже давно законсервированы -- их возможностей с лихвой хватает для текущих нужд. Если в cls_2 обнаруживается баг или проблема под каким-то новым компилятором, я не могу отложить ее устранение на неопределенно долгий срок, т.к. вообще не уверен, будет ли в этом проекте следующая логическа точка. Я предпочитаю, чтобы cls_2 была приведена в работоспособное состояние как можно раньше.

Еще сложнее, когда исходники каких-то библиотек делаются доступными нашим заказчикам (например, через svn). Заказчик находит critical bug, из-за которого его разработка останавливается. Мы не можем тянуть с исправлением ошибки. И можем не иметь возможности сказать ему, подождите до версии 1.(N+1), т.к. у нас может быть с этим заказчиком договор только на предоставление ему версии 1.0 и поддержки ее (только поддержки, без предоставления новых версий) в течении некоторого срока. В таких условиях мне кажется более правильным закомитить bugfix в тот же tag и сделать этот bugfix сразу же доступным для заказчика.

E>>Теперь представим, что мы исправляли ошибки в подпроекте (например, oess_1), который, в свою очередь входит в подпроект so_4, который в свою очередь входит в подпроект aag_3. Итак, есть oess_1/tags/1.0.0, oess_1/tags/1.0.1 и т.д., oess_1/tags/1.0.5. Есть so_4/tags/4.3.2, который был построен на oess_1/tags/1.0.0. Что нужно сделать с so_4, чтобы перейти на oess_1/tags/1.0.5? Просто сменить externals в so_4/tags/4.3.2 или же создать новый тег so_4/tags/4.3.3? Наверное, создать новый тег, т.к. не факт, что исправление ошибки в oess_1/tags/1.0.5 не выявило какую-то скрытую ошибку в so_4. Итого, получается, что как только мы выделяем новый тег с bugfix-ом в подпроекте so_4, мы должны делать новый тег в so_4. Если so_4 зависит не только от oess_1, а еще от четырех подпроектов, то новый тег в so_4 будет создаваться при появлении нового тега в любом из подпроектов. И то же самое будет происходить в aag_3. Т.е. исправление на самом нижнем уровне пирамиды взаимосвязей проектов будет приводить к каскадному росту числа тегов к вершине пирамиды.
E>>Так это представляется мне. Или же ты пользуешься какой-то другой схемой?

A>В общем в этом случае уже используются brunches. Ты же не станешь использовать в проекте нестабильную библиотеку (аля trunk, tags), а вот стабильная на некоторый момент версия (в некотором роде) и должна выносится в новую ветку, ака 'alpha 0.29', 'release 1.0' ... практически все изменения в этих ветках должны попасть потом и в основную ветку (trunk).

Кстати, иногда использую. Например, сейчас у меня есть проект so_sysconf_2, который остановился в branches/2.3. Он достиг стабильной, рабочей версии, но еще не протестирован на всех платформах. Поэтому проекты, которым нужна функциональность из 2.3 уже используют его. В branches/2.3 не будет расширения функциональности, это уже замороженная версия. Если все же расширение потребуется, то я просто скопирую branches/2.3 в branches/2.3.1. Но я не вижу большого смысла делать копию в tags/2.3.beta1.

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

A>Я вообще-то не удивлён, что такие пространства имён не используются, потому как это скорее напоминает заплатку для версионности АПИ, чем для реального разделения по пространствам имён (как я понимаю делается это для того, чтобы избавится от несовместимостей АПИ в разных версиях библиотеки), какие проблемы будет решать такая конвенция наименования? .

Это наименование должно позволить решить проблему одновременного использования разных версий (поколений) проектов в одном монолитном проекте.

Например, сейчас у нас используются два протокола для работы с клиентами: mbsms_1 и mbsms_2. Новые клиенты подключаются по mbsms_2, старые по mbsms_1. Сам сервер использует mbsms_2. Для того, чтобы сервер не заморачивался на поддержку mbsms_1 сделан mbsms_gate, который автоматически конвертирует mbsms_1 в mbsms_2 и обратно. Т.е. для сервера все подключения идут только через mbsms_2.

Так вот в mbsms_gate нужно одновременно использовать код mbsms_1 и mbsms_2. В этих библиотеках пересечение имен близко к 95% (если не к 99%): одни и те же названия заголовочных файлов, одни и те же названия namespace/классов/констант/функций, одни и те же названия библиотек. Единственное, что позволяет их отличать -- это номер поколения проекта в самом верхнем пространстве имен. Это позволяет мне в одном исходном файле mbsms_gate использовать обе библиотеки одновременно. Например:
Подгрузка заголовочных файлов:

#include <mbsms_1/h/pub.hpp>
#include <mbsms_1/h/private.hpp>

#include <mbsms_2/h/pub.hpp>
#include <mbsms_2/h/private.hpp>

Использование классов из разных пространств имен одновременно:

/*!
    \brief Конвертирует результат отсылки SMS из mbsms_2 в mbsms_1.
*/
mbapi_3::result_shptr_t
convert_v2result( const mbapi_3::result_t & r )
    {
        if( mbsms_2::routing_failure_result_t::result_type == r.query_type() )
            // Этого типа в mbsms_1 не было.
            // Заменяем на mbsms_1::smpp_smsc_result_t.
            return mbapi_3::result_shptr_t(
                    // Возвращаем код ESME_RPROHIBITED.
                    new mbsms_1::smpp_smsc_result_t( 0x101 ) );

        if( mbsms_2::smpp_smsc_result_t::result_type == r.query_type() )
            {
                // Нужно сохранить SMPP command_status.
                const mbsms_2::smpp_smsc_result_t & v2result =
                        dynamic_cast< const mbsms_2::smpp_smsc_result_t & >( r );
                return mbapi_3::result_shptr_t(
                        new mbsms_1::smpp_smsc_result_t(
                                v2result.query_command_status() ) );
            }

        // Сохраняем result тем же самым.
        return mbapi_3::result_shptr_t( r.clone() );
    }

Линковаться к двум разным версиям библиотек одновременно:

require 'mxx_ru/cpp'

require 'oess_1/util_cpp_serializer/gen'

Mxx_ru::setup_target(
    Mxx_ru::Cpp::Dll_target.new( "mbsms_gate_1/prj.rb" ) do

#<...skipped...>

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

        required_prj "mbsms_1/prj.rb"
        required_prj "mbsms_2/prj.rb"

        target "mbsms_gate"

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

        cpp_source "cfg.cpp"

#<...skipped...>

    end
)

Ничего подобного бы у меня не получилось, если бы я использовал для mbsms-библиотек пространство имен mbsms, путь к заголовочным файлам <mbsms/h>, библиотеки mbsms.lib.

A>2) При переходе с одной версии на другую, что предполагается делать? Есть ли вариант, что somenamespace_1::MyAPIFunction будет отличаться от somenamespace_2::MyAPIFunction порядком параметров, типом параметров, типом результата и т.п. (выбрасываемыми исключениями например

).

Просто адаптироваться к новым условиям работы. При этом ты явно знаешь, где тебе нужно что-то менять, т.к. видишь, где именно используются somenamespace_1.

A>3) Что произойдёт если я просто поменяю using namespace somenamespace_1 на using namespace somenamespace_2, могут ли при этом возникать ошибки логического плана, которые не так просто отследить в большом проекте?

Это зависит от конкретной задачи. Если изменения слишком серьезные, то простая замена, естественно, не пройдет.
Но, если какие-то куски функциональности существенно не изменились, то ничего страшного не будет. В уже показанном выше примере с mbsms_2 оказалось, что в большинстве случаев, в прикладном коде достаточно было просто сменить mbsms_1 на mbsms_2, и только в очень ограниченном числе мест реально потребовалась адаптация к новому протоколу. Но это была действительно серьезная адаптация.

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

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

Ммм. Я так понимаю ты никогда не работал в CVS

Там при всём желании исправить никакой таг нельзя — это просто логическая метка определённой ревизии ... Отсюда и вся логика. То есть то что ты называешь тагами, которые хочешь исправлять — это и есть brunches, только ты имена им даёшь 'tags'.

C Уважением, Andir!

using( RSDN@Home 1.2.0 alpha rev. 643 ) { /* Работаем */ }

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

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

Только из-за последнего пункта я бы отказался от такой практики

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

C Уважением, Andir!

using( RSDN@Home 1.2.0 alpha rev. 643 ) { /* Работаем */ }

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

A>Ммм. Я так понимаю ты никогда не работал в CVS

Там при всём желании исправить никакой таг нельзя — это просто логическая метка определённой ревизии ... Отсюда и вся логика. То есть то что ты называешь тагами, которые хочешь исправлять — это и есть brunches, только ты имена им даёшь 'tags'.

Для с CVS не работал, бог миловал

Все, что я говорил, относится именно к Subversion.

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

ЕО>>Статья:
ЕО>>Структура проектов на C++ с использованием Subversion и Mxx_ru

E>Я в статье описываю идею добавления в имя верхнего пространства имен номера версии (т.е. oess_1, so_4, smart_ref_3 и т.д.). Но нигде больше подобных вещей не видел. До недавнего времени. В мартовском выпуске "ACE News and Tips Newsletter" говорится буквально следующее:
E>

E>The ACE Namespace Versioning provides a means for ACE-based application developers to avoid symbol conflicts by using versioned namespaces...
E>
E>       namespace ACE_5_5_0
E>       {
E>         class ACE_Reactor
E>         {
E>           ...
E>         };
E>       }
E>       using namespace ACE_5_5_0;
E>

Оказывается, все новое -- это хорошо забытое старое. Только что вычитал этот трюк у Страуструпа в "Дизайн и эволюция C++" (раздел 17.4.4 "Использование пространств имен для управления версиями"). Впервые данный способ продемонстрирован Страуструпу Тандж Беннет (Tanj Bennett).

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

// ace_ns.hpp
namespace ACE = ACE_5_5_0;

затем файл ace_ns.hpp используется при работе с библиотекой ACE:

#include "ace_ns.hpp"

class MyReactor : public ACE::ACE_Reactor { ... };

При необходимости смены версии ACE достаточно поменять только строчку в ace_ns.hpp.

От:	eao197	http://eao197.blogspot.com
Дата:	19.01.06 07:41
Оценка:

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

От:	Andir	http://twitter.com/AndirNotes
Дата:	03.04.06 21:12
Оценка:

От:	Andir	http://twitter.com/AndirNotes
Дата:	03.04.06 21:12
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	04.04.06 05:10
Оценка: