[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] CDT 3.0 project browsing feature
|
I am trying to understand your problem better and why you feel it's too difficult to do what you wish to do with the existing functionality.
Could you not just import your folders as linked resources into a standard make project? Even if you don't ever build the project and just want to use Eclipse/CDT as a fancy text editor, wouldn't this fit the need? If you don't want to build using CDT, then just don't hit CTRL + B :-)
How complicated are your directory structures for your sources? Your mileage will probably vary, as we like to say. Eclipse for whatever bizarre reason enforces a rule that you cannot have linked folders anywhere except the project root.
___________________________________________
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
> -----Original Message-----
> From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
> Behalf Of Øyvind Harboe
> Sent: Friday, November 26, 2004 4:01 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] CDT 3.0 project browsing feature
>
> Except for more of the same :-), I'd like to see CDT support existing
> C/C++ projects more smoothly.
>
> Currently CDT has a fundamental assumption that users will switch to
> doing their projects entirely in CDT. This is a stumbling block for
> using CDT on a existing projects.
>
> E.g. I'd like to be able to use CDT to refactor existing projects
> *without* switching those projects to use CDT as a project management or
> build mechanism.
>
> What is a CDT project anyway?
>
> Why is it needed?
>
> E.g. I've got an existing eCos project with a makefile. To build it, I
> need to issue various commands from the command line. My eCos project
> eventually produces an executable.
>
> I'd like to tell CDT where my source files are(multiple directories,
> application + eCos source). I don't want CDT to tell me where the source
> files should be.
>
> A "CDT project" could simply be a place to store emphemeral information
> about how to build existing projects, much like how debug sessions are
> stored. These CDT projects wouldn't even be shared among multiple
> developers. This is an important point, because it should be the
> decision of a lone programmer whether to use CDT or not in a larger
> project.
>
>
> - Support for automake/autoconf is definitely along these lines:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=29757
>
> - Wrapping up CDT as a commandline Insight replacement is another
> example of a push in this direction.
>
> - Wrapping up Eclipse as a WinDiff replacement is moving further in this
> direction.
>
> Be like a text editor. The developer should be able to turn to Eclipse
> CDT for a useful subset of functionality. He should have to convert
> religion before he can drink from the source. :-)
>
>
> --
> Øyvind Harboe
> http://www.zylin.com
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
