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

2009/5/29 Elena Laskavaia <elaskavaia@xxxxxxx>:
> You have to do pretty much what you have described for complicated project
> structure.
> 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:
>> Hi,
>> 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
>> this
>> is an often repeated question, and correct any bad assumptions/conclusions
>> I
>> 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
>> this
>> 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
>> under
>> 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,
>> so
>> I use standard makefiles.  To get the project working I need to jump
>> through
>> the following hoops:  Write a makefile [which users do not expect to do
>> when
>> using an IDE], create a linked resource variable to somewhere lower down
>> the
>> directory tree, setup paths from the linked resource variable to the files
>> required, created a working set, manually configured the working set to
>> only
>> show the files that are in the makefile.  If I want to add or removed
>> files
>> 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.
>>  This
>> 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
>> be
>> 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
>> function
>> 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.
>> Regards,
>> Richard.
>> +
>> Designed for Microcontrollers.  More than 7000 downloads per month.
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx

Back to the top