I'm using Eclipse CDT for a C project.
I found out most of the frameworks require installation to use.
I need one framework that doesn't require installation and just need to include the
.h files or/and .c files so that I can use the framework anywhere.
The MinUnit is very cool but it's tool simple. I can use the MinUnit If there's a plugin like Junit to generate the test function stubs for me.
Is there any Eclipse CDT plugin to generate test function stubs like Junit did?
Thank you!
What about CUnit? When I used it - I just added the files as a sub-project to my development tree.
Related
I was testing and creating FMUs with the tool FMU SDK provided by Qtronic. It works fine by running the script build-fmu, but I would like to work in Eclipse, so I can build everything from there.
So I created a new project and copied all the headers libraries that i thought would be needed, but at the end it does show a lot of undeclared functions, is there a especial way to export the files to eclipse environment?
If the goal is to export FMI 2.0 for co-simulation, you could give https://github.com/Vico-platform/fmu4cpp a try, provided that you can use cmake with eclipse.
I have an Eclipse project that is currently a monolithic one. That is, it contains all of the C source/includes and build an executable. This project is comprised of a GIT module and several submodules. I would like to refactor this Eclipse PROJECT so that it contains the executable project and projects for the submodules as static libraries.
I'm pretty sure that I can do this if I was creating this from scratch. However, I can't seem to figure out how to do this by modifying the existing project.
Any ideas on how to accomplish this?
I've got a managed Eclipse project that uses the GNU ARM Embedded Toolchain to compile for an ST microcontroller. What I want to do now is, unit test the code in that project. The framework I want to use for unit testing is Google Test.
I tried creating a second Eclipse project for the unit tests, that uses the standard GNU toolchain. Like this:
Project1 (ARM)
|---src
Project2 (Desktop)
|---test
The problem with that is twofold:
The second project doesn't have access to the source code of the first project (obviously). Therefore I tried creating a static library from the first project for testing purposes, which leads to the second problem.
The Library created from the first project isn't compatible with the second project, because it uses the GNU ARM embedded toolchain instead of the standard GNU toolchain.
To solve the second problem I added a build configuration to the first project to try and compile it with the right toolchain. That didn't work out though.
Another path I went was to have the unit tests in the same project as the actual code and use a build configuration to create an executable for unit testing. Something like this:
Project
|---src
|---test
That didn't work out as well and it kind of seems like it's the same problem as with the first approach anyway.
The problem isn't unit testing in itself. I know how to use Google Test for testing regular C projects in eclipse.
How is unit testing an embedded project usually approached with managed projects in eclipse? Is it possible at all? If so, is it a good way to do it or should I write my own makefile to accompilsh this task?
To do that using eclipse auto generated makefiles, you have to create a Build Configuration for each build (one for target and one for the desktop), accordingly:
Project1, will have to be built as a static library for both platforms. It will contain your application in a platform independent manner.
Project2 will have to be build only for Desktop, it will have tests and tests main, also will link to Project1 library.
A Project3 (with main and platform dependent code) will have to be created and build a an elf or bin, linking to Project1 library for target platform.
It can get more complicated if you decide to run tests on target platform as well;
I have two examples/templates where you can get based, but they are not related to eclipse:
Build with Makefiles with msp430 toolchain, CppUTest as test framework.
https://github.com/felipe-lavratti/UnitTestingEmbeddedC-Demo1
Build using Scons, tests are run in both platforms, dependencies and CppUTest as unit testing framework.
https://github.com/felipe-lavratti/UnitTestYoutubeVideos
I am moving from Netbeans to Eclipse (on Ubuntu 12.0.4). I have a C application that consists of several sub projects which are libraries (shared and static), as well as stand alone executables.
I can't figure out how to create a 'parent' project foo, which contains component projects
foobar
foofoo
barfoo
barbar
Ideally, I want all the 'component projects' to be created under the folder foo, so that I have a directory structure like this:
/path/to/foo/foobar/ (contains foobar project files)
/path/to/foo/foofoo/ (contains foofoo project files)
/path/to/foo/barfoo/ (contains barfoo project files)
/path/to/foo/barbar/ (contains barbar project files)
Does anyone know how I can achieve this structure using Eclipse as IDE (with CDT)?
Last but not the least, I intend to create my C modules using the Autotools option. Will the generated files for Autotools be automatically updated as I add new header/source to a module - or do I need to manually maintain the Autotool files?
Friend,
I think there is no the "parent" C project. You can create a normal C project in IDE and add all dependencies into sub-folders. Then tell compiler your build procedure via Makefile. I think it's easy way as you have had experience on C application.
About autotools, once you update/add/remove your project file, I think you need to modify your Makefile to reflect your change and do clean and rebuild your project.
For other C build tools, you can use buildroot if you'd like.
The best way I can think to do this in eclipse is to create a separate workspace for the project e.g. foo, and then add the sub-projects (foobar, foofoo, etc...) as projects. This is generally a better approach to take with eclipse, instead of a single monolithic workspace. I don't know what the specific dependency structure for the sub-projects looks like, but you should be able to express it simply by using eclipse project properties. This can include a rollup executable sub-project that depends on the libraries.
Unfortunately, I'm not sure if eclipse cdt will maintain autotools files. However if not, it should be relatively easy to integrate and use some of the autotools binaries such as autoscan, and autoheader into the eclipse build commands.
At first you need to a working directory, Then you should new project, Then per file or per class (according to C++ or C ) append your files, it's much safe way. another way is not clean, i have experience. don't use them.
I am attempting to use QtCreator as an IDE for a straight C project. The reason is that I am comfortable with QtCreator and I want a visual IDE for stepping through this new project I am working on. My development box and my deployment box are different, but both of those have gmake on them. QtCreator requires cmake, which I dont mind putting on my development box, but my deployment box is not going to have cmake.
Am I OK to build my software on the Qt box, and be sure it will deploy on the deployment box?
Edit: to be clear, the existing code base already has a makefile structure going, and I'd rather not interrupt that. If I can set my project up to use those existing targets and such it would be great.
If your project is using CMake as build system, then you should have it installed on the machine you are building. You can't pregenerate Makefile's and then just run make on the other box.
Well, you actually can, but then you will probably need same compiler versions, libs/headers located in same paths and etc. So generally it's not good idea.
As for deploying already compiled binaries - it have no relation to CMake. The general rule there is that you should have same shared libraries on both machines. Linking your project statically allows deploying single fat executable/library, without any additional dependencies.