I'm trying to work with relative folder paths within FinalBuilder project and Continua. For example I have a project that I want to execute from Continua or if the users don't have continua, can execute from FinalBuilder. Here is the structure of the Repository that contains the final builder project.
Source Code Repository Structure
\src\Sample1\*.sln
\src\Sample2\*.sln
\db\*.sql
\buildrunners\*.fbp7
If I want to build all the Visual Studio *.sln within the repository from final builder I can use the FileIterator and a "..\..src\*.sln" search and if finds all the solutions. However I can't pass that value into the Visual Studio Action as it will assume it's relative to the devenv.com.
So I get compile errors like
Solution ..\..\Samples\Android\cs\SimpleApp\SimpleApp.slnRunning C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.com with parameters : /build "Debug|Any CPU" "..\..\Samples\Android\cs\SimpleApp\SimpleApp.sln"
How can I convert relative path "parents" to actual folders, so these final builder 7 projects can be run anywhere a person downloads the repository file on a PC?
So my recommendation here create a FinalBuilder Project variable : ROOTPATH - set it’s default value to a path that will work when FB is run stand alone, e.g %FBPROJECTDIR%
In continua, on the FinalBuilder Action, set ROOTPATH=$WORKSPACE$
Posted By Vincent Parrett on 18 Apr 2013 02:08 AM FinalBuilder does not support relative paths, you must anchor all paths to a folder.
Vincent, I accept that FB should use full paths for all the various actions. It definitely the safe approach. However, this is one of the things that nagged my about finalbuilder projects and a believe a significant functional UX improvement for your excellent software.
In IMHO there seems to be a few options to resolve the relative paths, by simply calling API's which do support that logic. Hence Actions like file iterators could resolve relative paths to anchored paths. When I think back to how I was doing things in FB Server 7 days, I often had to setup my build server with the exact same folder structure as final builder for projects to execute consistently (or use project variables, as your post suggests).
Basically what I'm trying to point out, is FinalBuilder would benefit from a new action (or modify some of the existing actions) to call windows API's that support relative paths. Vsoft customers could then use FinalBuilder or Continua + FinalBuilder software and execute projects without having to manually change variables or pass root paths in/out of the project from Continua. This seems to be even more critical, when FinalBuilder projects are included in repositories.
The difficulty is that microsoft does not document which win32 api functions support relative paths (FinalBuilder is an unmanaged application) and most that we use do not. If you leave it to the api to resolve the relative path, it will do that to the current directory for the application, which is not very useful in a multithreaded application and probably not what you intended anyway.
The problem is that in different actions, users will have different expectations of how relative paths should work. For example, on the VS.NET action, if I set the OutputPath property to a relative path, is that relative to the solution, the finalbuilder project or the current directory? If I set the Solution property to a relative path, what is that relative to?? The potential for confusion (and thus support load) there is immense.
We have looked at adding relative path support many times over the years and have yet to come up with a satisfactory, consistent and obvious (to the user) solution. FWIWI, most windows api’s do support anchored relative paths, which is why your fileset example above works.