cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with app.mk using relative path to TouchGFX env folder

Jesper_MCI
Associate II

Hi

I just noticed that when building the Simulator using TouchGFXDesigner 4.24.1 the files
/config/gcc/app.mk
and
/config/msvs/Application.props

are updated with the relative path to the TouchGFX env folder, for instance:

# Location of the TouchGFX Environment
touchgfx_env := ../../../../../TouchGFX/4.24.1/env

If I try to overwrite these paths the files are just overwritten when I run the Simulator from TouchGFX Designer.


This is a problem when working on a project with multiple people that may have the project check out at different folder depths. I don't think the solution is to require that the project is checkout out at the same folder depth for everyone on the same project.
You can argue that it isn't a big problem as TouchGFX Designer updates the path for anyone creating the Simulator.
But it does create 'noise' in the repository.

Any suggestions on how to solve this ?

//Jesper

9 REPLIES 9
Pavel A.
Evangelist III

I don't think the solution is to require that the project is checkout out at the same folder depth for everyone on the same project.

Why? This is called "convention over configuration". What is good for one, is good for all. Everyone uses same settings, everyone is happy.

 'noise' in the repository

Specially to avoid unwanted changes, git has commit hooks. It is a script that can detect forbidden changes and fail pushes to the common repository. Or it can remove offending bits and continue.

 

Thanks for your reply !

I think this is really a TouchGFX Designer issue.
It mixes tool run-time configuration with project specific settings in app.mk.
Since the tool knows the relative path at compile time - why does it need to store it in a configuration file ?

This makes it a tool enforced "requirement" to place the project root folder at a given folder depth.

 

>Why? This is called "convention over configuration". What is good for one, is good for all. Everyone uses same >settings, everyone is happy.

For a project that uses multiple platforms it is not feasible!
And yes, I am ware that TouchGFX Designer is currently only running on windows.

I am not convinced this is an example of "convention over configuration".

( in general I feel pretty sure I agree with you. Limit the number of concerns a developer is forced to face. )

What is the convention and what is the configuration in this case ?

Basically TouchGFX Designer writes a configuration to the project files that needs to be under version control.
It does this regardless of what convention you adopt.

As long as everyone keeps the relative path the same everything is good.
But this becomes a requirement, a configuration. That needs to be documented so new users can get up and running.
It can -never- be considered a convention; because then it would not have to be documented!
Unless the convention is that everyone using TouchGFX Designer should always place their project source files at a specific relative path to the install folder of TouchGFX Designer.
Good luck selling that one.

I think I may just have argued that it is TouchGFX Designer that should adhere to the paradigm "convention over configuration" ?

> Specially to avoid unwanted changes, git has commit hooks. It is a script that can detect forbidden changes and fail pushes to the common repository. Or it can remove offending bits and continue.

Urgh.. sounds like a configuration to me :)
In this case I would want "git status" to ignore changes to specific lines in specific files.
I think I'd rather take the repository 'noise' any day .. with TouchGFX there is a lot of 'noise' from the generated files anyway.

I may have missed it somewhere - but it is not easy to know which files TouchGFX is updating outside of the generated folder and which lines are user configurable.
I find that I am spending an increasing time struggling with the development tools ( and understanding what they do ) and thus less time coding..

ferro
Senior III

Hi @Jesper_MCI 

Few times this crossed my mind as well. I've just looked into it and it seems scripts responsible for updates are here:

c:\TouchGFX\4.24.1\env\MinGW\msys\1.0\Ruby30-x64\lib\ruby\gems\3.0.0\gems\touchgfx-cli-4.24.1\lib\touchgfx\generators\

When you search for 'touchgfx_env'. I wonder if these could be adapted to your needs.

ferro
Senior III

"This is a problem when working on a project with multiple people that may have the project check out at different folder depths."

Not sure if I understand your setup. This path wil be changed based on current folder depth. I work with the same propject in different depth without any problem.

GaetanGodart
ST Employee

Hello @Jesper_MCI ,

 

To be clear, the issue is that multiple people work on the same project from different environment, therefore, the relative path is different and you use a shared git so whenever you commit, the path change is part of the changes?

 

Regards,

Gaetan Godart
Software engineer at ST (TouchGFX)

>Not sure if I understand your setup. This path wil be changed based on current folder depth. I work with the same propject in different depth without any problem.

 

Are you checking in the two files every time or have you added precautions so that it only happens on absolutely necessary changes ?


I discovered this as someone else checked in and while reviewing the changes it occurred to me that the other person must have a different relative path to the TouchGFX folder.
That caused changes to the two files I mentioned. And I had to investigate into it.


You can argue it is not a (big) problem.
As I mentioned in my reply it seems that TouchGFX Designer will update the path in the files whenever you ask it to create the assets / build the simulator.

Not a big deal as it will not pose a problem to a developer.

But it does add 'noise' to a Pull Request as git will detect that the file has an update.
You cannot add the file to .gitignore since it holds project relevant details that -may- change over the course of the project.

Yes basically.

Multiple people are working on the project with different relative paths to the TouchGFX env folder.

If they open TouchGFX Designer and generate assets or build the simulator TouchGFX Designer will make changes to ( at least ) two files.

And thus when committing to git these changes will have to be considered.

Initially I thought it was an issue. So I thought I'd ask for some help/guidance in here as I was not sure how we should handle it.

But since then I arrived at the conclusion that the particular setting is only used by TouchGFX Designer ( that conclusion may be wrong, I honestly don't know ). And I am willing to just ignore those changes - as in if they turn up in a pull request code review it's all good..

>"But it does add 'noise' to a Pull Request as git will detect that the file has an update."
Yes, I understand your point. I observed there is more places where CubeIDE, CubeMX and GfxDesigner share files which are changed by each tool and generators are not compatible e.g. one tool uses spaces for indentation and other tool uses tabs - 'noise'. It is difficult to maintain these incompatibilities by ST (any) dev team, I've seem much worse.

Interesting what Pavel mentioned "to avoid unwanted changes, git has commit hooks". Did not know about this option. Seems obvious - many people ran into the same problem as this one and Git must have feature for that. I am a novice in Git.

 

"Are you checking in the two files every time or have you added precautions so that it only happens on absolutely necessary changes ?"

Sorry I missed that question. Sometimes I rememer to not commit it, sometimes i dont. It is only me who works on the project therefore different scenario to yours. You learn over time what is 'noise'' and can be ignore. On the project I share with other people there is alway a bit of uncertainty when merging e.g. CubeMX project.