Re: [cdt-dev] Directory structure rebellion - Embedded development

[James Blackburn <jamesblackburn@xxxxxxxxx>]

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:
http://sergebeauchamp.blogspot.com/

I've got these changes back-ported to the 3.4 Eclipse stream if you're
interested in trying it for real:
http://github.com/jamesblackburn/eclipse-core-resources
http://github.com/jamesblackburn/eclipse-ui-ide

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 eclipse.org
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.

Cheers,
James


> 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.  http://www.freertos.org/a00017.html 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.
>>
>> + http://www.FreeRTOS.org
>> Designed for Microcontrollers.  More than 7000 downloads per month.
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>