IDE Variables - Revision history

Bcent1234: minor typos.

2007-11-09T14:21:58Z

minor typos.

← Older revision		Revision as of 16:21, 9 November 2007
Line 1:		Line 1:
	In the IDE you can define so called IDE variables. Here I will describe one good place to use such a variable.		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.		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 from 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.		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.		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 fixes the placement on the disk, which makes restructuring of the disk difficult and 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).		Instead, you may use relative paths (like ..\sharedTools\tool1\tool1.pack), this is a little better, because you can at least choose a 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~~.		But still the placement of the tools is locked relative to the projects, and this has some of the same drawbacks as the fixed placement approach above, only a little less limiting.

	~~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.		As an example you can use an IDE variable to 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.		When the include paths use 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.		If you decide to move the shared Tools to another place, you can just do it and then redefine the $(Tools) variable. IDE variables 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 has 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.		This strategy has long been used for the IDE variable $(ProDir) which always points to the Visual Prolog installation directory of the current compiler.

	[[ru:IDE: Переменные]]		[[ru:IDE: Переменные]]
	[[Category:IDE]]		[[Category:IDE]]

Victor Yukhtenko at 14:12, 31 October 2007

2007-10-31T14:12:34Z

← Older revision		Revision as of 16:12, 31 October 2007
Line 19:		Line 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.

			[[ru:IDE: Переменные]]
	[[Category:IDE]]		[[Category:IDE]]

Thomas Linder Puls: categorized

2007-09-23T15:04:16Z

categorized

← Older revision		Revision as of 17:04, 23 September 2007
Line 18:		Line 18:

	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:IDE]]

Thomas Linder Puls: New page: 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 softwar...

2007-09-23T14:27:29Z

New page: 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 softwar...

New page

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.