How to move the sourcetrail project location, e.g. to a sub-dir

[PhilipOakley]

As a typical startup user I put/left the Sourcetrail database at the project top level.

I now realise it would be much better to place it in a ./Sourcetrail/ sub-directory of the project for separation of concerns within the git/VCS (version configuration system) and the actual project files.

Is there a method for doing the move?

Do any of the files need tweaking to adjust relative or absolute paths. Is it just the three *.srctrl* files It looks like the [prj] file is xml text, but, for me, doesn't appear to have a path to the project.

[egraether]

It depends on whether you defined the file and directory paths within your project as relative or absolute. Our file picker will automatically convert them to relative. If they are absolute you can move without problem.

The .srctrlprj file is XML, you can open it with a text editor and do changes.

[PhilipOakley]

Our file picker will automatically convert them to relative.

So, for editing the .srctrlprj file I will need to add a leading .. , or maybe /.. to move up one directory level from the new Sourcetrail sub-dir.

Do the compiler flags also need tweaking, or are they relative to the (corrected) buildpath?

Below are three examples from my current .srctrlprj file at the top level:

        <build_file_path>
            <compilation_db_path>compile_commands.json</compilation_db_path>
        </build_file_path>

        <indexed_header_paths>
            <indexed_header_path>./</indexed_header_path>
        </indexed_header_paths>

         <compiler_flag>-D GIT_HTML_PATH=&quot;share/doc/git-doc&quot;</compiler_flag>

I guess the buildpath becomes ../compile_commands.json and the indexer path ../, though I'm unsure about the compiler flags (from the user's viewpoint their 'project' isn't 'sourcetrail').

I'll also try some hacking to see what happens if I start another sourcetrail project inside my single project (so getting two sourcetrail projects for the price of one user project..).

[PhilipOakley]

getting two sourcetrail projects for the price of one user project

I tested the creation of a second Sourcetrail project to be located in the newly created Sourcetrail sub-dir.

I used the navigation (two places) to select the compilation compile_commands.json file and also my project's top level. I copy/pasted the compiler directives from the old 'toplevel' version of the sourcetrail project, and then pasted them into the new sub-dir sourcetrail project without adjustment, and it all indexed just fine.

Here's the edited XML

        <build_file_path>
            <compilation_db_path>../compile_commands.json</compilation_db_path>
        </build_file_path>

        <header_search_paths>
            <header_search_path>..</header_search_path>
        </header_search_paths>

note that it is a

        <name>C/C++ from Compilation Database</name>

(repeats for the <type> entry.)

The compiler flags look identical.

Next step: shift the old srctrl project files out of the way/rename and see if re-index works..

• Success! Hope that helps anyone else trying the manoeuvre.

[PhilipOakley]

Actually I missed out making sure that the header includes were added and pointing at the top level. I'd actually added an entry to the additional includes. Now corrected. I only noticed when trying to navigate something and reached a non-indexed entry reference.

These answers probably also answer a question as to whether the same .srctrlprj files can be used portably between OSes (Win/Nix/Mac), with an answer of 'almost' (but not quite). Unsure if the forward-backward slashes need tweaking etc., but expect some small changes.

[PhilipOakley]

Hmmm, think I've hit a diminishing returns problem.

I realised that I hadn't moved the destination of the /compile_commands.json export (from the VS add-in) to the 'Sourcetrail' sub-dir so as to keep all the bits in a separate sub-dir.

It looks like things are breaking at this point in that while VS is happy, the Clang view is starting from the sub-dir (i.e. the /compile_commands.json location) and it's probably missing a load of references (non-indexed symbols) because the includes are not right. Even when I tweaked the paths in the "-D " directives (there were fewer than expected), I still got the non-indexed symbols.

Think I need to restart with a clean slate using the top-level dir. Re-prove that use case. Then restart for the sub-dir case to clarify which parts are failing.

Options appear to be:

1. All files (compile_commands.json, Git_ScrTrl.srctrlprj, Git_ScrTrl.srctrldb, Git_ScrTrl.srctrlbm) at top level (works)
2. .json at top level, other three srctrl* in sub dir. (appears to work)
3. All files in sub dir. (not working yet, relative [to what] path troubles)

[PhilipOakley]

Options appear to be:

1. All files (`compile_commands.json, Git_ScrTrl.srctrlprj, Git_ScrTrl.srctrldb, Git_ScrTrl.srctrlbm`) at top level (works)

2. `.json` at top level, other three `srctrl*` in sub dir. (appears to work)

3. All files in sub dir. (not working yet, relative [to what] path troubles)

It does look like all three option can and do work, at least when using the VS Extension to export the compile_commands.json file to the correct sub-directory (as opposed to moving it there).

Obviously for the sub-dir case, the Source Group settings for include files will be .. rather than ./, but these were correctly offered in the selection dialog.

Looking good. Have used it to explore the Git code base. The "Custom trail..." (under the Edit menu), should be more positively highlighted in the intro explanatory videos!

Looking good. Finding it useful.

(can be closed once a few days have past and a few folk have read this)