Предлагаю пренести Интеграции в проект компилятора - Интеграция Nemerle и Visual Studio

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

Выходные не прошли бесследно

Предлагаю посмотреть на мой патч и покритиковать.

Установка патча:
1. Скачать и распаковать Rev8060.rar
2. Скопировать папку Nemerle поверх корня компилятора.
3. Применить патч.

Некоторые варианты сборки:
1. msbuild NemerleAll.nproj — сборка компилятора, утилит, интеграции, shell-а, инсталлятора. Затем бинарники компилятора копируются в Program Files и регистрируются в реестре.
2. msbuild NemerleAll.nproj /t:Installer — то же, что и в п.1, но без копирования и регистрации в Program Files
3. msbuild NemerleAll.nproj /t:Stage2 — двухпроходная сборка сомпилятора
4. msbuild NemerleAll.nproj /t:VSIntegration — снячала двухпроходная сборка компилятора, потом — интеграция
5. msbuild NemerleAll.nproj /t:RegBoot — зарегистрировать *.targets в boot
Реально вариантов больше, кому интересно — см. NemerleAll.nproj

VD>Было бы сдорово вообще избавиться от батников перенеся весь процесс сборки в msbuild.
Готово, но требует критики.

VD>Что желательно сделать:
VD>1. Солюшен сборки компилятора. Он должен компилировать компилятор и производить его регистрацию. Нужно сделать так чтобы можно было компилировать и без регистрации. Кроме того регистрация должна производиться как в %ProgramFiles%\Nemerle, так и в boot.
Готово.
3. msbuild NemerleAll.nproj /t:Stage2

VD>Кроме того должна поддерживаться двух студийная сборка проекта (сначала собирается компилятор в некой промежуточной директории, например, stage2, а потом компилятор собирается полученными на предыдущей стадии бинарниками). При неудаче сборки ничего не должно быть унитожено. Бут должен изменяться только при успешном завершении второй стадии компиляции.
Готово, требует тестирования, т.к. реальную ситуацию с ошибкой я создать не смог, но если генерировать ошибку искуственно, то откат работает. В общем нужно тестировать.

VD>Желательно (но не обязательно) сделать и третью стадию компиляции которая бы собирала исходники бинарниками созданными на второй стадии. Эти бинарники нужно сравнить с бинарниками получеными на второй стадии. Если они не равны, то процесс сборки должен считаться неудачным. Это конечно немного параноя, но так было сделано в исходном процессе сборки компилятора (том который был на Гну-сных утилитах основан). Да, желательно, чтобы этот солюшен собирал и МСБилдный таск.
Этого пока не делал.

VD>2. Еще один солющен должен собирать утилиты и прочую дрибедень.
2. msbuild NemerleAll.nproj /t:Tools

VD>3. Третий солюшен должен собирать интеграцию.
4. msbuild NemerleAll.nproj /t:VSIntegration

VD>4. Ну, и должен быть еще один солюшен который собирает три предыдущих солюшена (точнее проекты из них) и собирает инсталлятор.
2. msbuild NemerleAll.nproj /t:Installer

VD>5. Кроме того хорошо бы сделать еще один солюшен который собирал бы компилятор и интеграцию и прогонял тесты. В случае успеха можно комитить изменения. Если автоматизировать еще и комит — это будет вообще супер.
Это чуть позже — времени не хватило.

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

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

VD>>Если нет, то можно как-то при переносе оставить историю файлов?

IT>Можно попробовать в RepoБраузере каталоги мышкой потаскать.

Зачем нам маны, даешь импровизацию

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

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

VD>>Предлагаю пренести Интеграции в проект компилятора.
GR>Мысль здравая. Это сильно упростит сборку всего солюшина. Если что, я готов с msbuild-ом повоевать.
GR>Еще хотелось бы избавиться от батников. Все можно сделать в виде msbuild task-ов.

Я перенес папку Интеграци, так что можно заняться причесыванием msbuild-ных фалов.

Было бы сдорово вообще избавиться от батников перенеся весь процесс сборки в msbuild.

Что желательно сделать:
1. Солюшен сборки компилятора. Он должен компилировать компилятор и производить его регистрацию. Нужно сделать так чтобы можно было компилировать и без регистрации. Кроме того регистрация должна производиться как в %ProgramFiles%\Nemerle, так и в boot. Кроме того должна поддерживаться двух студийная сборка проекта (сначала собирается компилятор в некой промежуточной директории, например, stage2, а потом компилятор собирается полученными на предыдущей стадии бинарниками). При неудаче сборки ничего не должно быть унитожено. Бут должен изменяться только при успешном завершении второй стадии компиляции. Желательно (но не обязательно) сделать и третью стадию компиляции которая бы собирала исходники бинарниками созданными на второй стадии. Эти бинарники нужно сравнить с бинарниками получеными на второй стадии. Если они не равны, то процесс сборки должен считаться неудачным. Это конечно немного параноя, но так было сделано в исходном процессе сборки компилятора (том который был на Гну-сных утилитах основан). Да, желательно, чтобы этот солюшен собирал и МСБилдный таск.
2. Еще один солющен должен собирать утилиты и прочую дрибедень.
3. Третий солюшен должен собирать интеграцию.
4. Ну, и должен быть еще один солюшен который собирает три предыдущих солюшена (точнее проекты из них) и собирает инсталлятор.
5. Кроме того хорошо бы сделать еще один солюшен который собирал бы компилятор и интеграцию и прогонял тесты. В случае успеха можно комитить изменения. Если автоматизировать еще и комит — это будет вообще супер.

Здравствуйте, gloomy rocker!

GR>Выходные не прошли бесследно

Предлагаю посмотреть на мой патч и покритиковать.
Может ты просто зайдёшь на
http://groups.google.com/group/nemerle-dev?hl=en
и попросишь доступ к репозиторию?

... << RSDN@Home 1.2.0 alpha 4 rev. 1090>>

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

БП>Может ты просто зайдёшь на
БП>http://groups.google.com/group/nemerle-dev?hl=en
БП>и попросишь доступ к репозиторию?

Да, пожалуй стоит так сделать. Только это несколько затянет процесс причесывания msbuild-ных скриптов.

Заодно хотел бы услышать мнение. Сейчас я подправил проекты интеграции и шелла так, чтобы они ссылались на сборки из boot, а не на Program Files\Nemerle. ИМХО это правильней. Если я не прав — покритикуйте.

Еще я реализовал возможность зарегистрировать путь к Nemerle.MSBuild.targets в boot, но толку от этого мало, т.к. во всех шаблонах проектов есть такой код:

    <PropertyGroup>
        <NoStdLib>true</NoStdLib>
        <Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
    </PropertyGroup>

Единственный способ, который я нашел, заставить студию смотреть на boot — определить переменную окружения Nemerle=<путь к boot>. Если такой вариант устроит, то нужно будет в таск RegBoot добавить инструкцию, которая создает эту переменную в системе.

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

GR>Единственный способ, который я нашел, заставить студию смотреть на boot — определить переменную окружения Nemerle=<путь к boot>.

Может какую другую переменную объявить? Типа NemerleBoot. Хорошо бы вообще разделить установленный на машине Nemerle стандартным образом с тем, с чем работают девелоперв. Тогда можно будет писать интеграцию на самой интеграции.

... << RSDN@Home 1.2.0 alpha rev. 771>>

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

GR>Сейчас я подправил проекты интеграции и шелла так, чтобы они ссылались на сборки из boot, а не на Program Files\Nemerle. ИМХО это правильней. Если я не прав — покритикуйте.

Это не верное решение. В boot почти всегда находятся устаревшие версии компилятора. Он нужен исключительно для бутсрипинга. Изменяться boot должен только после успешного прохождения второй стадии компиляции (а по уму и тестов). Файлы в нем должны комититься как можно реже, так как это довольно большие бинарные файлы, к тому же ктитичные.

Кроме того очень важно производить прекомпиляцию сборок компилятора ngen-ом, так как это во много раз ускоряет загрузку компилятора.

GR>Еще я реализовал возможность зарегистрировать путь к Nemerle.MSBuild.targets в boot, но толку от этого мало, т.к. во всех шаблонах проектов есть такой код:

GR>

GR>    <PropertyGroup>
GR>        <NoStdLib>true</NoStdLib>
GR>        <Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
GR>    </PropertyGroup>
GR>

GR>Единственный способ, который я нашел, заставить студию смотреть на boot — определить переменную окружения Nemerle=<путь к boot>. Если такой вариант устроит, то нужно будет в таск RegBoot добавить инструкцию, которая создает эту переменную в системе.

Не надо работать из бута. Можно сделать тупое копирование файлов из бута в %ProgramFiles%\Nemerle, если это кому-то надо. Но надо понимать, что современные версии Интеграции могут попросту не собираться из бута.
Ну, а задать Nemerle можно и через командную строку при запуске MSBuild-а через ключ /property:<n>=<v> или /p:<n>=<v>:

MSBuild.exe /property:Nemerle=D:\MyProjects\Nemerle\nemerle\trunk

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

GR>Выходные не прошли бесследно

Предлагаю посмотреть на мой патч и покритиковать.

Здорово! Молодец.

Несколько вопросов:
1. Поддерживается ли прекомпиляция ngen-ом (как это было в батч.файлах)?
2. Производится ли инициализация ключей реестра вроде HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\MSBuild\SafeImports?

Другими словами насколько полно воспроизведен http:\\nemerle.org\svn\nemerle\trunk\Reg.cmd?

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

Насчет раскоментаривания <DocumentationFile>bin\Debug\Nemerle.XML</DocumentationFile> в дебаге — это приведет к еще большему замедлению процесса компиляции. Так что надо бы защитить описание этих тегов неким условием. Кому надо пусть опишут некое свойство и получат эти файлы (или наоборот, кому не надо опишут некое свойство и файлы документации генерироваться не будут.

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

Кстати, можно попробовать вот эти мсбилдные задачи:
http://msbuildtasks.tigris.org/
С их помощью можно избавиться от вызова внешних утилит и сделать многие фишки вроде комита в SVN-репозиторий.

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

VD>Несколько вопросов:
VD>1. Поддерживается ли прекомпиляция ngen-ом (как это было в батч.файлах)?
VD>2. Производится ли инициализация ключей реестра вроде HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\MSBuild\SafeImports?

Посмотрел исходники... Данные вопросы снимаются. Остается только вопрос не лучше ли использовать сторонние задачи (http://www.rsdn.ru/forum/message/3007014.1.aspx) вместо exe-шников?

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

GR>3. msbuild NemerleAll.nproj /t:Stage2 — двухпроходная сборка сомпилятора
GR>4. msbuild NemerleAll.nproj /t:VSIntegration — снячала двухпроходная сборка компилятора, потом — интеграция

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

GR>5. msbuild NemerleAll.nproj /t:RegBoot — зарегистрировать *.targets в boot

А как регистрировать в %ProgramFiles%\Nemerle?

При работе над интеграцией и компилятором самый частый сценарий это:
1. Однопроходная сборка компилятора.
2. Регистрация файлов компилятора в %ProgramFiles%\Nemerle.
3. Сборка тестов.
4. Сборка Интеграции.

Причем желательно чтобы все эти задачи выполнялись только при успешной сборке предыдущих пунктов (чтобы сборка прерывалась в случае сбоя).
Как это сделать с помощью NemerleAll.nproj?

GR>Реально вариантов больше, кому интересно — см. NemerleAll.nproj

Будем поглядать...

VD>>1. Солюшен сборки компилятора. Он должен компилировать компилятор и производить его регистрацию. Нужно сделать так чтобы можно было компилировать и без регистрации. Кроме того регистрация должна производиться как в %ProgramFiles%\Nemerle, так и в boot.
GR>Готово.
GR>3. msbuild NemerleAll.nproj /t:Stage2

Э... нужно чтобы компиляция и регистрация могла бы производиться в оду стадию. Иначе резко замедлится работа над компилятором. Я выполняю сборку в две стадии исключительно когда подготавливаю файлы к комиту в SVN.

GR>Готово, требует тестирования, т.к. реальную ситуацию с ошибкой я создать не смог, но если генерировать ошибку искуственно, то откат работает. В общем нужно тестировать.

О. Это не проблема. Для этого ошибку надо посадить в макрос которые генерировал бы некорректный код.

VD>>3. Третий солюшен должен собирать интеграцию.
GR>4. msbuild NemerleAll.nproj /t:VSIntegration

Здорово! А перед этим производится компиляция компилятора? Интеграция при этом компилируется уже новой версией компилятора? Зачастую Интеграция может быть скомпилирована только новой версией компилятора, а портить boot нельзя, так как компилятор может и не собраться текущей своей версией (частая ситуация при работе над макросами из стандартной библиотеки).

VD>>4. Ну, и должен быть еще один солюшен который собирает три предыдущих солюшена (точнее проекты из них) и собирает инсталлятор.
GR>2. msbuild NemerleAll.nproj /t:Installer

Отлично! Вот это и есть подход "зеленой факсовой кнопки".

VD>>5. Кроме того хорошо бы сделать еще один солюшен который собирал бы компилятор и интеграцию и прогонял тесты. В случае успеха можно комитить изменения. Если автоматизировать еще и комит — это будет вообще супер.
GR>Это чуть позже — времени не хватило.

Как я понимаю встроенными задачами это не реализовать (если только вызвать внешние утилиты командной строки). Но вот это должно помочь. Можно залить бинарники этих тасков на сервер и пользоваться ими.

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

IT>Может какую другую переменную объявить? Типа NemerleBoot.
Я не совсем понимаю идею... Изначально я хотел добиться того, чтобы экспериментальная ветка смотрела на сборки компилятора из boot, а рабочая — на Program Files. Как этого добиться введением переменной NemerleBoot?

IT>Хорошо бы вообще разделить установленный на машине Nemerle стандартным образом с тем, с чем работают девелоперв. Тогда можно будет писать интеграцию на самой интеграции.
У нас мысли сходятся

... << RSDN@Home 1.2.0 alpha 4 rev. 1088>>

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

Сначала опишу, чего я хотел этим добиться.
1. Иметь две версии Nemerle на одной машине:
а. Стабильная версия, установленная последним официальным инсталлятором.
б. Девелоперская версия, собранная из исходников.
2. Избавиться от необходимости в процессе сборки копировать компилятор в Program Files и регистрировать его там. Это автоматом делает невозможным п. 1
3. Разрабатывать компилятор и интеграцию на чуть более ранней версии интеграции.

GR>>Сейчас я подправил проекты интеграции и шелла так, чтобы они ссылались на сборки из boot, а не на Program Files\Nemerle. ИМХО это правильней. Если я не прав — покритикуйте.
VD>Это не верное решение. В boot почти всегда находятся устаревшие версии компилятора. Он нужен исключительно для бутсрипинга. Изменяться boot должен только после успешного прохождения второй стадии компиляции (а по уму и тестов).
Сейчас так и делается. Последовательность сборки компилятора:
1. Первая фаза компиляции (исп. оригинальный boot)
2. В случае успеха п.1 копируем в boot то, что скомпилировалось
2.1 Вторая фаза — компилируем новой версией самого себя.
2.2 В случае ошибки восстанавливаем оригинальный boot.
То есть в результате сборки второй фазы boot будет уже изменен, и там лежит вполне рабочая версия компилятора.
Это то, как я понимал до сих пор процесс сборки. Но видимо в это справедливо только для тех, кому интересно просто нажать кнопку и получить работающую интеграцию. По-этому я прошу описать наиболее типичные варианты сборки для девелопера и для потребителя, т.к. удовлетворить нужно всех.

VD>Файлы в нем должны комититься как можно реже, так как это довольно большие бинарные файлы, к тому же ктитичные.
Для комита можно предусмотреть специальный таск, который в случае необходимости можно указать при сборке в командной строке явно:

msbuild NemerleAll.nproj /t:Stage2;Commit

VD>Кроме того очень важно производить прекомпиляцию сборок компилятора ngen-ом, так как это во много раз ускоряет загрузку компилятора.
Это можно делать сразу после Stage2 вот так:

msbuild NemerleAll.nproj /t:Stage2;RegProgramFiles

Для самых частых типов задач можно придумать что-нить покороче.

GR>>Еще я реализовал возможность зарегистрировать путь к Nemerle.MSBuild.targets в boot, но толку от этого мало, т.к. во всех шаблонах проектов есть такой код:

GR>>

GR>>    <PropertyGroup>
GR>>        <NoStdLib>true</NoStdLib>
GR>>        <Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
GR>>    </PropertyGroup>
GR>>

GR>>Единственный способ, который я нашел, заставить студию смотреть на boot — определить переменную окружения Nemerle=<путь к boot>. Если такой вариант устроит, то нужно будет в таск RegBoot добавить инструкцию, которая создает эту переменную в системе.

VD>Не надо работать из бута. Можно сделать тупое копирование файлов из бута в %ProgramFiles%\Nemerle, если это кому-то надо. Но надо понимать, что современные версии Интеграции могут попросту не собираться из бута.
В %ProgramFiles%\Nemerle очень хотелось бы иметь версию, установленную инсталлятором. Может рассмотреть вариант — копировать все это в некий \work, и там обрабатывать ngen-ом. work в SVN класть будет совсем не обязательно.

VD>Ну, а задать Nemerle можно и через командную строку при запуске MSBuild-а через ключ /property:<n>=<v> или /p:<n>=<v>:
VD>

MSBuild.exe /property:Nemerle=D:\MyProjects\Nemerle\nemerle\trunk

Или определить эту переменную в NemerleAll.nproj...

... << RSDN@Home 1.2.0 alpha 4 rev. 1088>>

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

VD>Посмотрел исходники... Данные вопросы снимаются. Остается только вопрос не лучше ли использовать сторонние задачи (http://www.rsdn.ru/forum/message/3007014.1.aspx) вместо exe-шников?

На выходных попробую, но сразу могу сказать, что NGen таска там нет. Смотрел еще вот эти таски http://www.codeplex.com/sdctasks, но там тоже нет.
К стати наткнулся на редактор msbuild скриптов http://www.attrice.info/downloads/index.htm — может кому пригодится.

... << RSDN@Home 1.2.0 alpha 4 rev. 1088>>

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

VD>Насчет раскоментаривания <DocumentationFile>bin\Debug\Nemerle.XML</DocumentationFile> в дебаге — это приведет к еще большему замедлению процесса компиляции. Так что надо бы защитить описание этих тегов неким условием. Кому надо пусть опишут некое свойство и получат эти файлы (или наоборот, кому не надо опишут некое свойство и файлы документации генерироваться не будут.

Я хотел это сделать, но времени небыло. Реально эти xml нужны только при сборке инсталлятора, а значит предлагаемое свойство можно попытаться устанавливать автоматически в зависимости от таргетов.

... << RSDN@Home 1.2.0 alpha 4 rev. 1088>>

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

VD>Можно ли собирать компилятор и интеграцию в один проход? При работе над интеграцией частенько приходится менять компилятор. Так как это промежуточные сборки и комитить код сразу после этого не надо, то ждать второго похода слишком накладно. Плюс частенько в работе компилятор оказывается "разобранным" и собрать им себя становится невозможным, так что нельзя затирать boot.
В данной версии скриптов это не предусмотрено, но сделать можно. Но пред тем, как что-то делать хотелось бы договориться насчет копирования (а точнее не копирования) бинарников в Program Files. Как вариант рядом с boot можно разместить папку work, и туда класть результат превой фазу. Туда же копировать и targets, и там же все это регистрировать. При этом work в SVN класть не нужно — он всегда будет создаваться на первой фазе компиляции.

VD>А как регистрировать в %ProgramFiles%\Nemerle?
msbuild NemerleAll.nproj /t:RegProgramFiles

VD>При работе над интеграцией и компилятором самый частый сценарий это:
VD>1. Однопроходная сборка компилятора.
VD>2. Регистрация файлов компилятора в %ProgramFiles%\Nemerle.
VD>3. Сборка тестов.
VD>4. Сборка Интеграции.
Добро, реализую такой сценарий и сделаю его по умолчанию. Сборка будет до безобрази проста: msbuild NemerleAll.nproj

VD>Причем желательно чтобы все эти задачи выполнялись только при успешной сборке предыдущих пунктов (чтобы сборка прерывалась в случае сбоя).
VD>Как это сделать с помощью NemerleAll.nproj?

GR>>Реально вариантов больше, кому интересно — см. NemerleAll.nproj
VD>Будем поглядать...
Это поможет http://www.attrice.info/downloads/index.htm

VD>>>1. Солюшен сборки компилятора. Он должен компилировать компилятор и производить его регистрацию. Нужно сделать так чтобы можно было компилировать и без регистрации. Кроме того регистрация должна производиться как в %ProgramFiles%\Nemerle, так и в boot.
GR>>Готово.
GR>>3. msbuild NemerleAll.nproj /t:Stage2

VD>Э... нужно чтобы компиляция и регистрация могла бы производиться в оду стадию. Иначе резко замедлится работа над компилятором. Я выполняю сборку в две стадии исключительно когда подготавливаю файлы к комиту в SVN.
Не вопрос
msbuild NemerleAll.nproj /t:Stage2;RegProgramFiles
или
msbuild NemerleAll.nproj /t:Stage2;RegBoot

GR>>Готово, требует тестирования, т.к. реальную ситуацию с ошибкой я создать не смог, но если генерировать ошибку искуственно, то откат работает. В общем нужно тестировать.
VD>О. Это не проблема. Для этого ошибку надо посадить в макрос которые генерировал бы некорректный код.
На выходных попробую

VD>>>3. Третий солюшен должен собирать интеграцию.
GR>>4. msbuild NemerleAll.nproj /t:VSIntegration

VD>Здорово! А перед этим производится компиляция компилятора?
Да, Stage2, но насколько я понял, здесь нужна Stage1.
VD>Интеграция при этом компилируется уже новой версией компилятора?
Да, из boot, в котором уже новая версия компилятора
VD>Зачастую Интеграция может быть скомпилирована только новой версией компилятора, а портить boot нельзя, так как компилятор может и не собраться текущей своей версией (частая ситуация при работе над макросами из стандартной библиотеки).
А вот над этим нужно будет еще потрудиться, т.к. интеграция сейчас смотрит на boot, который затирается после Stage2 (см. предложение относительно work)

VD>>>4. Ну, и должен быть еще один солюшен который собирает три предыдущих солюшена (точнее проекты из них) и собирает инсталлятор.
GR>>2. msbuild NemerleAll.nproj /t:Installer
VD>Отлично! Вот это и есть подход "зеленой факсовой кнопки".

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

VD>>>5. Кроме того хорошо бы сделать еще один солюшен который собирал бы компилятор и интеграцию и прогонял тесты. В случае успеха можно комитить изменения. Если автоматизировать еще и комит — это будет вообще супер.
GR>>Это чуть позже — времени не хватило.

VD>Как я понимаю встроенными задачами это не реализовать (если только вызвать внешние утилиты командной строки). Но вот это должно помочь. Можно залить бинарники этих тасков на сервер и пользоваться ими.
Вот только как бы все это протестировать... На живом SVN, пожалуй, не хорошо. Нужно будет копию развернуть и в тестовом режиме туда комитить пока не заработает как положено.

... << RSDN@Home 1.2.0 alpha 4 rev. 1088>>

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

GR>Я не совсем понимаю идею... Изначально я хотел добиться того, чтобы экспериментальная ветка смотрела на сборки компилятора из boot, а рабочая — на Program Files. Как этого добиться введением переменной NemerleBoot?

В немерловом проекте студии указан путь к Nemerle как %Program Files%. Что, если его поменять на что-нибудь более подходящее? Может вообще можно указать прямые ссылки? А если всё засунуть в один солюшин?

IT>>Хорошо бы вообще разделить установленный на машине Nemerle стандартным образом с тем, с чем работают девелоперв. Тогда можно будет писать интеграцию на самой интеграции.
GR>У нас мысли сходятся

Как первый шаг на пути к этому я изменил все проекты (кроме самого компилятора) так, чтобы они смотрели на boot, но Влад такой ход раскритиковал — будем искать более удачное решение.

Насчёт бута он прав. Нужно, чтобы ссылка была на свежеоткомпилированную версию.

... << RSDN@Home 1.2.0 alpha rev. 771>>

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

GR>Сначала опишу, чего я хотел этим добиться.
GR>1. Иметь две версии Nemerle на одной машине:
GR> а. Стабильная версия, установленная последним официальным инсталлятором.
GR> б. Девелоперская версия, собранная из исходников.
GR>2. Избавиться от необходимости в процессе сборки копировать компилятор в Program Files и регистрировать его там. Это автоматом делает невозможным п. 1
GR>3. Разрабатывать компилятор и интеграцию на чуть более ранней версии интеграции.

Как всегда дорога в ад вымощена благими намерениями.

Намерение хорошее, но вот использовать для компиляции интеграции сборки из boot-а нельзя, так как интеграция разрабатывается в расчете на свежайший компилятор. Очень часто работая над Интеграцией приходится менять компилятор. И именно по этому так же нужно иметь возможность собирать компилятор в один проход (без двух стадий).

Интеграция же из под интеграции и так запускается. Проблема только в самокомпиляции. Для ее решения нужно копировать сборки в разные места. Но бут использовать нельзя.

Переменную Nemerle можно задать:
1. Через параметр — /p:Nemerle=... в MSBuild.
2. Через установку переменной среды окружения — set Nemerle=....
3. Изнутри проекта задавая свойства проекта — <Nemerle>...</Nemerle>. При этом можно использовать условия.

Но есть одна глобальная проблема. Сборки для целей интеллисенса и сборки для самой игтерации грузятся в один домен приложений. А вот в один домен нельзя загрузить (без ужасных последствий) оду и ту же сборку разных версий. Так что боюсь, что попытка обречена на неудачу.

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

GR>Сейчас так и делается. Последовательность сборки компилятора:
GR>1. Первая фаза компиляции (исп. оригинальный boot)
GR>2. В случае успеха п.1 копируем в boot то, что скомпилировалось
GR> 2.1 Вторая фаза — компилируем новой версией самого себя.
GR> 2.2 В случае ошибки восстанавливаем оригинальный boot.
GR>То есть в результате сборки второй фазы boot будет уже изменен, и там лежит вполне рабочая версия компилятора.
GR>Это то, как я понимал до сих пор процесс сборки. Но видимо в это справедливо только для тех, кому интересно просто нажать кнопку и получить работающую интеграцию. По-этому я прошу описать наиболее типичные варианты сборки для девелопера и для потребителя, т.к. удовлетворить нужно всех.

Двухфазная компиляция в два раза более медленная. По этому при работе над компилятором в основном используется однофазная компиляция. При этом копировать результат в boot нельзя, так как этой версией уже можно не скомпилировать компилятор.

VD>>Файлы в нем должны комититься как можно реже, так как это довольно большие бинарные файлы, к тому же ктитичные.
GR>Для комита можно предусмотреть специальный таск, который в случае необходимости можно указать при сборке в командной строке явно:
GR>

msbuild NemerleAll.nproj /t:Stage2;Commit

Еще раз... медленно. Комитить бинарники надо КАК МОЖНО РЕЖЕ. Они банально большие. Копирование же файлов в boot приводит к тому, что их можно закомитить по неволе.

Учитывая вышесказанное мы должны иметь полноценный вариант одностадийной компиляции. В нем ничего не должно копироваться в boot, а интеграция должна собираться новыми файлами (не из бута).

VD>>Кроме того очень важно производить прекомпиляцию сборок компилятора ngen-ом, так как это во много раз ускоряет загрузку компилятора.
GR>Это можно делать сразу после Stage2 вот так:
GR>

msbuild NemerleAll.nproj /t:Stage2;RegProgramFiles

При одностадийной компиляции регистрация тоже необходима.

GR>Для самых частых типов задач можно придумать что-нить покороче.

Да, корочен не надо. Часто используемые варианты можно тупо вынести в батники. Главное, чтобы они были простыми как три копйки, а не как сейчас.

GR>>>Еще я реализовал возможность зарегистрировать путь к Nemerle.MSBuild.targets в boot, но толку от этого мало, т.к. во всех шаблонах проектов есть такой код:

GR>>>

GR>>>    <PropertyGroup>
GR>>>        <NoStdLib>true</NoStdLib>
GR>>>        <Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
GR>>>    </PropertyGroup>
GR>>>

GR>>>Единственный способ, который я нашел, заставить студию смотреть на boot — определить переменную окружения Nemerle=<путь к boot>. Если такой вариант устроит, то нужно будет в таск RegBoot добавить инструкцию, которая создает эту переменную в системе.

MSBuild-проекту можно передать это дело задав свойство. На то этот Condition и был введен. Сложнее будет с компиляцией из под VS.

Однако не думаю, что разделение сборок по каталогам поможет писать интеграцию из под старой игтеграции. Как я уже говорил проблема в несовместимости сборок.

VD>>Не надо работать из бута. Можно сделать тупое копирование файлов из бута в %ProgramFiles%\Nemerle, если это кому-то надо. Но надо понимать, что современные версии Интеграции могут попросту не собираться из бута.
GR>В %ProgramFiles%\Nemerle очень хотелось бы иметь версию, установленную инсталлятором. Может рассмотреть вариант — копировать все это в некий \work, и там обрабатывать ngen-ом. work в SVN класть будет совсем не обязательно.

Можешь попробовать, но боюсь, что ничего не выйдет. Точнее можно будет запускать Интеграцию собранную из исходников и Интеграцию из %ProgramFiles%\Nemerle, но, боюсь, что использовать инсталлированную для работы над текущей не выйдет.

GR>Или определить эту переменную в NemerleAll.nproj...

Наверно. Незнаю "наследуется" ли она или нет. Если — да, то проблем нет... ну акромя упомянутых мною выше.

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

GR>К стати наткнулся на редактор msbuild скриптов http://www.attrice.info/downloads/index.htm — может кому пригодится.

К сожалению:

The installation package includes MSBuild Sidekick v2 application 14-days trial

в прочем может 1.х тоже что-то дает.

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

GR>Я хотел это сделать, но времени небыло. Реально эти xml нужны только при сборке инсталлятора, а значит предлагаемое свойство можно попытаться устанавливать автоматически в зависимости от таргетов.

В зависимости от конфигурации. Так оно и было. Если ты не обратил внимание, комментированные варианты были в Debug-конфигурации.

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

GR>В данной версии скриптов это не предусмотрено, но сделать можно. Но пред тем, как что-то делать хотелось бы договориться насчет копирования (а точнее не копирования) бинарников в Program Files.

Это пожалуйста, но нужно сделать вариант с копированием и регистрацией в %ProgramFiles%\Nemerle.

GR>Как вариант рядом с boot можно разместить папку work, и туда класть результат превой фазу. Туда же копировать и targets, и там же все это регистрировать. При этом work в SVN класть не нужно — он всегда будет создаваться на первой фазе компиляции.

Папки лучше называть Stage1, Stage2 и Stage3.

VD>>А как регистрировать в %ProgramFiles%\Nemerle?
GR>msbuild NemerleAll.nproj /t:RegProgramFiles

А при этом проект скомпилируется если он устарел?

VD>>При работе над интеграцией и компилятором самый частый сценарий это:
VD>>1. Однопроходная сборка компилятора.
VD>>2. Регистрация файлов компилятора в %ProgramFiles%\Nemerle.
VD>>3. Сборка тестов.
VD>>4. Сборка Интеграции.
GR>Добро, реализую такой сценарий и сделаю его по умолчанию. Сборка будет до безобрази проста: msbuild NemerleAll.nproj

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

VD>>Э... нужно чтобы компиляция и регистрация могла бы производиться в оду стадию. Иначе резко замедлится работа над компилятором. Я выполняю сборку в две стадии исключительно когда подготавливаю файлы к комиту в SVN.
GR>Не вопрос
GR>msbuild NemerleAll.nproj /t:Stage2;RegProgramFiles
GR>или
GR>msbuild NemerleAll.nproj /t:Stage2;RegBoot

А при этом регистрация произойдет если обломалась компиляция?

VD>>>>3. Третий солюшен должен собирать интеграцию.
GR>>>4. msbuild NemerleAll.nproj /t:VSIntegration

VD>>Здорово! А перед этим производится компиляция компилятора?
GR>Да, Stage2, но насколько я понял, здесь нужна Stage1.

Ага.

VD>>Отлично! Вот это и есть подход "зеленой факсовой кнопки".

GR>Это значительно приятней, чем когда только посвященные могут собрать инсталлятор

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

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

VD>>Как я понимаю встроенными задачами это не реализовать (если только вызвать внешние утилиты командной строки). Но вот это должно помочь. Можно залить бинарники этих тасков на сервер и пользоваться ими.
GR>Вот только как бы все это протестировать... На живом SVN, пожалуй, не хорошо. Нужно будет копию развернуть и в тестовом режиме туда комитить пока не заработает как положено.

Да пожалуй автоматический комит — это перебор. А вот забирать новые версии было бы очень даже удобно. И тестировать просто. К тому же SVN хорош тем, что всегда можно откатить ревизию.

... << RSDN@Home 1.2.0 alpha rev. 771>>

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

VD>Но есть одна глобальная проблема. Сборки для целей интеллисенса и сборки для самой игтерации грузятся в один домен приложений. А вот в один домен нельзя загрузить (без ужасных последствий) оду и ту же сборку разных версий. Так что боюсь, что попытка обречена на неудачу.

Проблема видимо из-за того, что номера варсий различаются лишь в билде. Может быть сборкам компилятора для интеграции давать какую-нибудь версию типа 10.*? Тогда они точно должны в одном домене работать.

... << RSDN@Home 1.2.0 alpha rev. 771>>

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

Что-то типа пробы сил.

Попытаюсь агрегировать обсуждения из соседних подветок.
Основные хотелки:

CompilerFull

CompilerFast

VsMedium

VsFast

Installer

CompilerFull

RegStage1

7. Установка Nemerle в Program Files инсталлятором

8. Мирное существование двух веток одновременно

9. Сборка всех проектов идет полностью в рамках каталога $(NemerleRoot)
Относительно фаз компиляции предлагаю поступить так: создаем каталог Stages, под нам три каталога — 1, 2, 3 (каталог = номер фазы). При первом проходе устанавливаем переменную Nemerle=$(NemerleRoot)\Sages\1, при втором — Nemerle=$(NemerleRoot)\Sages\2, и т.д. Вместо Program Files\Nemerle предлагаю использовать $(NemerleRoot)\Sages\1

Давайте проанализируем все эти хотелки, удалим лишние и добавим недостающее, пока без деталей реализации, если их отсутствие не вызывает неясности. После того, как список хотелок зафиксируем, обсудим детали, если потребуется.

З.Ы. $(NemerleRoot) — каталог, где лежит http://nemerle.org/svn/nemerle/trunk

... << RSDN@Home 1.2.0 alpha 4 rev. 1096>>

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

IT>Проблема видимо из-за того, что номера варсий различаются лишь в билде. Может быть сборкам компилятора для интеграции давать какую-нибудь версию типа 10.*? Тогда они точно должны в одном домене работать.

Попробуй.

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

GR>Основные хотелки:
GR>

CompilerFull

GR> Stage1, используя boot. Обработка NGen-ом

GR> Stage2, используя Stage1

GR> Stage3, используя Stage2

GR> Побайтное сравнение Stage2 и Stage3

GR> Только после этого копировать Stage3 в boot (при этом BackupBoot и RestoreBoot не нужны)

Желательно преде копированием Stage3 в boot прогонять тесты и производить копирование только при условии, что все тесты прошли.

GR>

CompilerFast

GR> а. Stage1, используя boot. Обработка NGen-ом

GR>

VsMedium

GR> а. Stage1, используя boot. Обработка NGen-ом

GR> б. VSIntegration, используя Stage1

GR>

VsFast

GR> а. VSIntegration, используя Stage1

Работа из разных мест может привести к ненужным, и что самое главное, непонятным проблемам.
Так что лучше при удачной сборке копировать файлы из StageХ в некий каталог вроде DevBin. И уже там производить обработку NGen-ом и прочую регистрацию (если надо).

GR>

8. Мирное существование двух веток одновременно
Боюсь, что без изменения версий сборок это будет невозможно, так как дотнет не даст загрузить две сборки одной версии без глюков и проблем. Так что этот вопрос остается открытым. Конечно было бы хорошо если бы это удалось бы сделать, но не факт, что это будет так просто. Дело далеко не только в общих директориях.

GR>

9. Сборка всех проектов идет полностью в рамках каталога $(NemerleRoot)
GR>Относительно фаз компиляции предлагаю поступить так: создаем каталог Stages, под нам три каталога — 1, 2, 3 (каталог = номер фазы).

Называть каталоги "1", "2" и "3" — это плохая идея. Будет много много где данное название будет сбивать с толку. Пусть уж лучше каталоги называются NStageX где Х — это порядковый номер. Тогда по одному названию будет ясно о чем идет речь. Кроме того корневой каталог для сборки лучше (традиционно) назвать bin. Каталоги же NStageX пусть размещаются в нем. Кроме того в нево же имеет смысл засунуть каталог DevBin (в который копировать "рабочие" версии сборок для использования разработчиками.

GR>При первом проходе устанавливаем переменную Nemerle=$(NemerleRoot)\Sages\1, при втором — Nemerle=$(NemerleRoot)\Sages\2, и т.д. Вместо Program Files\Nemerle предлагаю использовать $(NemerleRoot)\Sages\1

Вместо %%ProgramFiles%%\Nemerle нужно использовать $(NemerleRoot)\bin\DevBin. Это позволит избежать многих странных ошибок уши которых растут из того, что используются не те бинарники (не из того каталога).

GR>Давайте проанализируем все эти хотелки, удалим лишние и добавим недостающее, пока без деталей реализации, если их отсутствие не вызывает неясности. После того, как список хотелок зафиксируем, обсудим детали, если потребуется.

GR>З.Ы. $(NemerleRoot) — каталог, где лежит http://nemerle.org/svn/nemerle/trunk

Это понятно. В общем, и целом план хороший. Но учти высказанные выше замечания.

	От:	gloomy rocker
	Дата:	26.06.08 17:04
	Оценка:	51 (3) +2

От:	VladD2	www.nemerle.org
Дата:	26.06.08 14:01
Оценка:	15 (2) +1

От:	IT	linq2db.com
Дата:	26.06.08 17:51
Оценка:	15 (2) +1

	От:	gloomy rocker
	Дата:	29.06.08 20:00
	Оценка:	116 (2)

	От:	Аноним
	Дата:	26.06.08 18:11
	Оценка:

	От:	Блудов Павел
	Дата:	30.06.08 01:02
	Оценка: