Replace round brackets in the "variants" folder

[valeros]

Hi there,

Is your feature request/improvement related to a problem? Please describe.

In the latest core v2.0 the "variants" folder was refactored and grouped in sub-folders per series. Now, some internal variant folders might be common for several boards and contain round brackets () in their names (e.g. F042C(4-6)(T-U)). Even though such brackets are valid symbols and can be used for naming files and directories, Unix systems require such symbols to be quoted or escaped. With the Arduino IDE it works just fine as you simply quoted that paths in your platform.txt, but in case with PlatformIO it generates some considerable inconvenience as we need to properly handle such paths internally for many external tools like other editors (some IDEs need escaped symbols, other expect a raw path), static analysis tools, remote development, etc.

Describe the solution you'd like
Although we understand that this matter should have been discussed early on the stage of development, it would be great to switch to something more regular for variant grouping, for example the most generic and OS-neutral alternatives are underscore _ and hyphen -.

Thanks in advance.

[fpistm]

Hi @valeros,
this notation was kept to be inline with the [STM32_open_pin_data(]https://github.com/STMicroelectronics/STM32_open_pin_data/tree/master/mcu) mcu file name.
It have been discussed a lot and tests as you stated it works with Arduino IDE (1.8.x and 2.0.0 Beta) but also with VScode for debugging.
Usage of parenthesis is more readable for name factorization: F042C(4-6)(T-U) vs F042C_4-6_T-U
And factorization are required to avoid long name path issue.
Hyphen is already used.
So I really don't want change that.

And IIWR you was aware about that as I've ping you about that and the PIO ci ?

I moved it as a GH discussion, This will allow to discuss this point.

[fpistm]

Why not change the path in the PIO integration of the STM32 core package?
Anyway I'd guess dealing properly parenthesis in PIO would avoid further issue.

[valeros]

Usually, we strive to preserve the same workflow/structure as much as possible. Renaming/fixing variant paths will introduce another bewilderment to the end developers. As I already mentioned, PlatformIO is agnostic to any backend, so it seems as the wrong layer to fix the problem taking into account the fact that this behavior can be easily fixed in the framework itself.

[fpistm]

That make sense to preserve the same workflow/structure.
Anyway I'm not agree that is a problem of the framework itself. Having '()' in the path is more and more common.
I saw several user with this in their username or simply using the Program Files (x86) in the path.
I managed several script and '()' are properly managed. For python you should use PathLib instead of os.path to better handle that and also raw string.

[valeros]

There are plenty of hacky sub-optimal ways to overcome the issue, but why put walls up and further complicate this behavior if this can be easily fixed in the framework? Anyway, I see that you feel reluctant to make the integration easier, so feel free to close this issue/discussion.

[fpistm]

@valeros

There are plenty of hacky sub-optimal ways to overcome the issue, but why put walls up and further complicate this behavior if this can be easily fixed in the framework?

Here is the point we are not agree. First it is not a bug. So it does not require a fix in the framework while PIO should be able to deal with this so it is more a pio "issue". Changing the framework will simply hide this issue and I guess later it will come back with another FW or host OS integration with path. I know it is not so easy to fix this here or in PIO due to the number of scripts. But honestly, I really think you should properly handle that to avoid further issue. Maybe @ivankravets and you have a different mind.

Anyway, I see that you feel reluctant to make the integration easier, so feel free to close this issue/discussion.
I'm always open to discussion if you have any solution I'm ok but at this time I have no one.

[ivankravets]

Having '()' in the path is more and more common.

Hi @fpistm ,

Are you a Windows user? ( and ) are parts of Bash syntax on Unix and can be used to inject Bash code directly into the string. For example, $(echo 'STM').

Paths on UNIX are not escaped by default because they are not static strings as you have them on Windows. See a few examples for a proof http://www.compciv.org/topics/bash/variables-and-substitution/

@valeros added a workaround on our side. Nevertheless, if other projects would like to use the source code of this Arduino core, they must provide the same escaping to make it working on Unix.

I saw several user with this in their username or simply using the Program Files (x86) in the path

Because this is Windows.

[fpistm]

Hi @ivankravets
I used Windows and Linux. I'm aware of this anyway it is possible to deal with.

@valeros added a workaround on our side. Nevertheless, if other projects would like to use the source code of this Arduino core, they must provide the same escaping to make it working on Unix.

Fine, anyway this should not be a workaround but a safe way to manage all possible value.
About other projects, as said, it is safe to be able to handle all the possible case.

I saw several user with this in their username or simply using the Program Files (x86) in the path

Because this is Windows.

Right for those examples but already saw same issue on Linux/Mac. 😉

[ivankravets]

We don't quote PATHs by default to avoid issues with IDE integrations. We export compiler data into the multiple file formats depending on the IDE. Extra escaping can lead to unpredictable issues, such as

{
  "includes": [
    "\"buggy (windows folder)\""
  ]
}

So, I think @valeros can close this issue. If someone reports any issue related to STM32 + Arduino + PlatformIO, we will restart this conversation.

P.S: I highly recommend following https://en.wikipedia.org/wiki/KISS_principle to avoid similar issues.

Have a great day! 😊