Как да модифицирам/заменям файла с набор от опции при изграждане от командния ред?

Създавам пакети от пакетен файл, използвайки команди като:

msbuild ..\lib\Package.dproj /target:Build /p:config=%1

Настройките на пакетите зависят от набор от опции:

<Import Project="..\optionsets\COND_Defined.optset" Condition="'$(Base)'!='' And Exists('..\optionsets\COND_Defined.optset')"/>

Този набор от опции дефинира условен символ, от който зависят много от моите пакети. Файлът изглежда така:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <DCC_Define>CONDITION;$(DCC_Define)</DCC_Define>
    </PropertyGroup>
    <ProjectExtensions>
        <Borland.Personality>Delphi.Personality.12</Borland.Personality>
        <Borland.ProjectType>OptionSet</Borland.ProjectType>
        <BorlandProject>
            <Delphi.Personality/>
        </BorlandProject>
        <ProjectFileVersion>12</ProjectFileVersion>
    </ProjectExtensions>
</Project>

Сега имам нужда от две компилации: една с дефинирано условие и една без. Моят вектор за атака ще бъде файлът с набор от опции. Имам няколко идеи какво да направя:

  • напишете програма, която модифицира файла с набор от опции, стартирайте това преди пакетно изграждане
  • поиграйте с файловете на проекта и променете пътя на набора от опции, за да съдържа променлива на средата, след което разполагайте с различни набори от опции на различни места

Но преди да започнем да преоткриваме колелото, бих искал да попитам как бихте се справили с тази задача? Може би вече има средства, предназначени да поддържат такъв случай (като определени превключватели на командния ред, неща, които мога да конфигурирам в Delphi или магия на партиден файл).


deployment delphi delphi-2009
person Heinrich Ulbricht    schedule 29.11.2011    source източник

Отговори (2)


arrow_upward
3
arrow_downward

Начинът, по който подхождам към това, е да дефинирам множество конфигурации за изграждане и след това да избера подходящата по време на изграждане с /p:config=XXX. Работи добре и в IDE, защото можете просто да щракнете два пъти върху конфигурацията за изграждане в мениджъра на проекти, за да я активирате.

Аз лично използвам наследяване на конфигурации за изграждане, когато правя това, за да не се налага да се повтарям. Например имам конфигурация за компилация с име Debug DCUs, която наследява от конфигурацията Debug и просто променя опцията Debug DCUs на True.

За да обясня какво имам предвид, ето как изглежда конфигурационното дърво на компилацията в моя проект:

въведете описание на изображението тук

Конфигурацията Debug DCUs се осъществява с помощта на този набор от опции:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <DCC_DebugDCUs>true</DCC_DebugDCUs>
    </PropertyGroup>
    <ProjectExtensions>
        <Borland.Personality>Delphi.Personality.12</Borland.Personality>
        <Borland.ProjectType>OptionSet</Borland.ProjectType>
        <BorlandProject>
            <Delphi.Personality/>
        </BorlandProject>
        <ProjectFileVersion>12</ProjectFileVersion>
    </ProjectExtensions>
</Project>

Сигурен съм, че бихте могли да направите това, като използвате /p:DCC_Define=XXX, но мисля, че е по-чисто да използвате конфигурациите за компилация, така че да сте сигурни, че това, което получавате в IDE, е същото като това, което получавате от компилациите на командния ред.

Не бих препоръчал нито един от двата подхода във вашия списък с точки. Тези подходи ми изглеждат изключително крехки.

person David Heffernan    schedule 29.11.2011
comment
Наборът от опции изглеждаше добър начин да отида дори едно ниво по-високо в конфигурационната йерархия, защото можех на едно място да променя конфигурацията за всички зависими пакети. Но може би не е толкова голяма разлика в сравнение с използването на Configuration Manager. - person Heinrich Ulbricht; 29.11.2011
comment
Конфигурациите на компилация са фантастични за QA и повторяемост. Обичам ги! Все още не разбирам как да ги работя перфектно, но това е друга история!! - person David Heffernan; 29.11.2011
comment
Това означава ли, че не променяте нищо директно в конфигурациите за компилация (напр. Debug), а по-скоро дефинирате настройките в наборите от опции, които се добавят като справка? Така че конфигурациите за изграждане изграждат йерархията и наборите от опции носят настройките? - person Heinrich Ulbricht; 29.11.2011
comment
Да това е вярно. По този начин мога да споделя своите набори от опции във всички мои различни проекти. - person David Heffernan; 29.11.2011
comment
Това решава проблема с непоследователните настройки на проекта веднъж завинаги! много ми харесва! - person Heinrich Ulbricht; 29.11.2011
comment
Имах само едно притеснение: случаят, в който имате напр. четири различни условни символа и трябва да ги комбинирате по различни начини. Ще трябва да създам много конфигурации за изграждане за всяка комбинация. Това ме накара да се замисля за генерирането на набор от опции. Какво мислиш за това? Или това все пак е провал на дизайна? - person Heinrich Ulbricht; 29.11.2011
comment
Съгласен съм, че изборът и изборът от по-голям брой опции бързо става тромав чрез конфигурациите за изграждане. - person David Heffernan; 30.11.2011

arrow_upward
1
arrow_downward

Едно заобиколно решение е временно да преименувате файла .optset; това на практика го деактивира, тъй като посоченият файл не може да бъде намерен. Можете да го направите от пакетния си файл, преди да извикате msbuild. Това работи само за набори от опции, използвани като референтни - както във вашия случай.

Друга възможност е ръчно да вмъкнете директива <Import> във файла .dproj:

<Import Condition="Exists('$(OptSet)')" Project="$(OptSet)"/>

След това можете да зададете свойството OptSet от командния ред, което ще импортира набора от опции:

msbuild /t:Build /p:Config=Release /p:OptSet=myoptset.optset myproject.dproj

Без настройка на свойството OptSet наборът от опции няма да бъде импортиран:

msbuild /t:Build /p:Config=Release myproject.dproj
person Ondrej Kelle    schedule 29.11.2011