allow settings paths through env

[robamu]

Builds on #187 , documentation extended.

closes #187

[atsju]

Looks good to me. Could almost be merged as is .

[atsju]

Maybe we could add the variables names (or an example of variable name) here ?

[robamu]

I think this is a good idea. maybe even a concrete example for a file which can be sourced to load all necessary env variables at once (I find this really convenient compared to very large CMake commands, and the path stays clean if it is not used)

[atsju]

As of commit 08ceb4b it seems already excellent to me. It's better than what I expected. I will review When you remove WIP.

Please note also there are also Windows users like me, so keep generic (even if we can consider Linux as default choice)

[robamu]

I actually used .sh scripts on Windows with git bash or MinGW64. I am not totally sure whether this belongs in the README, but a regular CMake workflow generally involves more scripting and I found scripts like that to set up environments quickly extremely useful. I added this for the powershell on Windows as well, but I need to test this. I read somewhere that it would not be possible with powershell like that

[atsju]

The .sh only is OK don't worry. I just wanted to heads up. Your work is great.

[atsju]

No worry I just test some Github features :)

[robamu]

Okay, all okay now

[atsju]

@Hish15 Please review. To met this is 🥇
Plus it's super helpful. Now I can set the path to cubes and easily run tests on branches without additional script or cmakelist modification

[Hish15]

Hi all,

I understand the need covered by this feature, but isn't this what cmake toolchain files are meant?
My second concern is that defining things in ENV bring the risk of using unwanted configuration (from a previous project for instance)

I am not against the feature, but needed to open the discussion to be sure we are headed where we want.

[atsju]

Hi all,

I understand the need covered by this feature, but isn't this what cmake toolchain files are meant?
My second concern is that defining things in ENV bring the risk of using unwanted configuration (from a previous project for instance)

I am not against the feature, but needed to open the discussion to be sure we are headed where we want.

Fair point. I would argue this way:

• Toolchain file are more for configuring toolchain here we are just giving path to code (And only if not already set by project)
• This is an additional feature and users can still choose to configure via toolchain files or -D or cache or set in cmakelist (this is what I would recommend in production + HAL as submodule)
• Only paths are set, no configuration. So the risk is limited.

As I see benefits with limited risks of regression and user errors I would recommend integrating it.