Configuring a private user repo of the AMDC to use relative paths

[elsevers]

... is hard!!

This is a followup to PR #54, where we added this user alert to the Building and Running Firmware instructions:

If you plan to work on your private user repositories on multiple computers, it is recommended that you clone it to the same directory on each computer. Take this into consideration when first establishing your private repo (i.e., don’t clone it to the D drive if not all computers have a second hard drive).

This is due to certain Xilinx SDK settings using absolute (instead of relative) file system paths.

I have since managed to convert my private repository to using relative paths. Converting a project environment configured with absolute paths to use relative paths proved to be not for the faint of heart! It required me to do multiple iterations of manual edits to my .project and .cproject files and then in SDK deleting and re-adding the common folder and configuring the project build settings. But finally, when the smoke cleared out, I was able to successfully get my code building on two computers with different locations of the private user repo!

For others' reference, here is a diff screenshots from before/after the changes:
.cproject

and .project

I do think that if one step in the set up instructions was changed from Browse to... to instead typing in a relative path (../AMDC-Firmware/sdk/app_cpu1/common), the whole system might just set itself up using relative paths. Maybe....

My main takeaway after all this is that SDK is... challenging. And my second takeaway is that one should try to just place the private user repo in the same location always (as opposed to trying to provide a procedure for converting absolute paths to relative paths).

Anyway, I am posting here in case there is any follow on discussion and because this will be much easier to track down later in case other users need it than PR #54 will be.

[mohamed-dek1]

To add to this discussion, you only need to update paths in either file if they are absolute paths. Absolute paths make a project non-portable and need to be converted to workspace-relative or project-relative paths.

Below are examples of absolute paths that require manual modification:

.cproject

<listOptionValue builtIn="false" value="C:/WorkingCopies/...."/>

.project

<link>
    <name>common</name>
    <type>2</type>
    <location>C:/PersonalFolder/.../common</location>
</link>

And here are examples of properly formed relative paths, which don't need to be changed:

.cproject

<listOptionValue builtIn="false" value="../app_cpu1/src"/>
<listOptionValue builtIn="false" value="${workspace_loc:/app_cpu1/common}"/>

.project

<link>
    <name>common</name>
    <type>2</type>
    <locationURI>$%7BPARENT-1-PROJECT_LOC%7D/.../common</locationURI>
</link>

This addition to the discussion is brought up by the PR below.

• https://github.com/Severson-Group/full-bridge-converter/pull/109