old_dog->learn((ptr = new Trick));

Too many are the days where I head to the office, grind away, wander home, collapse in bed, and wake up the next morning feeling no better off than the previous day. Sure, some work got done, the bank balance is a bit bigger, but did I reallly improve any? Did I learn anything at all? Maybe I did, but it didn’t ‘stick,’ or was too trivial, and got lost along the way.

So, as a test, the new plan is to post here each day at least one new thing that I learned that day. Anything, work or personal, theory or practical, technique or tip, as long as it’s something I didn’t know before. It may be too technical, personal, or irrelevant to hold your interest, but who cares — this is for my benefit, not yours. :-P

Today’s (very boring) lesson is:

Our current InstallShield projects are a mess. After a build is finished, we have to copy all the built files, doc, resources, etc. to a staging area, map the staging area to a drive letter, and then run the InstallShield build, because the IS projects expect hardcoded paths to the source files through that mapped drive letter. We could point them straight at the output directories, but then they’d be a pain in the ass to change whenever a new branch is created, or moving from system to system (it might be d:\src\output… on one, c:\prj\depot\output… on another).

For the new InstallShield projects I’m creating, I think I’ll go a different way though. Instead of fully hardcoded paths, IS lets you use path variables to substitute in parts of the path. So, instead of hardcoding “c:\src\output\proj\dev_branch_4\winnt\release\foo.exe”, I can define:
       SRC_ROOT = c:\src
       BRANCH = dev_branch_4
       BUILD_TYPE = release
       PROJ_OUTPUT = <SRC_ROOT>outputproj<BRANCH>winnt<BUILD_TYPE>
and then when I add foo.exe to the project file list, its path is simply <PROJ_OUTPUT>foo.exe. If the branch name changes, or the root of the source control tree gets moved, or if I want to bundle the debug versions instead of the release versions, I only have to change a single definition. (The other parts of the path are fixed by our automated build and version control systems.) Instead of having to use a staging area, it can point right at the original locations in the source control tree or build output directories, depending on whether it’s compiled or not.

This still isn’t good enough, though. It still requires futzing about with the path variable settings in the InstallShield GUI and ideally I’d like a fully automated process as part of the build system, which means being able to do it all from the command line. Fortunately, there is a solution in the form of environment path variables, which act just like the path variables as described above, but which get their values from environment variables. All I should have to do is have a script that accepts the necessary information (passed down as part of the build process), set the appropriate environment variables, and invoke the IsCmdBld.exe to do a command-line InstallShield project build. That’ll be the goal, anyway…

The InstallShield IDE is being a pain though, and not letting me define those environment path variables in the first place. Any new ones I try to create wind up as normal path variables, even if I name them the way you’re supposed to for environment path variables. The documentation is no help either, as it’s as vague as humanly possible. Fortunately, there is a workaround: define a normal path variable, and then go to the ‘Direct Editor’ view, find the ISPathVariable table, go to the variable you just created, and change its Type column to ‘4’. Tada, it’s now an environment path variable.