Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, seregaa, Вы писали:
S>>Что значит место по умолчанию? Имхо компилятор, шаблоны проектов и т.д. не должны знать о том, какой путь для данной версии инсталятора и данной ОС является умолчальным. Думаю правильнее всегда устанавливать эту переменную, чем договариваться и соблюдать умолчальное значение.
VD>То и значит. Скажем переставил ты ОС... все будет работать так как переменная не нужна. То же самое при разработке.
ok.
Обнаружил в инсталяторе команду для установки переменной окружения, но ее значение устанавливается в [BINDIR], а эта папка давно уже не используется. Переделал на [APPLICATIONFOLDER], теперь все работает и при установке в нестандартную папку.
Наблюдая баталии дон ки хота(ов) в соседних форумах, решил немного побороться со своей закостенелостью. Вот что из этого вышло:
---------------------------
Nemerle Studio
---------------------------
Das importierte Projekt C:\Programme\Nemerle\Nemerle.MSBuild.targets wurde nicht gefunden. Vergewissern Sie sich, dass der Pfad in der <Import>-Deklaration korrekt und die Datei auf dem Datenträger vorhanden ist. C:\Dokumente und Einstellungen\Vladimir\Lokale Einstellungen\Temp\lbxyg1tn.ndx\Temp\ConsoleApplication3.nproj
---------------------------
OK
---------------------------
Ну, видимо, не судьба... Запустил интерпретатор:
Welcome to Nemerle interpreter (using ncc 1.0.0.8745).
Please enter expressions appended with ";;".
Type "Help;;" for more info.
Please wait while evaluating the config file..
— Help;;
Der Typeninitialisierer für Nemerle.Compiler.TyperBase hat eine Ausnahme verursa
cht. bei Nemerle.Compiler.Typer..ctor(ManagerClass mng)
bei Nemerle.Compiler.Typer..ctor(ManagerClass mng, TypeBuilder tb, MethodBuil
der mb)
bei Nemerle.Compiler.Typer..ctor(MethodBuilder m)
bei Nemerle.Compiler.CompilerComponentsFactory.CreateTyper(MethodBuilder m)
bei Nemerle.Compiler.MethodBuilder.RunBodyTyper()
bei Nemerle.Compiler.MethodBuilder.Compile()
bei Nemerle.Compiler.TypeBuilder.EmitImplementation()
bei Nemerle.Compiler.TypesManager._N_emit_impl__53681.apply_void(TypeBuilder
_N__53680)
bei Nemerle.Compiler.TypesManager._N_maybe_f__54248.apply_void(TypeBuilder _N
__54247)
bei Nemerle.Collections.NList.Iter[T](list`1 l, FunctionVoid`1 f)
bei Nemerle.Core.list`1.Iter(FunctionVoid`1 f)
bei Nemerle.Compiler.TypesManager.Iter(list`1 builders, FunctionVoid`1 f)
bei Nemerle.Compiler.TypesManager.Iter(FunctionVoid`1 f)
bei Nemerle.Compiler.TypesManager.compile_all_tyinfos(Boolean aux_phase)
bei Nemerle.Compiler.TypesManager._N__N_lambda__53121__53224.apply_void()
bei Nemerle.Compiler.Solver.Enqueue(FunctionVoid action)
bei Nemerle.Compiler.TypesManager.EmitDecls()
bei Nemerle.Compiler.ManagerClass.Run()
bei Nemerle.Evaluation.Evaluator.Eval(String code)
bei Nemerle.Evaluation.Interpreter.MainClass._N_printev_9740(_N_closure_9629
_N_Main_cp_9739, String c)
System.TypeInitializationException: Der Typeninitialisierer für Nemerle.Compiler
.TyperBase hat eine Ausnahme verursacht. ---> System.Configuration.Configuration
ErrorsException: Das Konfigurationssystem konnte nicht initialisiert werden. --- > System.Configuration.ConfigurationErrorsException: Unbekannter Konfigurationsa
bschnitt "dllmap". (D:\Programme\Nemerle\nemish.exe.config line 2)
bei System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean igno
reLocal)
bei System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(Configura
tionSchemaErrors schemaErrors)
bei System.Configuration.BaseConfigurationRecord.ThrowIfInitErrors()
bei System.Configuration.ClientConfigurationSystem.EnsureInit(String configKe
y)
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Configuration.ClientConfigurationSystem.EnsureInit(String configKe
y)
bei System.Configuration.ClientConfigurationSystem.PrepareClientConfigSystem(
String sectionName)
bei System.Configuration.ClientConfigurationSystem.System.Configuration.Inter
nal.IInternalConfigSystem.GetSection(String sectionName)
bei System.Configuration.ConfigurationManager.GetSection(String sectionName)
bei System.Configuration.PrivilegedConfigurationManager.GetSection(String sec
tionName)
bei System.Diagnostics.DiagnosticsConfiguration.GetConfigSection()
bei System.Diagnostics.DiagnosticsConfiguration.Initialize()
bei System.Diagnostics.DiagnosticsConfiguration.get_IndentSize()
bei System.Diagnostics.TraceInternal.InitializeSettings()
bei System.Diagnostics.Debug.set_IndentSize(Int32 value)
bei Nemerle.Compiler.TyperBase..cctor()
--- Ende der internen Ausnahmestapelüberwachung ---
bei Nemerle.Compiler.Typer..ctor(ManagerClass mng)
bei Nemerle.Compiler.Typer..ctor(ManagerClass mng, TypeBuilder tb, MethodBuil
der mb)
bei Nemerle.Compiler.Typer..ctor(MethodBuilder m)
bei Nemerle.Compiler.CompilerComponentsFactory.CreateTyper(MethodBuilder m)
bei Nemerle.Compiler.MethodBuilder.RunBodyTyper()
bei Nemerle.Compiler.MethodBuilder.Compile()
bei Nemerle.Compiler.TypeBuilder.EmitImplementation()
bei Nemerle.Compiler.TypesManager._N_emit_impl__53681.apply_void(TypeBuilder
_N__53680)
bei Nemerle.Compiler.TypesManager._N_maybe_f__54248.apply_void(TypeBuilder _N
__54247)
bei Nemerle.Collections.NList.Iter[T](list`1 l, FunctionVoid`1 f)
bei Nemerle.Core.list`1.Iter(FunctionVoid`1 f)
bei Nemerle.Compiler.TypesManager.Iter(list`1 builders, FunctionVoid`1 f)
bei Nemerle.Compiler.TypesManager.Iter(FunctionVoid`1 f)
bei Nemerle.Compiler.TypesManager.compile_all_tyinfos(Boolean aux_phase)
bei Nemerle.Compiler.TypesManager._N__N_lambda__53121__53224.apply_void()
bei Nemerle.Compiler.Solver.Enqueue(FunctionVoid action)
bei Nemerle.Compiler.TypesManager.EmitDecls()
bei Nemerle.Compiler.ManagerClass.Run()
bei Nemerle.Evaluation.Evaluator.Eval(String code)
bei Nemerle.Evaluation.Interpreter.MainClass._N_printev_9740(_N_closure_9629
_N_Main_cp_9739, String c)
—
Ну, короче, бэта — сырая... У меня все установленно (было, ибо — нефиг) на диске д. Ну, я все еще готов приобщиться...
Здравствуйте, Аноним, Вы писали:
А>Наблюдая баталии дон ки хота(ов) в соседних форумах, решил немного побороться со своей закостенелостью. Вот что из этого вышло:
А>--------------------------- А>Nemerle Studio А>--------------------------- А>Das importierte Projekt C:\Programme\Nemerle\Nemerle.MSBuild.targets wurde nicht gefunden. Vergewissern Sie sich, dass der Pfad in der <Import>-Deklaration korrekt und die Datei auf dem Datenträger vorhanden ist. C:\Dokumente und Einstellungen\Vladimir\Lokale Einstellungen\Temp\lbxyg1tn.ndx\Temp\ConsoleApplication3.nproj А>--------------------------- А>OK А>---------------------------
Не стоит менять дефолтное место установки (%ProgramFiles%\Nemerle) — иначе msbuild не сможет найти targets-файл. Вы можете открыть свой nproj файл любым текстовым редактором и подправить параметр <Nemerle/>, тогда проект соберется.
А>Ну, видимо, не судьба... Запустил интерпретатор:
А>Welcome to Nemerle interpreter (using ncc 1.0.0.8745).
Хм. Мне казалось, я это пофиксил...
Удалите nemish.exe.config — падение из за него.
Здравствуйте, hardcase, Вы писали:
H>Не стоит менять дефолтное место установки (%ProgramFiles%\Nemerle) — иначе msbuild не сможет найти targets-файл. Вы можете открыть свой nproj файл любым текстовым редактором и подправить параметр <Nemerle/>, тогда проект соберется.
Посмотрел, какой путь к таргетсам прописывается в проектах железного питона. Выяснил, что и питон, и F# используют для деплоя таргетсов подпапку в $(MSBuildExtensionsPath), которая сответствует папке "%Program Files%\MSBuild\". Может и нам так сделать?
Здравствуйте, seregaa, Вы писали:
S>Посмотрел, какой путь к таргетсам прописывается в проектах железного питона. Выяснил, что и питон, и F# используют для деплоя таргетсов подпапку в $(MSBuildExtensionsPath), которая сответствует папке "%Program Files%\MSBuild\". Может и нам так сделать?
Тогда нужно Nemerle.MSBuild складывать в GAC и как-то находить куда установлен компилятор. Может всетаки вернуться к переменной окружения?
Здравствуйте, hardcase, Вы писали:
S>>Посмотрел, какой путь к таргетсам прописывается в проектах железного питона. Выяснил, что и питон, и F# используют для деплоя таргетсов подпапку в $(MSBuildExtensionsPath), которая сответствует папке "%Program Files%\MSBuild\". Может и нам так сделать?
H>Тогда нужно Nemerle.MSBuild складывать в GAC и как-то находить куда установлен компилятор. Может всетаки вернуться к переменной окружения?
Понял. А что заставило в свое время отказаться от переменной? Кстати, можно считать путь из реестра. msbuild умеет считывать значения параметров не только из переменных окружения, но и из реестра: $(registry:Hive\MyKey\MySubKey@Value) http://msdn.microsoft.com/en-us/library/ms171458.aspx
Здравствуйте, hardcase, Вы писали:
H>Вы можете открыть свой nproj файл любым текстовым редактором и подправить параметр <Nemerle/>, тогда проект соберется. H>Удалите nemish.exe.config — падение из за него.
Здравствуйте, seregaa, Вы писали:
S>Понял. А что заставило в свое время отказаться от переменной? Кстати, можно считать путь из реестра. msbuild умеет считывать значения параметров не только из переменных окружения, но и из реестра: $(registry:Hive\MyKey\MySubKey@Value) S>http://msdn.microsoft.com/en-us/library/ms171458.aspx
Я не знаю почему от переменной окружения отказались. Когда-то была, теперь — нет.
Т.е. ты предлагаешь деплоить targets-файл и Nemerle.MSBuild в стандартный каталог, например $(MSBuildExtensionsPath)\Nemerle\1.0, а при обработки таска находить инсталляцию компилятора из реестра (если она не указана параметром Nemerle)?
Здравствуйте, Аноним, Вы писали:
А>Ждем следующий релиз
Что мешает поставить в %ProgramFiles%\Nemerle ?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[4]: Не рано ли вышла бета?
От:
Аноним
Дата:
11.04.10 11:49
Оценка:
А>>Ждем следующий релиз H>Что мешает поставить в %ProgramFiles%\Nemerle ?
На домашнем компьютере место на диске С закончилось где-то три года назад... А наш системный администратор — на дом не выезжает А чистить диск С — жена отказывается, а самому — не барское дело.
Здравствуйте, Аноним, Вы писали:
А>>>Ждем следующий релиз H>>Что мешает поставить в %ProgramFiles%\Nemerle ? А>На домашнем компьютере место на диске С закончилось где-то три года назад... А наш системный администратор — на дом не выезжает А чистить диск С — жена отказывается, а самому — не барское дело.
Здравствуйте, hardcase, Вы писали:
H>Т.е. ты предлагаешь деплоить targets-файл и Nemerle.MSBuild в стандартный каталог, например $(MSBuildExtensionsPath)\Nemerle\1.0, а при обработки таска находить инсталляцию компилятора из реестра (если она не указана параметром Nemerle)?
так, или наоборот — по умолчанию инициализировать параметр Nemerle значением из рееста.
т.е. в файле проекта вместо
<Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
прописывать
<Nemerle Condition=" '$(Nemerle)' == '' ">$(registry:...)\Nemerle</Nemerle>
Здравствуйте, seregaa, Вы писали:
S>Здравствуйте, hardcase, Вы писали:
H>>Т.е. ты предлагаешь деплоить targets-файл и Nemerle.MSBuild в стандартный каталог, например $(MSBuildExtensionsPath)\Nemerle\1.0, а при обработки таска находить инсталляцию компилятора из реестра (если она не указана параметром Nemerle)?
S>так, или наоборот — по умолчанию инициализировать параметр Nemerle значением из рееста. S>т.е. в файле проекта вместо S><Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle> S>прописывать S><Nemerle Condition=" '$(Nemerle)' == '' ">$(registry:...)\Nemerle</Nemerle>
Вообще указание размещения компилятора в пользовательских проектах нехорошая практика, этот параметр нужен в основном для сборки самого компилятора и библиотек.
Здравствуйте, hardcase, Вы писали:
H>Вообще указание размещения компилятора в пользовательских проектах нехорошая практика, этот параметр нужен в основном для сборки самого компилятора и библиотек.
Тем не менее сейчас это указание есть во всех пользовательских проектах, причем жестко указывающее на диск c:\
Давай тогда сделаем по первому варианту. Переменная в проектах по умолчанию будет отсутствовать, и в этом случае путь будет браться из рееста.
Этот путь уже прописывется инсталятором в HKEY_CURRENT_USER\Software\$(var.ProductName)\InstallDir, где $(var.ProductName) сейчас — это "Nemerle Beta 1"
S>Этот путь уже прописывется инсталятором в HKEY_CURRENT_USER\Software\$(var.ProductName)\InstallDir, где $(var.ProductName) сейчас — это "Nemerle Beta 1"
Да, из реестра видимо и стоит брать, по крайней мере FSharp.Build именно так и поступает.
Здравствуйте, seregaa, Вы писали:
S>Этот путь уже прописывется инсталятором в HKEY_CURRENT_USER\Software\$(var.ProductName)\InstallDir, где $(var.ProductName) сейчас — это "Nemerle Beta 1"
Эта переменная пустая
Может быть лучше прописывать путь в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Nemerle ?
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, seregaa, Вы писали:
S>>Этот путь уже прописывется инсталятором в HKEY_CURRENT_USER\Software\$(var.ProductName)\InstallDir, где $(var.ProductName) сейчас — это "Nemerle Beta 1"
H>Эта переменная пустая
Значит баг в инсталяторе
H>Может быть лучше прописывать путь в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Nemerle ?
А это мысль! Заодно сборки Немерле попадут в список Add Reference. Сейчас добавлю создание этого ключа в инсталятор.
H>>Может быть лучше прописывать путь в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Nemerle ? S>А это мысль! Заодно сборки Немерле попадут в список Add Reference. Сейчас добавлю создание этого ключа в инсталятор.
А ведь параметр Nemerle также используется для подцепления референсов (для пользовательских проектов NoStdLib = True).
Я так понимаю, что это требуется для копирования Nemerle.dll в каталог приложения.
Здравствуйте, Аноним, Вы писали:
А>Не рано ли вышла бета?
Дык, как же мы без вших фитбэков нашли бы ошибки?
И вообще, как тумаете, зачем выпускают бэты?
А>Наблюдая баталии дон ки хота(ов) в соседних форумах, решил немного побороться со своей закостенелостью. Вот что из этого вышло:
Спасибо за фитбэк.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если инсталляция производится не в дефолтный каталог, то нужно чтобы инсталлятор задавал занчение переменной среды окружения Nemerle.
Ну, и при деинсталляции нужно ее обязательно удалять!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Не рано ли вышла бета?
От:
Аноним
Дата:
12.04.10 20:30
Оценка:
VD>Спасибо за фитбэк.
Пожалуйста.
Кстати, если, примеры из статьи VD, которая "рассчитана на людей, не знакомых ни с чем", вставить в свежесозднанный проект — то либо так
D:\Projects\n\ConsoleApplication1\ConsoleApplication2\Main.n(12,5):Error: parse error near keyword 'def': expecting type declaration
D:\Projects\n\ConsoleApplication1\ConsoleApplication2\Main.n(12,9):Error: parse error near identifier 'fahrenheitToCelsius': unexpected token after class member (you forget a closing bracket?).
Build failed -- 2 errors, 0 warnings. Build took: 00:00:01.9876325.
либо так
D:\Projects\n\ConsoleApplication1\ConsoleApplication2\Main.n(15,1):Error: parse error near keyword 'module': unexpected keyword in expression context
D:\Projects\n\ConsoleApplication1\ConsoleApplication2\Main.n(15,8):Error: expected ';'
D:\Projects\n\ConsoleApplication1\ConsoleApplication2\Main.n(15,8):Error: parse error near identifier 'Program': unexpected token after expression in sequence (you forget a closing bracket?).
Build failed -- 3 errors, 0 warnings. Build took: 00:00:02.0070386.
Ну, я-то знаком, и разобрался быстро. А вот не знакомые ни с чем — деинсталируют.
P.S.1. Пардон.
P.S.2. На дебилов (себя имею ввиду) не обижаются.
P.S.3. А что задело? Пейсатель? Или дон ки хот?
Здравствуйте, Аноним, Вы писали:
VD>>Спасибо за фитбэк. А>Пожалуйста.
А>Кстати, если, примеры из статьи VD, которая "рассчитана на людей, не знакомых ни с чем", вставить в свежесозднанный проект — то либо так А>D:\Projects\n\ConsoleApplication1\ConsoleApplication2\Main.n(12,5):Error: parse error near keyword 'def': expecting type declaration
А в статье что написано?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Не рано ли вышла бета?
От:
Аноним
Дата:
12.04.10 21:27
Оценка:
VD>А в статье что написано?
Да, что там написано? Ты — автор, ты и говори
Здравствуйте, VladD2, Вы писали:
VD>Может кто-то попрвить компилятор? VD>Если инсталляция производится не в дефолтный каталог, то нужно чтобы инсталлятор задавал занчение переменной среды окружения Nemerle. VD>Ну, и при деинсталляции нужно ее обязательно удалять!
А таргет уже содержит код, подхватывающий эту переменную?
Может не стоит плодить переменные и использовать уже имеющееся в реестре значение? Я кстати уже поправил инсталятор, теперь значение InstallDir в реестре заполняется как надо.
Если такой подход устроит, то я пробегусь по шаблонам и заменю строку
<Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
на
<Nemerle Condition=" '$(Nemerle)' == '' ">$(registry:HKCU\Software\$(var.ProductName)\InstallDir)\Nemerle</Nemerle>
Здравствуйте, seregaa, Вы писали:
S>Если такой подход устроит, то я пробегусь по шаблонам и заменю строку S><Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle> S>на S><Nemerle Condition=" '$(Nemerle)' == '' ">$(registry:HKCU\Software\$(var.ProductName)\InstallDir)\Nemerle</Nemerle>
C этим тоже засада. Сейчас $(var.ProductName) равен Nemerle Beta 1, а через некоторое время сменится на Nemerle Beta 2 или Nemerle RC. Редактровать каждый раз шаблоны — это не дело. С другой стороны — а зачем мы включаем номер беты в название продукта? Две разные версии интеграции паралельно все равно не встанут, смысл давать им разные имена? Может уберем номер беты из названия продукта?
Здравствуйте, seregaa, Вы писали:
S>Здравствуйте, seregaa, Вы писали:
S>>Если такой подход устроит, то я пробегусь по шаблонам и заменю строку S>><Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle> S>>на S>><Nemerle Condition=" '$(Nemerle)' == '' ">$(registry:HKCU\Software\$(var.ProductName)\InstallDir)\Nemerle</Nemerle>
Параметр Nemerle нужен для:
1) указания targets файла (и как следствие Nemerle.MSBuild)
2) указания расположения стандартных библиотек: референсы сейчас указываются явно, NoStdLib = true.
3) бутстрапа компилятора
4) я штото упустил?
На мой взгляд в пользовательских проектах этого параметра быть не должно — параметр важен только для бутстрапа.
— Указать расположение targets файла можно с помощью стандартной переменной, например так: $(MSBuildExtensionsPath)\Nemerle\1.0
В этот каталог нужно деплоить targets и Nemerle.MSBuild.
— Nemerle.MSBuild может вычислять расположение инсталляции немерла посредством ключа реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Nemerle.
— Остается вопрос с референсами. Если ставить NoStdLib = false, то Nemerle.dll не попадает в аутпут каталог как это делается сейчас. Тот же вопрос с Nemerle.Compiler.dll, но его обычно указывают явно. GAC конечно призван нас спасти, но в него сейчас дистрибутив не инсталлирует сборки.
Если плюнуть на все и создать переменную окружения то вышесказанное отпадает автоматически.
Ну хм. Можно сделать частично, но не чере var.ProductName, а HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Nemerle.
Здравствуйте, hardcase, Вы писали:
H>- Указать расположение targets файла можно с помощью стандартной переменной, например так: $(MSBuildExtensionsPath)\Nemerle\1.0 H>В этот каталог нужно деплоить targets и Nemerle.MSBuild.
Наверное это самый правильный путь. А таргет пусть ищет компилятор через реестр.
H>- Nemerle.MSBuild может вычислять расположение инсталляции немерла посредством ключа реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Nemerle.
Я попробовал создвавать этот ключ, но поскольку он расположен не в пользовательской ветке реестра, а в глобальной (local machine), для этого нужен ALLUSERS режим работы инсталятора (http://msdn.microsoft.com/en-us/library/aa367559(VS.85).aspx). Если принудительно выбрать такой режим, то у пользователей при усановке интеграции могут возникнуть проблемы с нехваткой прав.
H>- Остается вопрос с референсами. Если ставить NoStdLib = false, то Nemerle.dll не попадает в аутпут каталог как это делается сейчас. Тот же вопрос с Nemerle.Compiler.dll, но его обычно указывают явно. GAC конечно призван нас спасти, но в него сейчас дистрибутив не инсталлирует сборки.
Устанавливать в GAC во время активной разработки и следовательно частых обновлений версий не удобно.
Здравствуйте, seregaa, Вы писали:
S>Здравствуйте, hardcase, Вы писали:
H>>- Указать расположение targets файла можно с помощью стандартной переменной, например так: $(MSBuildExtensionsPath)\Nemerle\1.0 H>>В этот каталог нужно деплоить targets и Nemerle.MSBuild. S>Наверное это самый правильный путь. А таргет пусть ищет компилятор через реестр.
+1
H>>- Nemerle.MSBuild может вычислять расположение инсталляции немерла посредством ключа реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Nemerle. S>Я попробовал создвавать этот ключ, но поскольку он расположен не в пользовательской ветке реестра, а в глобальной (local machine), для этого нужен ALLUSERS режим работы инсталятора (http://msdn.microsoft.com/en-us/library/aa367559(VS.85).aspx). Если принудительно выбрать такой режим, то у пользователей при усановке интеграции могут возникнуть проблемы с нехваткой прав.
Сдается мне для установки среды разработки (тем более в %ProgramFiles%) наличие администраторских привелегий — сущая необходимость.
H>>- Остается вопрос с референсами. Если ставить NoStdLib = false, то Nemerle.dll не попадает в аутпут каталог как это делается сейчас. Тот же вопрос с Nemerle.Compiler.dll, но его обычно указывают явно. GAC конечно призван нас спасти, но в него сейчас дистрибутив не инсталлирует сборки. S>Устанавливать в GAC во время активной разработки и следовательно частых обновлений версий не удобно.
Получается что переменная окружения нужна будет только ради прямого указания сборок в обход GAC.
Здравствуйте, seregaa, Вы писали:
S>Если такой подход устроит, то я пробегусь по шаблонам и заменю строку S><Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle> S>на S><Nemerle Condition=" '$(Nemerle)' == '' ">$(registry:HKCU\Software\$(var.ProductName)\InstallDir)\Nemerle</Nemerle>
Ну, а как вести разработку (когда ничего не инсталлируется)?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, seregaa, Вы писали:
S>C этим тоже засада. Сейчас $(var.ProductName) равен Nemerle Beta 1, а через некоторое время сменится на Nemerle Beta 2 или Nemerle RC. Редактровать каждый раз шаблоны — это не дело. С другой стороны — а зачем мы включаем номер беты в название продукта? Две разные версии интеграции паралельно все равно не встанут, смысл давать им разные имена? Может уберем номер беты из названия продукта?
Конечно лучше бы чтобы две разные версии могли вставать параллельно. Но если это невозможно, то действительно глупо давать разные имена каталогам.
Только причем тут проекты? В них же указывается только ветка реестра или переменная среды окружения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Параметр Nemerle нужен для: H>1) указания targets файла (и как следствие Nemerle.MSBuild) H>2) указания расположения стандартных библиотек: референсы сейчас указываются явно, NoStdLib = true. H>3) бутстрапа компилятора H>4) я штото упустил?
Еще для компиляции разных стадий. Но это можно отнести к третьему пункту.
H>На мой взгляд в пользовательских проектах этого параметра быть не должно — параметр важен только для бутстрапа.
Этот параметр позволяет использовать разные версии компилятора. Переменные ведь можно менять даже в бат-файлах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Получается что переменная окружения нужна будет только ради прямого указания сборок в обход GAC.
А зачем вы вообще изобретаете велосипеды?
Все что нужно сделать — это задавать переменную среды Nemerle в инсталляторе если установка производится в каталог отличный от дефолтного.
Зачем все эти приседания?
К тому же реестр есть тольтко под виндой. А переменные среды — везде. Разумно было бы иметь одинаковые средства настройки подо всеми поддерживаемыми ОС.
Так что бросайте возиться с реестром. Лучше доработайте инсталлятор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>А как добавить новый референс в Macro References? Правая кнопка мыши не работает.
А>Кстати просто References через ИДЕ тоже добавить не удалось... Пришлось редактировать файл проекта...
Что-то очень странное у тебя происходит. Оба пункта должны работать. Только выделять нужно именно ту ветку в которую идет добавление.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
VD>>А в статье что написано? А>Да, что там написано? Ты — автор, ты и говори
Там написано, что примеры нужно собирать из командной строки.
Интеграция не поддерживает сокращенного синтаксиса, как и синтаксиса основанного на отступах. Компилироваться код будет, но интеграция корректно работать не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Не рано ли вышла бета?
От:
Аноним
Дата:
15.04.10 06:18
Оценка:
VD>Интеграция не поддерживает сокращенного синтаксиса, как и синтаксиса основанного на отступах. Компилироваться код будет, но интеграция корректно работать не будет.
Этого я в статье — не видел. Видимо не внимательный.
Ну, вы[nemerle команда] хоть работаете над этим? Или это по каким-либо причинам не возможно?
Как часто выходят билды? Стоит ли интеграцию самому собирать?
Здравствуйте, VladD2, Вы писали:
VD>Интеграция не поддерживает сокращенного синтаксиса, как и синтаксиса основанного на отступах. Компилироваться код будет, но интеграция корректно работать не будет.
Понятно. А я только хотел спросить почему комплит (у меня в #develop) не работал без #pragma indent при включенной опции компиляции IndentationSyntax.
Здравствуйте, VladD2, Вы писали:
H>>Получается что переменная окружения нужна будет только ради прямого указания сборок в обход GAC. VD>А зачем вы вообще изобретаете велосипеды? VD>Все что нужно сделать — это задавать переменную среды Nemerle в инсталляторе если установка производится в каталог отличный от дефолтного. VD>Зачем все эти приседания?
Я думал, что существуют какие то непреодолимые причины, которые вынудили в свое время отказаться от переменной окружения. Ведь в инструкции по установке интеграции так и написано — удалите переменную окружения.
VD>К тому же реестр есть тольтко под виндой. А переменные среды — везде. Разумно было бы иметь одинаковые средства настройки подо всеми поддерживаемыми ОС.
Дельное замечание!
VD>Так что бросайте возиться с реестром. Лучше доработайте инсталлятор.
Значит используем такую схему: инсталятор создает переменную окружения Nemerle, и в пользовательских проектах эта переменная используется для указания путей к компилятору и сборкам Немерле.
Для этого нужно:
а) поправить инсталятор,
б) поправить шаблоны проектов, заменив путь "c:\program files\nemerle" на "$(env.Nemerle)"
Здравствуйте, hardcase, Вы писали:
VD>>Интеграция не поддерживает сокращенного синтаксиса, как и синтаксиса основанного на отступах. Компилироваться код будет, но интеграция корректно работать не будет.
H>Понятно. А я только хотел спросить почему комплит (у меня в #develop) не работал без #pragma indent при включенной опции компиляции IndentationSyntax.
Скорее вопрос почему он работает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, seregaa, Вы писали:
S>Я думал, что существуют какие то непреодолимые причины, которые вынудили в свое время отказаться от переменной окружения. Ведь в инструкции по установке интеграции так и написано — удалите переменную окружения.
Удалять ее нужно если установка идет в место предусмотренное по умолчанию. Старый инсталлятор туда полную пургу писал (в кавычки путь брал).
VD>>Так что бросайте возиться с реестром. Лучше доработайте инсталлятор. S>Значит используем такую схему: инсталятор создает переменную окружения Nemerle, и в пользовательских проектах эта переменная используется для указания путей к компилятору и сборкам Немерле.
Инсталлятор должен проверять производится ли установка в место предусмотренное по умолчанию, если — нет, устанавливать эту переменную, если — да, удалять ее.
S>Для этого нужно: S>а) поправить инсталятор,
Да.
S>б) поправить шаблоны проектов, заменив путь "c:\program files\nemerle" на "$(env.Nemerle)"
Нет. В проектах все ОК.
Свойств МСБилд получают значения по умолчанию из переменных среды окружения. Так что если Nemerle задана в винде, то свойство Nemerle будет установлено в проектах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Инсталлятор должен проверять производится ли установка в место предусмотренное по умолчанию, если — нет, устанавливать эту переменную, если — да, удалять ее.
Что значит место по умолчанию? Имхо компилятор, шаблоны проектов и т.д. не должны знать о том, какой путь для данной версии инсталятора и данной ОС является умолчальным. Думаю правильнее всегда устанавливать эту переменную, чем договариваться и соблюдать умолчальное значение.
S>>Для этого нужно: S>>а) поправить инсталятор, VD>Да.
S>>б) поправить шаблоны проектов, заменив путь "c:\program files\nemerle" на "$(env.Nemerle)" VD>Нет. В проектах все ОК. VD>Свойств МСБилд получают значения по умолчанию из переменных среды окружения. Так что если Nemerle задана в винде, то свойство Nemerle будет установлено в проектах.
здорово! не знал о такой особенности
Здравствуйте, seregaa, Вы писали:
S>Что значит место по умолчанию? Имхо компилятор, шаблоны проектов и т.д. не должны знать о том, какой путь для данной версии инсталятора и данной ОС является умолчальным. Думаю правильнее всегда устанавливать эту переменную, чем договариваться и соблюдать умолчальное значение.
То и значит. Скажем переставил ты ОС... все будет работать так как переменная не нужна. То же самое при разработке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Ну, вы[nemerle команда] хоть работаете над этим? Или это по каким-либо причинам не возможно?
Скажем так — это весьма не просто. А учитывая, что есть много более приоритетных задач, данная отложена в долгий ящик.
А>Как часто выходят билды? Стоит ли интеграцию самому собирать?
Раньше под каждое изменение, что было не здорово. Теперь вручную, с помощью пометки тегом некоторого комита.
Собирать самостоятельно имеет смысл если хочется видеть под отладкой код компилятора.
Собственно теперь сборка компилятора — это процесс совершенно тривиальный. Нужно только установить VS SDK.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Понятно. А я только хотел спросить почему комплит (у меня в #develop) не работал без #pragma indent при включенной опции компиляции IndentationSyntax.
Не знаю. Наверно что-то связанное с работой лексера.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
