IDE: Переменные - История изменений

SergeMukhin в 11:16, 5 ноября 2007

2007-11-05T11:16:52Z

← Предыдущая		Версия 13:16, 5 ноября 2007
Строка 1:		Строка 1:
	В IDE Вы можете определить так называемые переменные среды IDE. Мы покажем здесь один из случаев ~~удобного~~ их использования.		В IDE Вы можете определить так называемые переменные среды IDE. Мы покажем здесь один из случаев их использования.

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

	Скоро Вы обнаружите, что ссылки на эти пакеты по их абсолютным ~~маршрутам~~ (как c:\sharedTools\tool1\tool1.pack) - плохая практика, поскольку это закрепляет местоположение на диске, а это, в свою очередь затрудняет реструктуризацию дискового пространства, а при работе в группе все члены группы ~~вынуджены~~ использовать одинаковую организационную структуру диска.		Скоро Вы обнаружите, что ссылки на эти пакеты по их абсолютным путям (как c:\sharedTools\tool1\tool1.pack) - плохая практика, поскольку это закрепляет местоположение на диске, а это, в свою очередь затрудняет реструктуризацию дискового пространства, а при работе в группе все члены группы вынуждены использовать одинаковую организационную структуру диска.

	Вместо этого Вы можете использовать относительные маршруты (например ..\sharedTools\tool1\tool1.pack), это несколько лучше, поскольку теперь Вы можете установить по крайней мере свою собственную директорию верхнего уровня (и, следовательно, другой ~~дисковод~~ при необходимости).		Вместо этого Вы можете использовать относительные маршруты (например ..\sharedTools\tool1\tool1.pack), это несколько лучше, поскольку теперь Вы можете установить по крайней мере свою собственную директорию верхнего уровня (и, следовательно, другой диск при необходимости).

	Однако по-прежнему расположение пакетов привязано относительно проектов, и это ~~создает~~ примерно те же проблемы, что и раньше, только может быть менее ~~жесткие~~.		Однако по-прежнему расположение пакетов привязано относительно проектов, и это создаёт примерно те же проблемы, что и раньше, только может быть менее жёсткие.

	Использование переменных среды IDE повышает гибкость. Давайте рассмотрим имя файла $(Tools)\tool1\tool1.pack. Чтобы его можно было использовать, Вы должны определить переменную среды $(Tools) и затем Вам необходимо включить переменную $(Tools) в качестве include-директории в установках проекта.		Использование переменных среды IDE повышает гибкость. Давайте рассмотрим имя файла $(Tools)\tool1\tool1.pack. Чтобы его можно было использовать, Вы должны определить переменную среды $(Tools) и затем Вам необходимо включить переменную $(Tools) в качестве include-директории в установках проекта.
Строка 17:		Строка 17:
	Теперь, если Вы решите переместить sharedTools в другое место, Вы можете смело это сделать и только переопределить переменную $(Tools). Переменные IDE разделяются среди всех проектов, и такое изменение должно быть сделано лишь один раз для того, чтобы все проекты смогли бы использовать такие пакеты. Разные члены группы могут иметь директории с общими пакетами в различных местах, поскольку каждый член группы использует свою собственную переменную $(Tools).		Теперь, если Вы решите переместить sharedTools в другое место, Вы можете смело это сделать и только переопределить переменную $(Tools). Переменные IDE разделяются среди всех проектов, и такое изменение должно быть сделано лишь один раз для того, чтобы все проекты смогли бы использовать такие пакеты. Разные члены группы могут иметь директории с общими пакетами в различных местах, поскольку каждый член группы использует свою собственную переменную $(Tools).

	Такая стратегия ~~длительно~~ используется для $(ProDir), которая всегда ссылается на директорию установки системы программирования Visual Prolog на данном компьютере.		Такая стратегия используется для $(ProDir), которая всегда ссылается на директорию установки системы программирования Visual Prolog на данном компьютере.

	=Ссылки=		=Ссылки=
	[[en:IDE Variables]]		[[en:IDE Variables]]
	[[Категория:VipIDE]]		[[Категория:VipIDE]]

Victor Yukhtenko в 14:11, 31 октября 2007

2007-10-31T14:11:08Z

← Предыдущая		Версия 16:11, 31 октября 2007
Строка 1:		Строка 1:
	~~In the~~ IDE ~~you can define so called~~ IDE ~~variables~~. ~~Here I will describe one good place to use such a variable~~.		В IDE Вы можете определить так называемые переменные среды IDE. Мы покажем здесь один из случаев удобного их использования.

	~~Over time most programmers~~, ~~teams~~, ~~companies, etc build up a set of software packages, which are used in many projects~~. ~~Sometimes these packages are simply copied fro one project to another~~, ~~but this leads to many copies of~~ (~~nearly~~) ~~the same software~~. ~~And each time you find a bug or make an improvement you have to make it many places~~.		Большинство программистов, групп и компаний создают наборы программных пакетов, которые используются во многих проектах. Иногда эти пакеты просто копируются из одного проекта в другой, однако это приводит к появлению большого числа копий одного и того же (почти) программного обеспечения. И каждый раз, найдя ошибку, или улучшив пакет, приходится вносить изменения во все копии использованных таким образом пакетов.

	~~Eventually, you decide to share these packages instead of copying them~~. I.~~e. you will only have one copy of these packages on the disk. This means that the packages will lie outside the projects~~, ~~rather than inside them~~.		В конце концов Вы решаете сделать эти пакеты разделяемыми вместо их копирования. То есть у Вас будет всего одна копия этих пакетов на диске. Это значит, что пакеты будут теперь лежать вне проектов, вместо того, чтобы лежать внутри их.

	~~You will discover that it is not a good idea to reference such shared packages by an absolute path~~ (~~like~~ c:\sharedTools\tool1\tool1.pack), ~~because that fixates the placement on the disk~~, ~~which makes restructuring of the disk difficult and in teams all team members will need an identical disk layout~~.		Скоро Вы обнаружите, что ссылки на эти пакеты по их абсолютным маршрутам (как c:\sharedTools\tool1\tool1.pack) - плохая практика, поскольку это закрепляет местоположение на диске, а это, в свою очередь затрудняет реструктуризацию дискового пространства, а при работе в группе все члены группы вынуджены использовать одинаковую организационную структуру диска.

	~~Instead you may use relative paths~~ (~~like~~ ..\sharedTools\tool1\tool1.pack), ~~this is a little better~~, ~~because now you can at least choose different top level directory~~ (~~and therefore for example different disk drive~~).		Вместо этого Вы можете использовать относительные маршруты (например ..\sharedTools\tool1\tool1.pack), это несколько лучше, поскольку теперь Вы можете установить по крайней мере свою собственную директорию верхнего уровня (и, следовательно, другой дисковод при необходимости).

	~~But still the placement of the tools is locked relative to the projects~~, ~~and this have some of the same drawbacks as above only a little less strong~~.		Однако по-прежнему расположение пакетов привязано относительно проектов, и это создает примерно те же проблемы, что и раньше, только может быть менее жесткие.

	~~Using an~~ IDE ~~variable increase the flexibility, i.e~~. ~~let us name the file~~ $(Tools)\tool1\tool1.pack. ~~To do this you must define the IDE variable~~ $(Tools) ~~and then you must make~~ $(Tools) an include ~~directory in the project settings~~.		Использование переменных среды IDE повышает гибкость. Давайте рассмотрим имя файла $(Tools)\tool1\tool1.pack. Чтобы его можно было использовать, Вы должны определить переменную среды $(Tools) и затем Вам необходимо включить переменную $(Tools) в качестве include-директории в установках проекта.

	~~When the~~ include ~~paths uses~~ IDE ~~Variables~~, ~~the project tree will also reflect this~~.		Когда include-маршруты используют переменные IDE, проектное дерево также показывает это.

	~~If you decide to move the~~ sharedTools ~~to another place you can just do it and then redefine the~~ $(Tools) ~~variable~~. IDE ~~variable are shared across all projects~~, ~~so this update only has to be done once to work for all projects~~. ~~Different people in a team can have the tools directory in different places~~, ~~because each person have their own~~ $(Tools) ~~variable~~.		Теперь, если Вы решите переместить sharedTools в другое место, Вы можете смело это сделать и только переопределить переменную $(Tools). Переменные IDE разделяются среди всех проектов, и такое изменение должно быть сделано лишь один раз для того, чтобы все проекты смогли бы использовать такие пакеты. Разные члены группы могут иметь директории с общими пакетами в различных местах, поскольку каждый член группы использует свою собственную переменную $(Tools).

	~~This strategy has long been used for~~ $(ProDir) ~~which always points to the~~ Visual Prolog ~~installation directory of the current compiler~~.		Такая стратегия длительно используется для $(ProDir), которая всегда ссылается на директорию установки системы программирования Visual Prolog на данном компьютере.

			=Ссылки=
			[[en:IDE Variables]]
	[[Категория:VipIDE]]		[[Категория:VipIDE]]

Victor Yukhtenko: «Переменные Среды (IDE)» переименована в «IDE: Переменные»

2007-10-31T13:39:45Z

«Переменные Среды (IDE)» переименована в «IDE: Переменные»

← Предыдущая	Версия 15:39, 31 октября 2007
(нет различий)

Victor Yukhtenko в 13:39, 31 октября 2007

2007-10-31T13:39:00Z

← Предыдущая		Версия 15:39, 31 октября 2007
Строка 19:		Строка 19:
	This strategy has long been used for $(ProDir) which always points to the Visual Prolog installation directory of the current compiler.		This strategy has long been used for $(ProDir) which always points to the Visual Prolog installation directory of the current compiler.

	[[~~Category~~:VipIDE]]		[[Категория:VipIDE]]

Victor Yukhtenko в 13:38, 31 октября 2007

2007-10-31T13:38:32Z

← Предыдущая		Версия 15:38, 31 октября 2007
Строка 19:		Строка 19:
	This strategy has long been used for $(ProDir) which always points to the Visual Prolog installation directory of the current compiler.		This strategy has long been used for $(ProDir) which always points to the Visual Prolog installation directory of the current compiler.

	[[Category:~~VipIde~~]]		[[Category:VipIDE]]

Victor Yukhtenko в 13:37, 31 октября 2007

2007-10-31T13:37:09Z

← Предыдущая		Версия 15:37, 31 октября 2007
Строка 19:		Строка 19:
	This strategy has long been used for $(ProDir) which always points to the Visual Prolog installation directory of the current compiler.		This strategy has long been used for $(ProDir) which always points to the Visual Prolog installation directory of the current compiler.

	[[Category:~~VipIDE~~]]		[[Category:VipIde]]

Victor Yukhtenko в 13:36, 31 октября 2007

2007-10-31T13:36:46Z

← Предыдущая		Версия 15:36, 31 октября 2007
Строка 19:		Строка 19:
	This strategy has long been used for $(ProDir) which always points to the Visual Prolog installation directory of the current compiler.		This strategy has long been used for $(ProDir) which always points to the Visual Prolog installation directory of the current compiler.

	[[Category:~~VipСреда~~]]		[[Category:VipIDE]]

Victor Yukhtenko: Новая: In the IDE you can define so called IDE variables. Here I will describe one good place to use such a variable. Over time most programmers, teams, companies, etc build up a set of softw...

2007-10-31T13:36:06Z

Новая: In the IDE you can define so called IDE variables. Here I will describe one good place to use such a variable. Over time most programmers, teams, companies, etc build up a set of softw...

Новая страница

In the IDE you can define so called IDE variables. Here I will describe one good place to use such a variable.

Over time most programmers, teams, companies, etc build up a set of software packages, which are used in many projects. Sometimes these packages are simply copied fro one project to another, but this leads to many copies of (nearly) the same software. And each time you find a bug or make an improvement you have to make it many places.

Eventually, you decide to share these packages instead of copying them. I.e. you will only have one copy of these packages on the disk. This means that the packages will lie outside the projects, rather than inside them.

You will discover that it is not a good idea to reference such shared packages by an absolute path (like c:\sharedTools\tool1\tool1.pack), because that fixates the placement on the disk, which makes restructuring of the disk difficult and in teams all team members will need an identical disk layout.

Instead you may use relative paths (like ..\sharedTools\tool1\tool1.pack), this is a little better, because now you can at least choose different top level directory (and therefore for example different disk drive).

But still the placement of the tools is locked relative to the projects, and this have some of the same drawbacks as above only a little less strong.

Using an IDE variable increase the flexibility, i.e. let us name the file $(Tools)\tool1\tool1.pack. To do this you must define the IDE variable $(Tools) and then you must make $(Tools) an include directory in the project settings.

When the include paths uses IDE Variables, the project tree will also reflect this.

If you decide to move the sharedTools to another place you can just do it and then redefine the $(Tools) variable. IDE variable are shared across all projects, so this update only has to be done once to work for all projects. Different people in a team can have the tools directory in different places, because each person have their own $(Tools) variable.

This strategy has long been used for $(ProDir) which always points to the Visual Prolog installation directory of the current compiler.

[[Category:VipСреда]]