- Grouping project configuration with the project.
- The ability to split the configuration of the IDE between team settings and personal settings.
IncludePath=c:\include;$(SUPLIB)\include AdditionalLibraries=c:\lib;$(SUPLIB)\libIf you have a set of variables that map to the latest versions of a supporting package you would expect those variables to change as the code base moves forward. If you looked at a version from last year you would like those variables to point to what they pointed to a year ago. I currently work for a company that uses normal environment variables in order to get around this problem. As far as I can work out there are no advantages of doing this and several disadvantages:
- Every user needs to set up all the variables on their PC, or their new PC, or the dedicated PC they are using as a build machine.
- Every user has to keep track of when these variables are modified or new ones are created.
- Once an environment variable is set up you can’t have a different definition, for that environment variable, per project.
- You need a master document to hold all these configuration options, so that when you are trying to use a new machine you don’t miss anything out.
- Don’t know about you, but I use ten’s of supporting libraries, and so the more you have the longer it takes to configure a machine and the more error prone this process can be.
SUPLIB_1_2=z:\lib1.2 SUPLIB_2_0=z:\lib2.0So when someone updates the support library:
- They must get every developer to add a new environment variable
SUPLIB_3_0=z:\lib3.0to their machine.
- They must also update a master document containing all the configuration items that must be configured to do a build.
- All the projects that use this supporting library must have their project files changed to use this new location to pick up the latest libraries.
- Firstly navigate to the location of the solution file ending
- Create a file called
SolutionProperties.vspropsin your favourite editor.
- Enter the following definitions. You can see that ZDRIVE is defined as the first macro and it is used in subsequent macros. Under Clearcase (and every other source controller) everything is relative to the root. It’s just that the root can change its location.
<?xml version="1.0" encoding="Windows-1252"?> <VisualStudioPropertySheet ProjectType="Visual C++" Version="8.00" Name="ClearCaseDrive" > <UserMacro Name="ZDRIVE" Value="z:" PerformEnvironmentSet="true" /> <UserMacro Name="CUDA" Value="$(ZDRIVE)\CUDA\cuda-4.0" PerformEnvironmentSet="true" /> <UserMacro Name="INTEL_IPP" Value="$(ZDRIVE)\Intel_IPP" PerformEnvironmentSet="true" /> </VisualStudioPropertySheet>
- Check in the
- For each project file:
- Load the solution/project into Visual Studio.
- Right click on the project and select Properties.
- Under Configuration Properties, click General.
- In the right hand configuration panel change Inherited Project Property Sheets to:
- Save project configuration file.
- Check the project files into the source controller.
$(SolutionDir)\SolutionProperties.vsprops’s location is defined using a standard Visual Studio macro and so it becomes independent of file system paths. There is a precedence order to the configuration files, newer variables overwrite predefined variables. Now instead of having a multitude of variables defining all the versions of a supporting library, you just need one to be defined in the
SolutionProperties.vsprops. The project needs to be updated to change the
SUPLIB, but once that is done there shouldn’t be any other need to update the project file again. When you need to update the supporting library the person in charge of doing it can update their local copy of
SolutionProperties.vsprops, build and test the new library. When they are happy they check in their local copy of
SolutionProperties.vsprops. The change to the new library is reflected in all the other developers views without them needing to know or care. They have been decoupled. Team configuration in the IDE There are many options that should be set up in a team configuration file. These settings should apply to everything and everyone. The best example of this is TABs or spaces. If you checkout a file with spaces making up the indentation and your IDE is set to use TABs then when you check it in, every line (or the line you have edited (depending on the preference)) will be different to the last version which makes spotting differences between files that bit more difficult. You may have a code formatter that needs to be allied to code before it’s checked-in, or want extra warning flagged switched on (warning free code - is good code!). Unlike library and header locations there will be a lot of personal preferences that will have to be contended with. You will have to arbitrate between what you consider team settings and personal preferences. The easiest thing to do is:
- Set up a Visual Studio installation the way you want.
- From the menu bar select Tools -> Options
- From the Options panel, select Environment -> Import and Export Settings
- The Automatically save my settings to this file option will point to your current settings file.
- Copy the current settings file to the solution directory of the source controller and call it
- Edit it, only keep the settings that apply to the team and remove everything else.
- Check in the team file.
- Send notification to your developers. Each developer must:
- Inside Visual Studio, click the Tools -> Options
- From the Options panel, select Environment -> Import and Export Settings
- Check the Use team settings file
- Unfortunately macros are not supported here, although they maybe in the future. Edit the location box to point to the team settings file.
- Click OK
I’m very black and white when it comes to buying things and doing personal shopping. I almost take it to the extreme: a £20 t-shirt should be twice as good as a £10 t-shirt with regards to build quality. If it is not twice as good I’m paying for the brand. The trouble with the brand is that it is only perceived value. Perceived value is not the same as actual value and in reality bares no relationship to build quality.
I had a girlfriend a while back who spent an awful lot of money on shoes, bags and clothes. It was a constant bone of contention that a Gucci hand bag that cost £500 cost that much because it was made from quality components. Whereas a similar looking bag made by an independent was cheaper because it was made with sub-standard materials. “You’re paying for the quality” she kept saying. Amazing, such is the power of marketing!
While there may be other things that effect the price, such as after sales support, the majority of the cost comes from the perception that if it is expensive then only a select few will be able to afford them and so with that comes exclusivity. There is no way that a pair of Emporio Armani jeans are 5 times as good as a pair of Levi jeans even though their price tag is five times more. So what am I paying for? It costs a lot of money to advertise in exclusive magazines and even more to advertise on television. I expect it costs quite a bit to push their wears on celebrities and sponsorship. But none of these expenses have anything to do with the actual product. I don’t expect these companies are pouring money into R & D to design the latest bags; market research isn’t that expensive and because it’s fashion, what ever they say the latest fashion is - then that’s what it is. So no money spent there either.
Maybe I’m taking a simplistic view on this, but is that just it. Is everyone being duped in to paying twice the price for nothing?
One of the most difficult things in the world is to convince a woman that even a bargain costs money.I ended up with a house full of things I didn’t need or want that my girlfriend had bought because they were cheap. For some reason I couldn’t convince her that just because they had knocked 50% off the price didn’t mean that it was a bargain. It only became a bargain if we needed it and more often than not it was just used as ammo for her argument about buying a bigger house!