Possibly slightly obvious but nonetheless a minor little tip to bear in mind when moving a project (.dproj/.dpr) by saving it to a new location (which I encountered this morning):
Possibly slightly obvious but nonetheless a minor little tip to bear in mind when moving a project (.dproj/.dpr) by saving it to a new location (which I encountered this morning):
While the IDE will automatically adjust form/pas file paths for files included in the project in the .dpr for you, what it will not however do is also adjust the project "Search path" in a similar fashion, even though moving the project is guaranteed to break the project if it has project relative search paths and hence they would require adjusting.
That is to say, if you have project relative search folders specified in the "Search path" (and indeed the output folders), you will need to manually go and edit these paths in the project by hand when you change the project's location.
(I'd argue that the IDE ought to update relative paths in the project options automatically given that it does so already for the .dpr; it would be the intuitive and graceful thing to do.)
While the IDE will automatically adjust form/pas file paths for files included in the project in the .dpr for you, what it will not however do is also adjust the project "Search path" in a similar fashion, even though moving the project is guaranteed to break the project if it has project relative search paths and hence they would require adjusting.
That is to say, if you have project relative search folders specified in the "Search path" (and indeed the output folders), you will need to manually go and edit these paths in the project by hand when you change the project's location.
(I'd argue that the IDE ought to update relative paths in the project options automatically given that it does so already for the .dpr; it would be the intuitive and graceful thing to do.)
It owns the .dpr and .dproj so should adjust all paths in them, not just the ones of files listed in the project manager.
ReplyDeleteJeroen Wiert Pluimers Exactly, thanks! :)
ReplyDeleteJeroen Wiert Pluimers not sure if I'd wanted it to do that.
ReplyDeleteMartijn Coppoolse I assume you meant to say "that's why you always use absolute paths in the search path", otherwise what you said doesn't make sense. The trouble is fixed paths are actually very restrictive, it basically means you can only have one checkout of the code in one and only one place, and moreover this has to be the same for every developer on every workstation they happen to work at, and the code must be on the the same drive as well. I however often have multiple checkouts of the same repository (working on different features or tasks); moreover source code location on my workstation at home is on a separate drive which has a different drive letter. Having absolute paths would therefore be very problematic for me/us at least. The relative path not updating by itself when the .dproj moves is in comparison annoying but relatively minor, one doesn't move projects around that often and it's a quick edit in a text editor to fix, needed only when the projects relative depth location has changed. (With apologies, not wanting to be disagreeable! :)
ReplyDeleteWalter Prins another problem is that when you add files to a project from the various drives, Delphi always makes some of these paths absolute. I've not dug deep into finding a pattern there (as I managed to work around the situations it happened in), but sometimes this means having absolute search paths too.
ReplyDeleteAnother cool tip is to ensure that search paths depend on an environment variable like the IDE does for $(BDS) which allows you to switch complete environments quite easily.