Здравствуйте, Ziaw, Вы писали:
Z>Только при этом подключаемые сборки из папки лежащей внутри %Nemerle% должны попадать в референсы и макрореференсы тоже как $(Nemerle)\relative_to_nemerle_path. Сейчас туда попадает путь относительно проекта, что совсем не кошерно. А в макрореференсы у меня и руками не получилось запихать $(Nemerle)\Nemerle.Linq.dll
Реализовал в 8916.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Прекомпиляция сборок при компиляции Nemerle
Здравствуйте, Ziaw, Вы писали:
Z>Только при этом подключаемые сборки из папки лежащей внутри %Nemerle% должны попадать в референсы и макрореференсы тоже как $(Nemerle)\relative_to_nemerle_path. Сейчас туда попадает путь относительно проекта, что совсем не кошерно. А в макрореференсы у меня и руками не получилось запихать $(Nemerle)\Nemerle.Linq.dll
При сборке Nemerle и интеграции к студии есть одна мелкая, но неприятная проблема. Хотя в конце сборки производится прекомпиляция сборок ngen-ом, по каким-то причинам она не дает ожидаемого результата.
Это выражается в том, что после компиляции проектов с помощью NemerleAll.nproj (т.е. батников: DevBuildQuick.cmd, DevBuildQuickWithTests.cmd, DevBuildForCommit.cmd, DevBuild2StageWithTests.cmd или DevBuild2Stage.cmd), последующие компиляции исходников немерле протекают со значительной задержкой. Загрузка компилятора занимает 3-5 секунд.
Если после этого прогнать Reg-bins-2.cmd, который по идее делает в точности тоже самое, что и вышеприведенные батники, то прекомпиляция проходит и следующие компиляции исходников немерла проходят намного быстрее.
Я не понимаю в чем заключается проблема при использовании NemerleAll.nproj. По идее выполняются те же самые вызовы ngen.exe. Однако ускорения загрузки компилятора от этого не происходит.
Если у кого-то есть какие-то идеи, или кто-то может заняться устранением этой проблемы, то милости просим!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Всем привет.
VD>При сборке Nemerle и интеграции к студии есть одна мелкая, но неприятная проблема. Хотя в конце сборки производится прекомпиляция сборок ngen-ом, по каким-то причинам она не дает ожидаемого результата.
После установки *.msi Немерле на чистой машине в кеше GAC (и в списке сборок из Add Reference...) сборки Nemerle.dll, Nemerle.Compiler.dll не появляются.
Это та же проблема?
Re[2]: Прекомпиляция сборок при компиляции Nemerle
Здравствуйте, catbert, Вы писали:
C>После установки *.msi Немерле на чистой машине в кеше GAC (и в списке сборок из Add Reference...) сборки Nemerle.dll, Nemerle.Compiler.dll не появляются.
C>Это та же проблема?
Нет. Это вообще не проблема. Так и должно быть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Прекомпиляция сборок при компиляции Nemerle
Здравствуйте, VladD2, Вы писали:
VD>Нет. Это вообще не проблема. Так и должно быть.
Только при этом подключаемые сборки из папки лежащей внутри %Nemerle% должны попадать в референсы и макрореференсы тоже как $(Nemerle)\relative_to_nemerle_path. Сейчас туда попадает путь относительно проекта, что совсем не кошерно. А в макрореференсы у меня и руками не получилось запихать $(Nemerle)\Nemerle.Linq.dll
Re[4]: Прекомпиляция сборок при компиляции Nemerle
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, VladD2, Вы писали:
VD>>Нет. Это вообще не проблема. Так и должно быть.
Z>Только при этом подключаемые сборки из папки лежащей внутри %Nemerle% должны попадать в референсы и макрореференсы тоже как $(Nemerle)\relative_to_nemerle_path. Сейчас туда попадает путь относительно проекта, что совсем не кошерно. А в макрореференсы у меня и руками не получилось запихать $(Nemerle)\Nemerle.Linq.dll
Здравствуйте, Ziaw, Вы писали:
Z>Только при этом подключаемые сборки из папки лежащей внутри %Nemerle% должны попадать в референсы и макрореференсы тоже как $(Nemerle)\relative_to_nemerle_path. Сейчас туда попадает путь относительно проекта, что совсем не кошерно.
Хорошая мысль. Создай фич-реквест.
Z>А в макрореференсы у меня и руками не получилось запихать $(Nemerle)\Nemerle.Linq.dll
Странно. Что за проблема?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.