Canonicalize Path


is there an action that implements the Windows API “PathCanonicalize”?

Use case:
My FinalBuilder Project is located in a subfolder “Buildsystem”, whereas the source is located in a subfolder “source”. For the FinalBuilder Script to work properly i configure a variable that looks similar to “%FBPROJECTDIR%\…\Source”.

This works fine. Canonicalizing the path will make the log easier to read, though.


Hi Thomas

There wasn’t, but now there is

Note that I did not use the windows api call, as that is only supported on Windows 8 or higher and FB8 still supports Windows 7 (we will drop windows 7 support in FB9).

Hi Vincent, very nice. Thanks a lot.

Hi Vincent,

i am in the process of using the feature “Canonicalize Path” with more projects. As nice as the feature is, it is rather hard to use for me. I set up about 10 project variables for each project, that represent a path. To canonicalize them, i need to setup 10 actions - one by one for each variable, trying not to forget one of them as i need to check the list of project variables. As a side effect the project file grows about 10 KB.

Any ideas on how to avoid these drawbacks?



Hi Vincent,

a possible solution is to canonicalize the one path variable, which all others depend on and set the macro flag for the others. This reduced the file size by 9 KB (52 downto 43). Execution was a second slower, but that is within tolerance of measurement anyway. Setting up the configuration is also easier. The drawback i see, is the unnecessary variable expansion caused by each access to them.

To better understand my configuration here is an abstract of my variables:

Hi Thomas

I always recommend building up path variables using macro variables. It makes it so much simpler in the long run, change 1 variable and 10 other automatically update.

I’m going to give this some thought, but it might be possible for us to automatically cannonicalize variables… if we know they are paths. Not promising anything, just something for me to investigate.

Hi Vincent,

Thanks for your confirmation on using macros as “best practices”.

Without any expectations a summary of my use cases for variables:

  • Constants
    A default value is assigned and not changed at runtime. For example Scriptname “D:\Tools\Sometool.exe” or Reportname “MyReport.xml”
  • Arguments
    Passed by ContinuaCI, for example “BuildBranch”, usually not modified at runtime
  • Dependencies
    Loaded from a configuration file. Directories (no filename) and paths (directory including a filename), usually not modified at runtime
  • Directories
    Directories derived by other directories (Root is FBPROJECTDIR), usually not modified after initial assignment
  • Values
    Variables, for example holding version information

I group my variables, according to the above use cases. Maybe the group name can be extended to specify properties that affect the usage of properties belonging to that group.

For example:
[X] constant
[X] is path/filename
[X] value retrieved from Continua (arguments)

But maybe it is more flexible to add such properties aside the already known, such as “macro”.

Thanks for the info.

I do want to avoid optionitis - there are already a lot of options on variables - but will give it some thought.

Path/Filename is the only relevant. The others might offer enhancements, such as runtime optimization for constant values.

An algorithm can check, whether a value represents a path/filename, so that even this option is not mandatory. But unless this can be done reliably i’d prefer an option.

Hi Vincent,

with FinalBuilder the following feature got added:
Enhancement - Addded Canonicalize Path option to String variable types.

Thanks a lot!

I noticed, that i have to set the var type to string, rather than the default variant.

Do i also have to check the macro expansion option to use canonicalize?

No, but I’m looking into a UI bug which keeps resetting that option to false. Not sure why it is happening.

I will upload another update shortly.

So it turns out there was 2 similarly named identical functions, one was used, the other not, and I updated the wrong one - no idea why there 2 functions but after updating the correct one (and deleting the unused one) it now works correctly.

Canonicalize will be applied when the variable is reset to it’s default value, or when the variable value is set (either by the Set Variable Action or by scripting). For macro variables, this is applied each time the value is read (which forces a reset to calculate the value).

I load the variables from an INI file. Do i have to take further action?

No, it calls through the same api as the Set Variable action, so it will do the same thing.

New update is on the website now,

I downloaded the file from Thanks Vincent!
Please note, that on the file is not listed yet.

Discourse sometimes takes it’s time updating the Categories view, it’s showing for me now.

Understood. Thanks. It’s showing for me now, too.

I have installed the build. I’ll send feedback to you, as soon as i have run a test.

Hi Vincent,

as promised here is my feedback. First of all: the feature is awesome. I like it a lot. It took me two clicks, that’s all. The log is much more readable now, as i usually download and read the plain log. As a side effect the log size got reduced by more than 10%.

I hit a small bug though. To enable the “[ ] Canonicalize” checkbox, you must not only set the var type to string. You also must close and reopen the variables dialog. This bug got introduced with build 2917.

Other than that i only had to configure my root variable on which all other variables depend on. The change is really small, but the impact is huge.

Hint: As for the project file itself, “canonicalizepath = false” gets added to existing entries. I suppose that’s the way to upgrade the file.


I just tried the reproduce that here and could not. Can you provide the exact steps for this?

That will be gone in the next update, the default is false so no need to write it out to the file.