NemerleBinPathRoot определяет корневой каталог в которой должны быть установлены все версии Nemerle. Каждая конкретная версия помещается в подкаталог соответствующий названию версии (т.е. свойству NemerleVersion).
По умолчанию считается путем к корневому каталогу считается %ProgramFiles%\Nemerle. Если этот путь будет изменен в инсталляторе, то инсталлятор пропишет в переменную среды окружения NemerleBinPathRoot путь к этому каталогу.
Примечание: MSBuild (и соответственно VS) воспринимают переменные окружения как MSBuild-свойства. Так что установка переменной окружения эквивалентна заданию значения MSBuild-свойства.
Поставить разные версии Nemerle в независимые каталоги будет невозможно.
Таким образом, если вы хотите переместить бинарники немерла в какой-то другой каталог (отличный от принятого по умолчанию), вам проедется определить NemerleBinPathRoot.
Если вы захотите задать пути к бинарникам на время сборки како-либо проекта, то вы можете временно установить переменные среды NemerleBinPathRoot или Nemerle. Собственно, все должно быть понятно из определения данных свойств приведенного выше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Новый алгоритм вычисления путей к бинарникам Nemerle
Здравствуйте, VladD2, Вы писали:
VD>Теперь, при компиляции MSBuild-проектов (они же проекты VS 20XX), путь к бинарникам Nemerle будет определяться тремя свойствами проекта: VD>
VD>NemerleBinPathRoot определяет корневой каталог в которой должны быть установлены все версии Nemerle. Каждая конкретная версия помещается в подкаталог соответствующий названию версии (т.е. свойству NemerleVersion).
Все это правильно, только названия переменных почему-то перепутаны местами.
Бинарники ведь лежат в $(ProgramFiles)\Nemerle\Net-4.0 (это должен быть NemerleBinPathRoot)
А сам язык устанавливается в $(ProgramFiles)\Nemerle (это должен быть Nemerle)
Re[2]: Новый алгоритм вычисления путей к бинарникам Nemerle
Здравствуйте, Ziaw, Вы писали:
Z>Все это правильно, только названия переменных почему-то перепутаны местами. Z>Бинарники ведь лежат в $(ProgramFiles)\Nemerle\Net-4.0 (это должен быть NemerleBinPathRoot) Z>А сам язык устанавливается в $(ProgramFiles)\Nemerle (это должен быть Nemerle)
На мой взгляд названия адекватные. В прочем, я никогда не умел придумывать хорошие имена.
Кто-то еще согласен с Ziaw, что выбранные имена не адекватны вкладываемому в них смыслу? Если, да, то просьба предлагать альтернативные.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Новый алгоритм вычисления путей к бинарникам Nemerle
Здравствуйте, VladD2, Вы писали:
VD>Теперь, при компиляции MSBuild-проектов (они же проекты VS 20XX), путь к бинарникам Nemerle будет определяться тремя свойствами проекта: VD>
А в этом случае, $(NemerleBinPathRoot) — разве не будет всегда устанавливаться в значение: "$(ProgramFiles)\Nemerle", независимо от существования одноименной переменной окружения? Там по идее тоже надо проверять не выставлена ли соотвествующая переменная ранее инсталлятором:
Соответственно, в инсталляторе проверяем — если NemerleBinPathRoot не была установлена ранее инсталятором другой версии, то устанавливаем ее в нужное значение на основе дефолтного или выбранного пользовалем пути, а если уже была, то даем использовать для установки другой версии только этот каталог даже в advanved-режиме.
Что касается переименования, то $(Nemerle), на мой взгляд, должен указывать именно на конечный каталог с бинарниками, как есть сейчас, т.к. это обеспечит хоть какую-то обратную совместимость с уже существующими проектами. А вот $(NemerleBinPathRoot) можно назвать $(NemerleRoot), чтобы было понятнее.
KV>А в этом случае, $(NemerleBinPathRoot) — разве не будет всегда устанавливаться в значение: "$(ProgramFiles)\Nemerle", независимо от существования одноименной переменной окружения? Там по идее тоже надо проверять не выставлена ли соотвествующая переменная ранее инсталлятором:
Это, конечно же, ошибка. В шаблонах все так как ты написал:
KV>Соответственно, в инсталляторе проверяем — если NemerleBinPathRoot не была установлена ранее инсталятором другой версии, то устанавливаем ее в нужное значение на основе дефолтного или выбранного пользовалем пути, а если уже была, то даем использовать для установки другой версии только этот каталог даже в advanved-режиме.
Именно так.
KV>Что касается переименования, то $(Nemerle), на мой взгляд, должен указывать именно на конечный каталог с бинарниками, как есть сейчас, т.к. это обеспечит хоть какую-то обратную совместимость с уже существующими проектами.
Так оно и есть.
KV>А вот $(NemerleBinPathRoot) можно назвать $(NemerleRoot), чтобы было понятнее.
Ну, не знаю. По мне так NemerleBinPathRoot понятнее. Тут еще нужно учитывать то, что в будущем у нас, скорее всего, появятся каталоги библиотек для разных рантаймов (сервилат, компакт-фрэймворк, фрэймворки разных версий и т.п.), а вот бинарников самого компилятора будет меньше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
