Canonicalize Path

FinalBuilder Discussion
#1

Hi,

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.

Thomas

#2

Hi Thomas

There wasn’t, but now there is

https://downloads.finalbuilder.com/downloads/finalbuilder/800/FB800_2814.exe

CanonicalizePath
CanonicalizePath558×505 13.6 KB

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).

#3

Hi Vincent, very nice. Thanks a lot.

#4

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?

Thanks!

Thomas

#5

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:
ProjectPath=%FBPROJECTDIR%\…\…
ProjectLibs=%ProjectPath%\Libs

#6

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.

#7

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”.

#8

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.

#9

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.