[gme-users] GME Interpreters and CVS: How to generalize *.dsp files across computers

[Krishnakumar B]

On Tuesday, 28 September 2004, Jonathan Sprinkle wrote:
> Hey All,
>
> This msg is probably best answered by Peter or someone skilled in the
> hackful ways of GME interpreter development.
>
> I am using at least two, sometimes three, computers interchangeably. For
> performance reasons, at least one of my computers has GME installed to the
> "D" drive, rather than the "C" drive.
>
> This means that when running ConfigureComponent, my GME SDK files are found
> in the GME_ROOT=C:\[InstallDir]\SDK for one computer, and
> D:\[InstallDir]\SDK for the other. While INCLUDE paths can use environment
> variables to get around this, there is the problem of the files that are
> included in the project tree.
>
> This presents a problem when getting/updating code across my CVS tree, since
> if I download to one directory it has no idea how to compile the *.idl
> files, since my "D" drive is the DVD/CDROM. My current solution to this is
> to Search&Replace the "D:/" with "C:/" in the *.dsp files.

Don't hardcode any absolute paths in the .dsp files. Just use the
environment variables. We use GME_ROOT all the time in MPC files to
generate VC projects. VC7 is much better at handling environment variables.
VC6 is evil; it handles environment variables at all places except the
value of OutputDir.

The only problem that I have seen with compiling the IDL files is that
though VC understands environment variables and expands them correctly even
if there is a space in the filename, when doing a custom build to compile
the IDL files using MIDL, you have to be careful in quoting the value of
GME_ROOT so it will expand to %ProgramFiles%\GME\ even if there are spaces
somewhere in the path.

> Is there a way to alternatively structure the file generation process, so
> that the files are not included as pieces of the Project, or does VC7 (I
> am using VC6) allow containment of files based on $ENV variables?

I don't know how configurecomponent.exe works but I assume it should be
straightforward to generate workspaces to use the environment variable
GME_ROOT instead of hard-coding the path.

-kitty.