Why does new GIT repository have no TrueSTUDIO settings?

[Rstua.1]

I have made a new GIT repository of an existing TrueSTUDIO project. But this message is show when opening the project in TrueSTUDIO:

" No target settings could be found for this project For proper operation of TrueSTUDIO these settings must be set. "

Further, the project does not compile as all of the library paths have been deleted.

-thanks

[Ozone]

Probably because TrueStudio is discontinued after ST acquired Atollic ?

The new CubeIDE is the successor, and should be able to import TrueStudio projects/workspaces.

I don't use any of them, though.

[Rstua.1]

Thanks for your response @Ozone​ .

I think this is a disadvantage of using Eclipse.

(I assume that Atollic's TrueSTUDIO is a derivative of Eclipse.)

I have found that an instance of Atollic / TrueSTUDIO is storing mission critical (for example, library paths) configurations / data in a directory common to all projects that instance of Atollic / TrueSTUDIOthat is working on. This puts this mission critical data out of (normal) reach of Source Code Control tools like GIT, SVN and ClearCase. I am now looking for 2 things now:

1) The "recipe" for copying ALL the missing configuration information from one Atollic TrueSTUDIO project to another. I have found the Exporting / Importing menus. But this appears very piecemeal and error prone. There must be over a dozen selections each apparently requireing the user to create and track individal export / import files!

2) A way to FIX this problem permanently! Eclipse has been around for years. And so has Source Code Control. It follows others have found a way to store mission critical project information (used by the IDE) in the same directory as the source code. Otherwise, Eclipse projects pulled from, say, a GIT repository might actually be broken unable to find libraries just because the include path information was not stored along with the source code in the GIT repository.

-thanks

[Bob S]

Disclaimer: I have not ever used TrueSTUDIO nor the ST IDE derived from TrueSTUDIO.

But, I've gotten this to work using SystemWorkbench. We use build servers that pull from GIT repositories, and the GIT repository is at the "project" directory level, not the "workspace" level. For example:

 [edit to place directory structure in code block so indentation works]

C:\workspace
    -> .metadata (this is NOT included in the GIT repository)
    -> Project
        -> .git
        -> Drivers
        -> Inc
        -> Src
 

At least with SystemWorkbench, the compiler include directories, linker libraries, flags, etc. are all stored in the ".cproject" file in the project directory. There is also a ".project" and ".mxproject" (if you used CubeMX to generate code). So those files get included in the git repository. I did have to change some settings to get Eclipse to store the launch configurations in files in the project directory instead of in the ,metadata directory. The process is described here:

http://eclipsesnippets.blogspot.com/2007/07/tip-creating-and-sharing-launch.html

[Pavel A.]

When you check an Atollic project into version control, be sure to include .settings/com.atollic.truestudio.debug.hardware_device.prefs

> I think this is a disadvantage of using Eclipse.

Eclipse CDT is free, opensource software. If you think something is missing or can be improved, you're welcome to send a bug report or contribute.

If something good exists in upstream but unavailable or broken in CubeIDE, this can be discussed here.

-- pa

[Ozone]

> (I assume that Atollic's TrueSTUDIO is a derivative of Eclipse.)

Yes and no. Eclipse is the GUI, sans the toolchain (preprocessor, compiler, linker, bintools).

TrueStudio and CubeIDE use Eclipse, as many others do.

> I have found that an instance of Atollic / TrueSTUDIO is storing mission critical (for example, library paths) configurations / data in a directory common to all projects that instance of Atollic / TrueSTUDIOthat is working on.

Yes, but other IDEs do do as well. They bury/hide project meta information in opaque project files of proprietary format (usually some form of XML).

You can put that project files under source control as well, but need to live with trivial (non-source related) change causing updates.

Eclipse, and most of IDEs derived from it, support make-file based projects. Those would be optimal for source control.

I deal with firmware supporting multiple platforms (different 16732-bit architectures) requiring different toolchains. Some of them are Eclipse.

One might rest assured that mentioned Eclipse features are a royal pain in the b_u_t_t in such circumstances.