Creating a "portable" TclApp project file (*.tpj)

Posted by jgodfrey on 2012-04-19 10:05
Forums: TDK support | OS: All / Any

I have quite a number of TclApp project files (*.tpj). Recently, I've reorganized the working copies of my source code and now need to update the TPJ files to coincide with those changes.

Generally, when I set up the "Files" section of a TclApp project, I add a reference folder, then insert files and or folders beneath that reference folder.

With that structure in mind, I assumed I could simply open the TPJ file and adjust the top-level "reference" folder to point to the new source location and all else would just fall into place. However, it seems that all paths are stored as absolute references in the TPJ file and therefore all contain the top-level folder name.

Here's a few example records:

Path                   {Relativeto C:/Users/jgodfrey/Dev/Tcl/ViewMSI}
Path                   {File C:/Users/jgodfrey/Dev/Tcl/ViewMSI/viewMSI.tcl}
Path                   Startup
Path                   {File C:/Users/jgodfrey/Dev/Tcl/ViewMSI/images/*.png}

Obviously, this is still easily fixed with some hand editing, but I wonder if there's not a better way to define my projects to keep the TPJ's more portable in the face of source code relocations? If there's not a better way, perhaps there should be?

Thanks for any advice.

Jeff Godfrey

andreas.kupries
ActiveState Staff
Tue, 2012-05-01 10:45

I seem to remember having an enhancement request in the TDK bug database, to store the paths relative to the location of the project file, instead of storing absolute path. I am unable to find it however, at the moment, so I might be mis-remembering.

Is that a change which would help you ?

Or are you more looking for a reorganization of the project file so that you only have to modify a single path ?

jgodfrey | Tue, 2012-05-01 11:40

I guess I'm not exactly sure what I'm looking for. Currently, it just seems more difficult than necessary to "move" the location of TPJ-referenced source code due to all of the absolute path names in the TPJ files.

In my most recent case, my source code "structure" remained the same, but the entire branch was physically moved to a new location. If I understand what you mean by "store the paths relative to the location of the project file, instead of storing absolute path", that would seem to be an improvement.

Essentially, any enhancement that will make a TPJ file less brittle in the face of source code relocation would certainly be helpful.

Thanks,

Jeff

andreas.kupries
ActiveState Staff
Tue, 2012-05-01 12:35

Lets see if I can explain.

An absolute path, like
C:/Users/jgodfrey/Dev/Tcl/ViewMSI/viewMSI.tcl
is fully defined.

A relative path, like
ViewMSI/viewMSI.tcl

is not fully defined. To be an fully defined path you have to know the anchor point it is relative to.

In my comment above I mused about using either the path of the project file, or the path of the directory of the project file as the anchor point.

If the files are moved somewhere else, and the project file moved with them, keeping their relative locations to each other, then the relative paths will stay valid.

Of course, either moving just the project file to somewhere else, or just the files without the project file will break the relationship and invalidate the paths.

With absolute paths the project file can move without invalidating the paths, but moving the files breaks the project.

jgodfrey | Tue, 2012-05-01 14:06

Yeah, that's exactly what I thought you meant. In my case, I do keep my project files at the top level of the source code tree that belongs to them, though I haven't always done that. In the past, I've just kept all project files in a single folder.

One comment concerning the content of the project files... In my OP, I showed some live code from one of my project files. It seems that when files or folders are defined "relative to" some other folder, their paths should literally be "relative to" the defined folder. Currently, all paths seem to be absolute regardless of whether they're defined as "relative to" or not. To me, that seems like *part* of the problem...

Jeff