support converting relative paths in environment variables to absolut…

[yuanxingyang]

In some cross-compilation scenarios, the cross-compiler relies on custom environment variables to specify the path of the compiler. e.g. QNX_HOST and QNX_TARGET

[jkloetzke]

This change is actually not required. The absolute path of a tool is available in the BOB_TOOL_PATHS associative array. Suppose you have defined your QNX SDK in a recipe:

...
provideTools:
    qnx:
        path: "host/linux/x86"
        environment:
            QNX_TARGET: "../../../target/qnx6"

Then you can derive the paths in your using recipe like the following:

buildTools: [qnx]
buildVars: [QNX_TARGET]
buildScript: |
    export QNX_HOST="${BOB_TOOL_PATHS[qnx]}"
    export QNX_TARGET="$QNX_HOST/$QNX_TARGET"
    ...

Of course this can be factored out into a class. Does this solve your problem?

This PR itself is not something that I would like to merge because it implies that environment variables of tools that look like paths are treated as such. This will certainly break existing projects.

[jkloetzke]

Thanks for your efforts but I'm closing this PR because this approach will most likely break existing projects. Please open issue if the proposed solution above does not work for you. Thanks.

[yuanxingyang]

thank you for your reply I want to further confirm, according to the method you mentioned above, does every recipe using the SDK in a large project need to manually add this environment variable setting?

[jkloetzke]

I don't think you will have to manually add this to all recipes. Such functionality should be placed in a class and all recipes that build C/C++ code inherit this class.

In practice, if you start a new project, I would recommend to use https://github.com/BobBuildTool/basement as underlying project framework. There are classes for every major build system, e.g, cmake. They all inherit from the cpackage class which would be the only one that needs to be adapted. This particular class already covers support for Visual Studio toolchains so adding QNX there makes perfectly sense.

[yuanxingyang]

Thank you for your reply, but I have some ideas

1. if bob supports high cohesion and low coupling programing would be better.
2. In real-world projects, such as those running on the Qualcomm platform with QNX+Linux systems, there's a module called fdbus. It needs to be deployed on both QNX and Linux systems simultaneously. Therefore, I need to compile two versions of fdbus using the QCC compiler and ARM compiler. According to the approach you mentioned, I would need to write two versions of the CMake class: one for QNX SDP to be used with QCC and another for the ARM compiler. However, if these environment variables could be encapsulated into the classes for QNX SDP and ARM SDP respectively, it would streamline the process. Although it's still possible to achieve the decision of whether to export relevant environment variables in one CMake through other variables, wouldn't it be better if each one class handled its specific responsibilities?

[jkloetzke]

I think you misunderstood. I was advocating to enable the cpackage class to additionally cope with QNX. If you look at the cpackage class you can see that it can handle Visual Studio toolchains. Adding QNX support doesn't hurt. Then the class will work for Linux, Windows and QNX toolchains. The cmake class just relies on the cpackage class and will work with any of the toolchains.

Practically, all that is probably needed is the following in the cpackage class:

if [[ ${QNX_TARGET:+true} ]] ; then
    export QNX_HOST="${BOB_TOOL_PATHS[qnx]}"
    export QNX_TARGET="$QNX_HOST/$QNX_TARGET"
fi

If you've set the QNX toolchain, the class will set the variables. If you have another toolchain, the if condition won't be met and the QNX setup will be skipped.

And Bob was precisely made to have both in the same project. Please have look at the https://github.com/BobBuildTool/bob-example-embedded project and libecho in particular. This library is compiled for FreeRTOS and for Linux. The way how this is achieved is that there is a generic target-toolchain tool. Depending on the position in the dependency graph, it's either the Linux toolchain or the bare metal toolchain. The recipe (and its classes for the matter) do not care which toolchain it is exactly. And Bob will take care of building the recipe twice, each time with the respective toolchain. HTH

[yuanxingyang]

Thank you for your support!,I will try above solution.