Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Directory structure rebellion - Embedded development

James can you add this info on cdt wiki (design page), this is very useful stuff! Maybe add some brief description
or links on how to use it as well.

James Blackburn wrote:
2009/5/29 Elena Laskavaia <elaskavaia@xxxxxxx>:
You have to do pretty much what you have described for complicated project
There are some efforts to to create a "flexible project structure" a la
visual studio, but
it is coming slow (currently planned for e4 - next gen eclipse).

Actually the e4 stuff is basically *done* and working -- the most
important thing there is the UI support for creating the linked
resources easily & being able to have relative "Path variables" so
different people checking out the same source don't have to set a path
variable for things to be relative to.  Serge has implemented some
other neat bits -- such as resource filters.

You should checkout Serge's screencasts if you're interested:

I've got these changes back-ported to the 3.4 Eclipse stream if you're
interested in trying it for real:

There's not much difficulty in getting CDT to work with this work-flow
out the box.

So to answer you question: you can't do it with an
released Eclipse/CDT.  But with a little bit of effort you can get
there, and perhaps this stuff will make it into the base 3.6 release.


FreeRTOS info wrote:

First up - I'm new to the list and fully admit to having not read through
every past post first, so please just link me to the relevant place if
is an often repeated question, and correct any bad assumptions/conclusions
have made.

My questions/comments relate to using Eclipse in either managed make or
standard make with a directory structure that does not conform to the
apparent Eclipse requirement for all build files to be under the project
file directory.  Most (if not all) embedded projects I have worked on
include files from outside of the project directory for items such as
drivers, architecture specific port code, middleware etc.  These files are
typically under configuration control and so should ideally only exist in
one place but are common to lots of different applications.

As an example, I distribute an open source mini real time kernel.  For
I provide ports to many different architectures and demo projects for many
different compilers/IDEs.  I am trying to promote Eclipse use and even
provide a kernel aware plug in - but finding acceptance of this really
difficult.  The root directory is split into two:

+ FreeRTOS
   + Source
   + Demo

The Source directory contains the core kernel code for ALL the ports, and
the Demo directory contains the example projects.  There are many example
projects and all reference code from the Source directory.  Each demo
project also references source code from a common directory under Demo.
This in my opinion is a logical and maintainable structure and has served
well for the last 6 years. provides a
more complete explanation.

So there are two problems.  First off only a small subset of the files
Source need to be built.  Second the projects are stored in a subdirectory
under Demo but need to reference files that are higher up the directory
structure.  For example ../../common.

Using managed make is with this structure is, well, not easily workable,
I use standard makefiles.  To get the project working I need to jump
the following hoops:  Write a makefile [which users do not expect to do
using an IDE], create a linked resource variable to somewhere lower down
directory tree, setup paths from the linked resource variable to the files
required, created a working set, manually configured the working set to
show the files that are in the makefile.  If I want to add or removed
I need to edit the makefile and the working set.

This ends up with a working setup - !!!however!!! the linked resource
variable seems to be saved as part of the workspace, not the project.
means for each example I provide I have to include the entire workspace,
which is not designed for easy distribution.

So - am I missing something obvious here?  How would others use the build
system in Eclipse, just taking it as read that the project simply cannot
at the root of all the code that might need to be included?  How would
others distribute such projects, expect their users to maintain the code,
and document how to setup such a project?  I'm hoping there is a simple
answer to this or a plan to add something to the CDT that makes it
in a more 'traditional' way whereby a project can select the files to be
included through the IDE.

Thanks in advance for any advice you can provide.


Designed for Microcontrollers.  More than 7000 downloads per month.
cdt-dev mailing list

cdt-dev mailing list

cdt-dev mailing list

Back to the top