${project_loc} in DCT will not work

[padawan]

Hi,

I have written 2 cmd files. The first renames the main.cpp to main.c before the code generation runs. and the second renames main.c back to main.cpp afterwards. The files are in the project path. The plan was to access them with ${project_loc}\CppToC.cmd.
But this does not work.
Is there a solution?

Padawan

[TDK]

STM32CubeMX isn't going to support Eclipse variable expansion. Use an absolute path, or figure out where it wants those files and use a relative path.

[padawan]

Hi TDK

i don't want an absolute path, becouse if you  copy the  Project or open it on an other PC the path will not fit.

i tried to take the file only, but this is not working. Can we tell/beg STM to support the Eclipse vars in the DCT?

Padawan    

[TDK]

So use a relative path, perhaps just the file name. It's probably looking in the same directory as the IOC file.

CubeMX is a standalone product. Probably isn't a good way to support eclipse variable integration.

[padawan]

Hi TDK

thanks, but the files are in the same directory as the .ico file. Relativ path works only if you know where you are :)

I do not know at which path the STMcube starts, and if its the same on all systems. Or it is realtive to the STM-inst.

If i choose a file in the dialog, Stm expands it with the absolute path.

Is there anywhere a "wishlist" for STMCube project?

padawan

[Pavel A.]

${project_loc} works only in Eclipse builder context. It looks like CubeIDE does not populate these variables when generating code. 

> Is there anywhere a "wishlist" for STMCube project?

+1  A good idea, IMHO easy to do.  @mattias norlander  ?

At least, ensure that by default pre/post generation scripts run with current dir = project dir; then the variable expansion that the OP wants is just not needed.

[TDK]

Doesn't help you much, but CubeMX runs these before/after build scripts from this directory:

C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeMX

So your scripts would need to live in there.

[mattias norlander]

Hi Pavel and all,

Thanks for pinging me on this. 
I normally live more in the "IDE world" than the "MX world", hence I had to invest some time to play with this feature...
Apparently MX does not treat relative paths, only absolute paths. For me this is not good practice. 
I created a bug report and will try to ensure that MX uses the project root as the "current working directory".
With such bug fix, it should be possible to just specify the user action "my_script.sh". No need for $(project_loc).

Internal ST ticket number for reference: 164200

Exposing the environmental variables like $(project_loc) is unfortunately more costly than it might seem...
I will explain below (going completely off-topic) and at the end raise a far larger question... I would be very interested to hear feedback.

The integration of CubeMX inside CubeIDE is a challenging topic... The CubeMX editor inside CubeIDE may look like just another "editor". But in fact it is almost the full stand-alone CubeMX application integrated inside CubeIDE. Two tools written in different Java frameworks. There is a bridge(API) between the two frameworks, but it is quite limited. As a result, the MX tool is not at all aware of the environmental variable context of the IDE. This is why I suggested another bug fix...

Extending the bridge could be possible, but not necessarily cheap since we need to do modify the IDE, the bridge and MX.

In my "dream world", the two tools would not be integrated inside each other.
Let CubeMX and CubeIDE be two separate stand-alone applications only. Just let CubeMX generate files for CubeIDE, like for 3rd party IDEs.
If the tool could live just as stand-alone tools we would have some benefits:

• A bug inside CubeMX/CubeFW would not trigger forced re-releases of CubeIDE due to integration work
• The user could choose to update or freeze tools individually
• A bug inside one tool does not impact the other tool
• Integrating CubeMX inside CubeIDE --> CubeIDE becomes heavy and some stability issues is most likely related to this setup
• IDE and MX may target different phases of the project. CubeMX features are used intensively in the beginning (POC phase), then to a less extent or not all.
• Later in the project, many (most?) customers create their own makefile/cmake project, not managed by MX, to have full flexibility/control. This offer tool/code freeze and having one project targetting multiple MCUs. 

Then again the benefit of the integration today is:

• Customer only has to download one tool
• Customer can stay inside one tool without having to-do ALT+TAB

Would be really interesting to see which approach you prefer: integrated vs stand-alone approach, given the above information/benefits of the different approaches?!
Or maybe your preferred "approach" is based on a completely different factors?!

Please feel free to share your view!

[Bob S]

Jumping in here, +1 (really +100) for "separate, stand-alone".  Accessing CubeMX inside the IDE buys me nothing except (for me) longer startup time for MX.  And raises the possibliity of DIFFERENT CubeMX versions in the IDE and standalone (haven't I seen IDE's with alpha/beta releases of CubeMX in them?)  Just run MX when you need it, and the IDE when you need it.

[TDK]

@mattias norlander You've nailed all the drawbacks of the current scheme.

I almost exclusively use CubeMX in standalone mode, even for STM32CubeIDE projects. It's just so clunky and slow inside of CubeIDE.

Development time that would be spent on integrating them would be better spent on making each of them better, individually, IMO.