Reputation: 26356
I've a bunch of projects with some common libraries in a SVN repository. The repository has some branches for in-production versions.
For this reason (checking out several versions on one computer, and minimizing swap time), I tried to configure all projects as much as possible with relative paths within the repository. (....\libraries\common for forms in .dpr and library searchpaths).
This is not 100% ideal (it occasionally gets confused if you file->open and browse to a different dir, but that is easily solved by opening a file in the rootdir (the dir with the .dpr)).
But now I started to use the ITE I see that the hierarchy built by the resource wizard contains absolute paths. (drive/full/path/to/checkout).
Does sb have a good solution to deal with this? Specially the ITE bit. Are there macro's in search paths that denote the working dir?
P.s. I've used visual sourcesafe so I'm aware of the usual subst tricks. I prefer a solution without any action on changing project trees. (the modifying of projects to use relative paths is one-off, and checked in, so not that painful)
P.s.2 the situation within projects (not ITE, but normal projects) can be defused by always closing projects before opening new ones.
Upvotes: 4
Views: 1093
Reputation: 165
I have tried using Delphi environment vars in .dpr to include a file not in the project dir. For example I set variable $(Elsewhere) to be C:\dev\Elsewhere, whereas the Project is located in C:\dev\Here and .dpr contains
..
XXXUtils in '$(Elsewhere)\Utils\XXXUtils.pas',
..
It compiles fine, but .dProj keeps the evaluated relative paths, i.e.
<DCCReference Include="..\Elsewhere\Utils\XXXUtils.pas"/>
If I manually put
<DCCReference Include="$(Elsewhere)\Utils\XXXUtils.pas"/>
it all works but on the next .dProj save, the DCCReference reverts to .. Ditto when deleting the .dproj and recreating it from .dpr
So using Delphi environment vars can work, if one is very careful about modifying .dProj This typically requires manually crafting it and keeping it read-only. Which keeps bring up annoying error msgs.
Not a real solution but may help someone somewhat in dealing with including files from foreign paths in Delphi projects. Also will hopefully keep this subject alive and give it a tiny bit more visibility.
EDIT: actually, things in part work better than expected. If I change the $(Elsewhere) value and save the Project in IDE, the DCCReferences in .dproj are updated with the new evaluated path values.
However that exposes a new problem .. in RemObjects projects, .dProj includes the line
<None Include="..\Elsewhere\XXX.remoteRODL"/>
As this reference does not come from .dpr (or any .pas AFAICS) it does not get updated once one updates the $(Elsewhere) value. So the only solution here would be to manually modify .dProj:
<None Include="$(Elsewhere)\XXX.remoteRODL"/>
keep it read-only and re-open the .dProj in IDE on every change of $(Elsewhere) environment variable.
Upvotes: 0
Reputation:
File a QC request if one does not exist yet - it's not the only places where Delphi stubbornly uses absolute paths instead of relative ones. Especially the ITE got very little attention and never was polished since it was introduced.
Upvotes: 0
Reputation: 26356
I found a partial solution. In the first dialogue you can edit the rootdirectory (by playing with the tickmark so that "edit rootdir" gets enabled). If you set the rootdir to a directory that is the parent of all dirs with forms, the IDE remains in "relative" mode.
This is still not perfect (it now ends up in the rootdir instead of the app dir), but at least this works with branches. (and maybe a bit postediting the .dproj will solve even this
Update: this won't work, since the absolute path is still in every .dfn. It is just that the IDE will look nice, since the project shows the paths relative in the IDE (the paths in the .dfn are corrected with the rootdir path it seems)
Upvotes: 1