STM32CueMX generated project in version control

[danieloneill9]

Posted on April 29, 2014 at 12:14

Hi All,

I have generated a project using the STM32CubeMX tool for IAR Embedded Workbench. It is working great and I'm using TortiseHg and BitBucket for version control. This was working great until someone else (my boss) cloned the project to his machine. He could open it but it complained that some files were wrong. When he tried to build the project the compiler couldn't find ''stm32f4xx.h'' or '' ''(I can't remember which) to include. This seems like some sort of path issue. If I copy the project somewhere else on my computer it still compiles fine. Has anyone seen this before? Is there some computer dependant location for the CMSIS files in the project generated by STM32CubeMX? Cheers, Daniel

[frankmeyer9]

Posted on April 29, 2014 at 12:44 This is not a problem of STM32CubeMX or Mercurial (or any other version control system, for that matter), but an issue with inadequate project setup. It is very common that different people/developers are placing the projects on different paths on their machines. If you want account for that, you MUST create the project in a path-independant manner. Don't define any absolute path, neither for sources, nor for include directories or libs. Use environment variables instead, most toolchains support this on GUI level (even a make file can do this). Otherwise, the 'competing' developers will destroy each others project setting when checking in/committing their project setting.

[waclawek.jan]

Posted on April 29, 2014 at 12:55

Not only that.

Cube places some of its files into the ''standard'' Windows directories, which tend to change with Windows version, localisation, and maybe a couple of other things too JW

[frankmeyer9]

Posted on April 29, 2014 at 13:07

To be honest, I don't have Cube installed, no do I plan to do so. Having several non-commercial Std_Periph_Lib based projects, I see no reason to change this.

And secondly, I use Linux as host platform, avoiding this Windows-related trouble. BTW, another Windows-related observation. I once tried to create projects below the C:\Windows folder (suggested as default by the IDE). This turned out to be a really bad idea, with all sorts of spurious build errors. This folder has special treatment, with restricted rights to avoid easy installation thrashing.

[waclawek.jan]

Posted on April 29, 2014 at 13:19

> To be honest, I don't have Cube installed, no do I plan to do so. Having several

> non-commercial Std_Periph_Lib based projects, I see no reason to change this. I did so because I was curious. Yes, there's absolutely no merit in it, IMO; but I am of the same opinion of the ''Standard Library''. > And secondly, I use Linux as host platform, avoiding this Windows-related trouble. Sorry for the flaming OT, but this is SO NOT TRUE. Throughout the years, I have been constatnly fighting with various *ux distributions having different directory structure and surprising behaviour resulting from rights assigned to them. In any nontrivial files distribution and access right system, a nontrivial application can and will get things wrong. JW

[frankmeyer9]

Posted on April 29, 2014 at 14:42

Sorry for the flaming OT, but this is SO NOT TRUE. Throughout the years, I have been constatnly fighting with various *ux distributions having different directory structure and surprising behaviour resulting from rights assigned to them. In any nontrivial files distribution and access right system, a nontrivial application can and will get things wrong.

Perhaps I'm too old/experienced to feel 'offended'... But you are correct in some way. As long as you stay inside a 'group' of similiar linux distributions, it is less of a problem. But a few years ago I migrated from Suse to Mint Linux, which was a REAL PITA. Not sure why installation paths, configuration files, startup process, package formats, etc. really need to be different ..I did so because I was curious. Yes, there's absolutely no merit in it, IMO; but I am of the same opinion of the ''Standard Library''. I used the Standard Library mainly when it came with the examples, and where I did not need dig deeper. And I didn't bother where I required maximal performance. A well written library is of merit when you develop code for a platform, and not bound by minimized hardware costs. Those points do often not apply...

[stm32cube-t]

Posted on June 09, 2014 at 17:14

Hello,

I retrieved a project posted on the forum and could compile it ok from my PC. Make sure that in STM32CubeMX under the project settings options (Project Menu, Code Generator tab), you have selected the copy of the library files and not only the reference to them. Let us know if you still encounter the issue. Thanks.