Re[2]: BuildInstallerRelease.cmd
От: _nn_ www.nemerleweb.com
Дата: 10.03.10 08:56
Оценка: 9 (1) +1
Здравствуйте, kochetkov.vladimir, Вы писали:

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


KV>не против, если я заменю BuildInstallerRelease.cmd и BuildInstallerFull.cmd на один

Только за

Батник можно немного улучшить

@echo off

rem Check perquisites
rem // Тут надо еще добавить проверку, что есть необходимые файлы, необходимые программы и т.п.
rem // Лучше сразу узнать что не хватает чем получить непонятные сообщения об ошибках.
rem // Проверка VS
rem // Проверка VS SDK
rem // Проверка NUnit
rem // Проверка Wix
rem // Проверка Reflector addon
rem И т.д.

if "%~1"=="" (
    set Type=Release    
) else (
    set Type=%1
)


set NoPause=true
set Nemerle=%~dp0\boot

rem Build MSBuild task
call Build-MSBuildTask.cmd

rem Copy MSBuild targets to boot
copy "tools\msbuild-task\Nemerle.MSBuild.targets" /b "boot\"

rem Actualize revision number
misc\packages\wix\tools\SubWCRev.exe .\ misc\packages\wix\src\Version.wxi.template misc\packages\wix\src\Version.wxi

rem Build Installer
set MSBuild="%SystemRoot%\Microsoft.NET\Framework\v3.5\msbuild.exe"
%MSBuild% NemerleAll.nproj /t:InstallerFull /p:Configuration=%Type%

rem Done
set Type=
set NoPause=
set Nemerle=
del misc\packages\wix\src\Version.wxi


Обновление версии это хорошо

P.S.
Жаль нет [batch]
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[3]: BuildInstallerRelease.cmd
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 10.03.10 09:08
Оценка: :)
Здравствуйте, _nn_, Вы писали:

__>Здравствуйте, kochetkov.vladimir, Вы писали:


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


KV>>не против, если я заменю BuildInstallerRelease.cmd и BuildInstallerFull.cmd на один

__>Только за

Ок, добавлю проверки prereq и залью в проект

__>Батник можно немного улучшить


__>
__>if "%~1"=="" (
__>    set Type=Release    
__>) else (
__>    set Type=%1
__>)
__>
__>


А так хотелось хоть куда-нибудь впихнуть goto... (http://www.rsdn.ru/Forum/Info/FAQ.HUMOR.gotomustdie.aspx
Автор: IT
Дата: 08.06.02
)
... << RSDN@Home 1.2.0 alpha 4 rev. 1437>>

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[3]: BuildInstallerRelease.cmd
От: gloomy rocker Россия  
Дата: 10.03.10 09:18
Оценка:
Здравствуйте, gloomy rocker, Вы писали:

GR>Сейчас у меня компиляция идет в 4 стадии и результат каждой стадии компиляции лежит отдельно в папке bin\$(Configuration)\$(Stage)

GR>Stage1 компилируется компилятором из boot
GR>Stage2 — компилятором из bin\$(Configuration)\Stage1
GR>и т.д.
С четырьмя стадиями сборки обнаружилась проблема. Дело все в том, что вся сборка идет в одном AppDomain-е. Происходит следующее:
1. При сборке Stage1 из boot загружается Nemerle.MSBuild.Tasks.dll версии, допустим, 1.1.1.1
2. Результат компиляции помещается в папку bin\$(Configuration)\Stage1
3. При компиляции Stage2 из bin\$(Configuration)\Stage1 загружается Nemerle.MSBuild.Tasks.dll версии, допустим, 2.2.2.2
4. Поскольку версии в данном случае разные, то пока все хорошо и Stage2 собирается компилятором из Stage1
5. При компиляции Stage3 MSBuild пытается загрузить Nemerle.MSBuild.Tasks.dll из bin\$(Configuration)\Stage2
6. Поскольку версии сборок в bin\$(Configuration)\Stage1 и bin\$(Configuration)\Stage2 совпадают, то MSBuild продолжает использовать ранее загруженную из bin\$(Configuration)\Stage1 сборку.
7. Задача Ncc, которая в этой сборке находится использует ncc.exe, который лежит в той же папке, где и Nemerle.MSBuild.Tasks.dll

В результате получается, что Stage1 компилируется компилятором из boot, а Stage2-4 — из компилятором bin\$(Configuration)\Stage1

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

GR>что одна и та же цель собирается с разными параметрами.
В свете описанной проблемы это утверждение временно утратило силу.

Варианты решения:
1. Вместо задачи MSBuild использовать Exec, но тогда теряется цветной вывод на консоль.
2. Спекулятивное присвоение версии сборкам разных стадий
3. Копирование boot в промежуточную папку, а потом копировать туда результат каждой стадии, за исключением Nemerle.MSBuild.Tasks.dll
4. Предложите свой вариант.
Скука — двигатель прогресса.
Re[4]: BuildInstallerRelease.cmd
От: gloomy rocker Россия  
Дата: 10.03.10 09:37
Оценка: +1
Здравствуйте, _nn_, Вы писали:

GR>>Не все так просто, как может показаться на первый взгляд.

GR>>Некоторые проекты в исходниках Nemerle компилируются только если в $(ProgramFiles)\Nemerle лежат сборки компилятора.
GR>>Так ведет себя, например проект Linq.nproj. Кроме того в NemerleAll.nproj, при сборке цели NccFull или NccFast (а они предшествуют сборке интеграции и инсталлятора) идет копирование всего необходимого в $(ProgramFiles)\Nemerle.
GR>>От $(ProgramFiles)\Nemerle при сборке инсталлятора или компилятора по хорошему вообще нужно избавиться.

__>У меня при установке set Nemerle=NemerleProjectPath\boot ничего не копируется в $(ProgramFiles).

__>Собирал через BuildInstallerRelease.cmd .
Я имел виду, что внутренности NemerleAll.nproj устроены так, что в $(ProgramFiles) компилятор все же копируется.
Там есть такая цель, называется RegProgFiles. Кроме того boot лучше лишний раз не трогать. По хорошему его можно
перезаписать только после четвертой стадии и всех возможных тестов и валидаций.

__>Все должно работать нормально.

Да, если задать переменную $(Nemerle).

__>Только если $(Nemerle) не установлен берется $(ProgramFiles).

__>А вообще конечно хорошо убрать $(ProgramFiles) как директорию по умолчанию.
__>Может проще требовать, чтобы переменная Nemerle была установлена или там NRoot или другая ?
Я думаю, что скрипт NemerleAll.nproj нужно доделать таким образом, чтобы можно было на каждой стадии задавать, где взять boot-компилятор, и куда положить новый компилятор. Это делается путем задания двух свойств: Nemerle и OutDir.
А установку в ProgramFiles, регистрацию в GAC, NGen и т.д. нужно делать отдельной целью.
Скука — двигатель прогресса.
Re[4]: BuildInstallerRelease.cmd
От: _nn_ www.nemerleweb.com
Дата: 10.03.10 09:46
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Ок, добавлю проверки prereq и залью в проект


Я вот как-то подумал, может стоит добавить wget.exe (Ну или VBScript + WinHTTP, или что-то другое чтобы под линуксом собрать можно было ) в проект и если не найдена нужная программа, то ее можно предложить скачать и установить.
Это я про VS SDK, Wix, NUnit, Reflector.

Для небольших файлов можно, наверное, добавить сам msi в проект и запускать его если не установлен.
А для больших файлов, или с которыми может быть проблема с лицензией, предлагать скачать.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[4]: BuildInstallerRelease.cmd
От: gloomy rocker Россия  
Дата: 10.03.10 10:35
Оценка:
Здравствуйте, gloomy rocker, Вы писали:

GR>Варианты решения:

GR>1. Вместо задачи MSBuild использовать Exec, но тогда теряется цветной вывод на консоль.
ИМХО это пока наиболее простой и наименее кривой вариант.

GR>2. Спекулятивное присвоение версии сборкам разных стадий

GR>3. Копирование boot в промежуточную папку, а потом копировать туда результат каждой стадии, за исключением Nemerle.MSBuild.Tasks.dll
Этот вариант проверил — не работает. Nemerle.MSBuild.Tasks.dll зависит от Nemerle.dll, которая блокируется процессом MSBuild.
Чтобы такой вариант заработал нужно будет переписать Nemerle.MSBuild.Tasks.dll так, чтобы он не зависел от Nemerle.dll.

GR>4. Предложите свой вариант.


Можно еще посмотреть в сторону AppDomainIsolatedTask, но переусложнять тоже не хочется.
Скука — двигатель прогресса.
Re[3]: BuildInstallerRelease.cmd
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 15:57
Оценка:
Здравствуйте, gloomy rocker, Вы писали:

GR>Не все так просто, как может показаться на первый взгляд.

GR>Некоторые проекты в исходниках Nemerle компилируются только если в $(ProgramFiles)\Nemerle лежат сборки компилятора.
GR>Так ведет себя, например проект Linq.nproj.

Это не совсем так. Linq.nproj — это стандартный проект интеграции и то где лежат бинарники определяется (в нем) переменной среды окружения "Nemerle". Если она не задана, то в нее подставляется путь "$(ProgramFiles)\Nemerle". Если задана, то используется заданный путь. Вот начала этого проекта:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <NoStdLib>true</NoStdLib>
    <Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
    <Name>Linq</Name>
    <TargetPlatform>v2</TargetPlatform>
  </PropertyGroup>


Так что перед компиляцией этого проекта достаточно задать путь к бинарникам в переменную "Nemerle" и он будет использовать именно их.

GR> Кроме того в NemerleAll.nproj, при сборке цели NccFull или NccFast (а они предшествуют сборке интеграции и инсталлятора) идет копирование всего необходимого в $(ProgramFiles)\Nemerle.

GR>От $(ProgramFiles)\Nemerle при сборке инсталлятора или компилятора по хорошему вообще нужно избавиться.

Согласен.

GR>У меня на работе назрела необходимость перейти на одну из последних версий Nemerle, и пришлось взяться за старое и повозиться со сборкой.

GR>Выяснился такой нюанс. В $(Nemerle)\tools\msbuild-task есть два интересных файла: Compiler.MSBuild.targets и Nemerle.MSBuild.targets. Основное их отличие состоит в том, что Compiler.MSBuild.targets предполагает, что компилер находится в boot-е, а Nemerle.MSBuild.targets — ищет компилер там, куда указывает переменная $(Nemerle). В связи с этим у мня появилась идея, что Compiler.MSBuild.targets есть частный случай Nemerle.MSBuild.targets.

Да, так и есть. Копи-пас там по недоразумению.

GR>Я попробовал изменить файлы проектов ncc.nproj, nemerle.nproj и т.д. следующим образм:

GR>...Измененный ncc.nproj
GR>
GR>    <Nemerle Condition=" '$(Nemerle)' == '' ">$(MSBuildProjectDirectory)\boot</Nemerle>
GR>


Думаю, что условие (Condition=" '$(Nemerle)' == '' ") тут лишнее.
Может получиться так, что кто-то задаст переменную "Nemerle" в Windows. Это приведет к тому, что компилятор начнет собираться черт знает какими бинарниками. А он обязан собираться только бинарниками из boot-а или скомпилированными из них.

GR>В результате, как я и ожидал, все прекрасно скомпилировалось, но пришлось докручивать NemerleAll.nproj


Отлично!

GR>Теперь немного о том, чего хочется от NemerleAll.nproj и что я уже сделал.

GR>Сейчас у меня компиляция идет в 4 стадии и результат каждой стадии компиляции лежит отдельно в папке bin\$(Configuration)\$(Stage)
GR>Stage1 компилируется компилятором из boot
GR>Stage2 — компилятором из bin\$(Configuration)\Stage1
GR>и т.д.

А полученный инсталлятор не глючит? А то мы тут пытаемся на сервере процесс компиляции запустить и в результате получаются битые инсталляторы. При попытке создать проект выдается сообщение что languageService == null.

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


Этого не понял, ну да ладно.

GR>Собственно на этом я пока остановился. Думаю денек-другой, и смогу довести этот MSBuild-ный скрипт до ума так, чтобы не использовать $(ProgramFiles).

GR>Но для того нужна отмашка старших разработчиков. Может я не до конца понимаю смысл наличия двух разных targets файлов.

С таргетами ты совершенно прав.

Так что заливай изменения. В крайнем случае, будем разбираться по месту.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: BuildInstallerRelease.cmd
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 16:18
Оценка:
Здравствуйте, gloomy rocker, Вы писали:

GR>Забыл написать, что Nemerle.MSBuild.targets приходится перед началом очередной фазы компиляции копировать в папку, на которую указывает переменная $(Nemerle). В том числе и в boot.


Мы уже пользуемся услугами утилиты junction.exe. Наверно, имеет смысл вместо копирования создавать с ее помощью ссылки на файлы.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: BuildInstallerRelease.cmd
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 16:21
Оценка:
Здравствуйте, _nn_, Вы писали:

__>Только если $(Nemerle) не установлен берется $(ProgramFiles).

__>А вообще конечно хорошо убрать $(ProgramFiles) как директорию по умолчанию.
__>Может проще требовать, чтобы переменная Nemerle была установлена или там NRoot или другая ?

Вот этого не надо. Явно заданная переменная на машине будет приводить к проблемам. Ее должен задавать исключительно инсталлятор и только при условии, что местоположение компилятора не совпадает с "$(ProgramFiles)\Nemerle".
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: BuildInstallerRelease.cmd
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 16:23
Оценка:
Здравствуйте, gloomy rocker, Вы писали:

GR>Я думаю, что скрипт NemerleAll.nproj нужно доделать таким образом, чтобы можно было на каждой стадии задавать, где взять boot-компилятор, и куда положить новый компилятор. Это делается путем задания двух свойств: Nemerle и OutDir.


+1

GR>А установку в ProgramFiles, регистрацию в GAC, NGen и т.д. нужно делать отдельной целью.


А вот в GAC лучше не надо. Только если совсем отдельной целью которая по умолчанию не будет вызваться.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: BuildInstallerRelease.cmd
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 16:30
Оценка: 1 (1)
Здравствуйте, _nn_, Вы писали:

__>
__>set Nemerle=%~dp0\boot
__>


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

Переменную Nemerle нужно задавать только после того как будут скомпилированы сборки компилятора и на ту директорию в которую они будут помещены в процессе компиляции.
Соответственно это нужно делать из проекта, а не из батника.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: BuildInstallerRelease.cmd
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 17:02
Оценка:
Здравствуйте, gloomy rocker, Вы писали:

GR>5. При компиляции Stage3 MSBuild пытается загрузить Nemerle.MSBuild.Tasks.dll из bin\$(Configuration)\Stage2

GR>6. Поскольку версии сборок в bin\$(Configuration)\Stage1 и bin\$(Configuration)\Stage2 совпадают, то MSBuild продолжает использовать ранее загруженную из bin\$(Configuration)\Stage1 сборку.

Хм. Фигово.

Пути решения проблемы видятся следующие:
1. Использовать не задачу MSBuild, а задачу Exec в которой уже вызвать MSBuild.exe. Тогда он будет в отдельном процессе и проблема должна исчезнуть.
2. Подправить Nemerle.MSBuild.Tasks.dll так чтобы она могла получать путь к NCC.exe в качестве одного из свойств.
3. К едрене фене переписать Nemerle.MSBuild.Tasks.dll на C#, чтобы он больше не доставал. Он уже давно проблемы создает.

GR>7. Задача Ncc, которая в этой сборке находится использует ncc.exe, который лежит в той же папке, где и


GR>Варианты решения:

GR>1. Вместо задачи MSBuild использовать Exec, но тогда теряется цветной вывод на консоль.
GR>2. Спекулятивное присвоение версии сборкам разных стадий
GR>3. Копирование boot в промежуточную папку, а потом копировать туда результат каждой стадии, за исключением Nemerle.MSBuild.Tasks.dll

Ой. Вот что значит отвечать не дочитав до конца .

Мне кажется, все, кроме первого, предложенные тобой варианты имеют свои изъяны. Так копирование может привести к блокированию файлов во время сборки. От этого мы ведь и пытаемся уйти.

GR>4. Предложите свой вариант.


Мои я уже предложил выше. Самым простым видится добавление параметра (свойства) в Nemerle.MSBuild.Tasks.dll который будет указывать ему где брать компилятор.

А вообще, изначально нужно было писать Nemerle.MSBuild.Tasks.dll на шарпе. Тогда всех этих проблем с зависимостями попросту не было бы.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: BuildInstallerRelease.cmd
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 17:19
Оценка:
Здравствуйте, gloomy rocker, Вы писали:

GR>Чтобы такой вариант заработал нужно будет переписать Nemerle.MSBuild.Tasks.dll так, чтобы он не зависел от Nemerle.dll.


Это уже делали, но видимо снова что-то напортачили.

GR>>4. Предложите свой вариант.


GR>Можно еще посмотреть в сторону AppDomainIsolatedTask, но переусложнять тоже не хочется.


Согласен.

Мне кажется разумных выхода только три:
1. Переписать Nemerle.MSBuild.Tasks.dll на шарпе. Логика там примитивная.
2. Добавить в Nemerle.MSBuild.Tasks.dll параметр говорящий откуда брать ncc.exe. Тут так же могут быть проблемы с блокировками.
3. Вызвать вложенные MSBuild-ы через Exec.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: BuildInstallerRelease.cmd
От: gloomy rocker Россия  
Дата: 10.03.10 21:36
Оценка:
Здравствуйте, VladD2, Вы писали:

GR>>Я попробовал изменить файлы проектов ncc.nproj, nemerle.nproj и т.д. следующим образм:

GR>>...Измененный ncc.nproj
GR>>
GR>>    <Nemerle Condition=" '$(Nemerle)' == '' ">$(MSBuildProjectDirectory)\boot</Nemerle>
GR>>


VD>Думаю, что условие (Condition=" '$(Nemerle)' == '' ") тут лишнее.

VD>Может получиться так, что кто-то задаст переменную "Nemerle" в Windows. Это приведет к тому, что компилятор начнет собираться черт знает какими бинарниками. А он обязан собираться только бинарниками из boot-а или скомпилированными из них.
А не затрется ли в таком случае значение переменной $(Nemerle), переданное извне? У меня сильное предчувствие, что затрется, и невозможно будет указать, каким компилятором собирать проект.

GR>>В результате, как я и ожидал, все прекрасно скомпилировалось, но пришлось докручивать NemerleAll.nproj


VD>Отлично!

Я имел в виду, что собрался компилятор. Дальше я пока не продвинулся.

GR>>Теперь немного о том, чего хочется от NemerleAll.nproj и что я уже сделал.

GR>>Сейчас у меня компиляция идет в 4 стадии и результат каждой стадии компиляции лежит отдельно в папке bin\$(Configuration)\$(Stage)
GR>>Stage1 компилируется компилятором из boot
GR>>Stage2 — компилятором из bin\$(Configuration)\Stage1
GR>>и т.д.

VD>А полученный инсталлятор не глючит? А то мы тут пытаемся на сервере процесс компиляции запустить и в результате получаются битые инсталляторы. При попытке создать проект выдается сообщение что languageService == null.

До инсталлятора пока дело не дошло. См. выше.

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


VD>Этого не понял, ну да ладно.

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

GR>>Собственно на этом я пока остановился. Думаю денек-другой, и смогу довести этот MSBuild-ный скрипт до ума так, чтобы не использовать $(ProgramFiles).

GR>>Но для того нужна отмашка старших разработчиков. Может я не до конца понимаю смысл наличия двух разных targets файлов.

VD>С таргетами ты совершенно прав.

Ок

VD>Так что заливай изменения. В крайнем случае, будем разбираться по месту.

Для этого нужен доступ к SVN. Мой gmail: gordynych@gmail.com
Скука — двигатель прогресса.
Re[5]: BuildInstallerRelease.cmd
От: gloomy rocker Россия  
Дата: 10.03.10 21:46
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Пути решения проблемы видятся следующие:

VD>1. Использовать не задачу MSBuild, а задачу Exec в которой уже вызвать MSBuild.exe. Тогда он будет в отдельном процессе и проблема должна исчезнуть.
VD>2. Подправить Nemerle.MSBuild.Tasks.dll так чтобы она могла получать путь к NCC.exe в качестве одного из свойств.
VD>3. К едрене фене переписать Nemerle.MSBuild.Tasks.dll на C#, чтобы он больше не доставал. Он уже давно проблемы создает.
Если нет возражений, я остановлюсь на первом варианте. Минус будет только один — цели, предупреждения и ошибки не будут подсвечиваться соответствующими цветами.

GR>>1. Вместо задачи MSBuild использовать Exec, но тогда теряется цветной вывод на консоль.

VD>Мне кажется, все, кроме первого, предложенные тобой варианты имеют свои изъяны. Так копирование может привести к блокированию файлов во время сборки. От этого мы ведь и пытаемся уйти.
Мнения сходятся.

VD>А вообще, изначально нужно было писать Nemerle.MSBuild.Tasks.dll на шарпе. Тогда всех этих проблем с зависимостями попросту не было бы.

У меня, если честно, времени на это сейчас нет. Если найдутся энтузиасты и сделают это, я потом могу доработать скрипт.
Скука — двигатель прогресса.
Re[6]: BuildInstallerRelease.cmd
От: gloomy rocker Россия  
Дата: 10.03.10 21:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А вот в GAC лучше не надо. Только если совсем отдельной целью которая по умолчанию не будет вызваться.

GAC я по инерции упомянул. Сейчас в скрипте вроде и нет такой задачи.
Скука — двигатель прогресса.
Re[5]: BuildInstallerRelease.cmd
От: gloomy rocker Россия  
Дата: 10.03.10 21:51
Оценка:
Здравствуйте, VladD2, Вы писали:

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


GR>>Забыл написать, что Nemerle.MSBuild.targets приходится перед началом очередной фазы компиляции копировать в папку, на которую указывает переменная $(Nemerle). В том числе и в boot.


VD>Мы уже пользуемся услугами утилиты junction.exe. Наверно, имеет смысл вместо копирования создавать с ее помощью ссылки на файлы.

ИМХО разницы никакой. Но в принципе можно, когда скрипт будет отлажен и останется только причесать его.
Скука — двигатель прогресса.
Re[4]: BuildInstallerRelease.cmd
От: gloomy rocker Россия  
Дата: 11.03.10 00:41
Оценка: 136 (2)
Здравствуйте, VladD2, Вы писали:

VD>А полученный инсталлятор не глючит? А то мы тут пытаемся на сервере процесс компиляции запустить и в результате получаются битые инсталляторы. При попытке создать проект выдается сообщение что languageService == null.

Довел скрипт до состояния, когда можно скомпилировать инсталлятор. Полученный инсталлятор глючит.
Собирать сейчас можно двумя способами — быстро и очень медленно.
Быстрый способ — одна стадия компиляции компилятора, нет вылидации и тесты не запускаются
Очень медленный — 4 фазы компиляции компилятора, валидация сборок, запуск тестов

Инсталлятор проверил пока только в случае быстрой сборки.
Скука — двигатель прогресса.
Re[5]: BuildInstallerRelease.cmd
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.10 11:09
Оценка:
Здравствуйте, gloomy rocker, Вы писали:

GR>А не затрется ли в таком случае значение переменной $(Nemerle), переданное извне? У меня сильное предчувствие, что затрется, и невозможно будет указать, каким компилятором собирать проект.


Конечно затрется. Но, как я понимаю, только в рамках текущего проекта.
И в нем оно уже будет не интересно. Ведь ведется сборка конкретной конфигурации. Если кому-то оно нужно, то можно создать еще одно свойство, например NemerleOldValue и сохранить старое значение свойства в нем.

GR>Я имел в виду, что собрался компилятор. Дальше я пока не продвинулся.

GR>...До инсталлятора пока дело не дошло. См. выше.

Ясно. Жаль. Ну, да может все же дойдут.

Для инсталлятора Nemerle можно смело задавать нужное значение (кактлог).

GR>Раньше сборка компилятора запускалась в отдельном процессе с помощью задачи Exec. При этом вывод на консоль цветом не выделялся, как выделялся бы при использовании задачи MSBuild. MSBuild у меня раньше не получалось использовать, т.к. с одними и теми же параметрами его можно выполнить только один раз.


Понял, то есть цвет зависит от того используется ли задача MSBuild или Exec.
Ну, значит надо решать вопрос с Nemerle.MSBuild.Tasks.dll.

VD>>Так что заливай изменения. В крайнем случае, будем разбираться по месту.

GR>Для этого нужен доступ к SVN. Мой gmail: gordynych@gmail.com

Добавил.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: BuildInstallerRelease.cmd
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.10 11:11
Оценка:
Здравствуйте, gloomy rocker, Вы писали:

VD>>Пути решения проблемы видятся следующие:

VD>>1. Использовать не задачу MSBuild, а задачу Exec в которой уже вызвать MSBuild.exe. Тогда он будет в отдельном процессе и проблема должна исчезнуть.
VD>>2. Подправить Nemerle.MSBuild.Tasks.dll так чтобы она могла получать путь к NCC.exe в качестве одного из свойств.
VD>>3. К едрене фене переписать Nemerle.MSBuild.Tasks.dll на C#, чтобы он больше не доставал. Он уже давно проблемы создает.
GR>Если нет возражений, я остановлюсь на первом варианте. Минус будет только один — цели, предупреждения и ошибки не будут подсвечиваться соответствующими цветами.

Ну, вот как раз против бесцветия возражения есть. Привык я к цветам . Так что двай как для начала попробуем вариант 2. Там делов то на 5 минут.

VD>>А вообще, изначально нужно было писать Nemerle.MSBuild.Tasks.dll на шарпе. Тогда всех этих проблем с зависимостями попросту не было бы.

GR>У меня, если честно, времени на это сейчас нет. Если найдутся энтузиасты и сделают это, я потом могу доработать скрипт.

Ну, переписать все на шарпе действительно задача не на 5 минут, а вот добавить свойство в NCC-задачу можно очень быстро. Ща добавлю...
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.