| Multiple CDT embedded targets [message #1853452] |
Sat, 02 July 2022 13:35  |
Eclipse User |
|
|
|
What is missing from eclipse is the ability to create a pure C source code library that can be reused and reasonably imported into an EMBEDDED CDT package used by various CHIP venders
Take this as an example to try:
Create your own replacement implementation of the standard "string.h" library - its an example for this discussion.
I want to be able to create a library package that I can give to somebody and they cause within their already existing project.
The project would have for example these 3 things:
a) one "common src" directory
b) An optional series of target specific directories
* For example an optimization library for Arm CORTEX-M series
* Another for the ESP-32 series of chips
* Another for Xilinx Micr[/ALIGN]oBlaze
* etc.[/ALIGN]
c) One "common include directory"
d) Maybe a target-specific include directories
e) This should be buildable in either a DEBUG or RELEASE configuration
in effect as a standalone library for maintenance operations and maintenance builds, and test builds
f) When Imported into other tools - like Xilinx or STM - it should come in as a standalone project within the workspace, and automatically add the selected INC dirs to your APPLICATION project, and add the LIBRARY name to the list of libraries linked to your project
G) The ability to remove the library from the project
Right now, (E) and (F) and (G) is not possible and that makes it painful, very painful to use Eclipse CDT
|
|
|
|
| Re: Multiple CDT embedded targets [message #1853485 is a reply to message #1853479] |
Mon, 04 July 2022 11:37  |
| Eclipse User |
|
|
|
That's not even close to usable.
I could go through a provide a list of "requirements" - for what I'm looking for but I think I would be wasting my time
I am at times so frustrated that I would like to 100% replace all of CDT with something that is usable
and at times, I think I have to re-write it on my own.
What's wrong with the current implementation is this:
a) When I import a library it is not immediately usable by other members of the workspace.
Ok it is if you perform 'surgery' on all of the other projects, such as:
A library publishes or produces a "public api include folder" - why do I have to add this to all other members of the workspace?
The library creates a code library, why do I have to manually modifiy all applications in the workspace so that they can link against the project?
One library might require or use another library, for example: LWIP often is used with FreeRTOS
b) But instead, the idea that eclipse seems to be centered around is this: Just copy all of your source code(and header files) into this one directory and let the compiler tool sort it out
that works but is a maintainers nightmare - it's hard to track what came from where, and what changed
c) On Linux, and other platforms there is this idea of "Installing the library" - sorry - nope, will not and cannot.
I work on more then one project at a time, if Project(FOO) requires the library in Confguration(X) - do I install the configuration(X) headers and .a and .o files?
But what about project(BAR) that requires an incompatible configuration(Y), when switching from project(FOO) to (BAR) to help answer a question what happens?
Does my 'installed-configuration-x" get converted to Y? And then converted back to X later? What happens if something is missed?
Things like that should be 'installed' locally to the client project.
d) Besides, in most resource constrained places - embedded stuff - you must highly Taylor things to fit the situation, ie: Compile time flags that disable features or enable certain things
it's just not possible to install a full featured version of a library with all bells and whistles present because there is not enough flash memory in the design to do that
Thus configuration is a "forcing function" for many embedded situations, the LWIP and FreeRTOS configuration files are exact examples of this.
|
|
|
Powered by
FUDForum. Page generated in 0.03560 seconds
Home