Home » Language IDEs » C / C++ IDE (CDT) » Inflexible project structure problem
| Inflexible project structure problem [message #42814] |
Wed, 25 September 2002 15:21  |
Eclipse User |
|
|
|
Originally posted by: john_arthorne.o_ti.com
Many users of the Eclipse Java IDE have reported problems with the
inflexibility of the eclipse project structure. In particular, they
would like parts of a project to be located in a different place in the
file system from the project root. They would also like the ability to
exclude certain parts of a subtree from being compiled or even from
being part of the workspace. A short summary of the problems
encountered by java developers in Eclipse in this area is found here:
http://www.eclipse.org/eclipse/development/inflexible-projec ts-problem.html
The reason I'm posting here is that so far we only have java-specific
use-cases where these problems arise. I would like to know if CDT users
and developers experience similar problems. If so, can you describe
some problematic use-cases that arise in the course of C development
that are related to this area? In scoping out solutions to these
problems, we need to decide whether to go for a generic solution or for
more JDT-specific solutions. Knowing of similar cases in the non-Java
realm will help us do this. Thanks.
|
|
|
| Re: Inflexible project structure problem [message #42845 is a reply to message #42814] |
Wed, 25 September 2002 18:41  |
| Eclipse User |
|
|
|
Originally posted by: ed.burnette.no.spam.sas.com
I'm a new CDT user and I ran into problems right away trying to get it to
work with our existing directory structure, which cannot change. We have a
large structure with thousands of directories and source files. I'm only
working on a small part of that of course. The directory structure looks
something like:
/toplevel
/toplevel/component1
/toplevel/component1/src - C source files
/toplevel/component1/h - C header files
/toplevel/component1/doc - HTML documentation files
/toplevel/component1/testsrc - Test files
/toplevel/component1/testbin - Big binary database source files
/toplevel/component1/obj - Object modules (generated)
/toplevel/component1/com - Dlls and executables (generated)
/toplevel/component2
(more of the same)
/toplevel/component3
(etc..)
Problems:
1. The first problem was just trying to find the right directory level to
map to a 'project'. I can't use /toplevel because it would pull in waaaay
too much. So my workaround is currently to have separate projects for each
component I currently care about at the moment, which causes some problems
of its own because a unit of work will often touch several different
component directories.
2. Also we ran into is what the summary calls the 'all-inclusive' problem.
When I do a build the generated directories start appearing in the Navigator
and C++ Projects view. If I delete them from the view they go away on disk
too (which is sometimes what I want, sometimes not). There's no way to
filter them from either view (the views do have a filter command but the
patterns I might be able to use are not on the list).
3. We have the non-overlapping problem too. For example the 3 component
directories I work with most often really contain a dozen or more different
logical 'projects' spread across them (with references to many other
component directories that I'm not modifying). I can't group them together
for building or synchronization purposes.
4. Even though I created the component projects from the CVS Perspective and
used CVS modules that only included the source, header, and doc files, when
I do a resynchronize for some reason it wants to resync every directory that
is in CVS including the ones with the big binary files I don't care about.
That will either crash the CVS server or take so long so as to be not
useful.
5. This may be a CDT specific problem but debugging and launching requires
that I give it the name of some starting program file which is in one of the
projects. Well, it ain't. I haven't figured out a workaround for that one
yet so I have to launch and debug outside of Eclipse.
6. With Visual Studio or an IDE wannabe like TextPad I can drag a file from
the desktop onto the tool or do a File...Open in the tool to look at any
file using the built-in editor. Eclipse doesn't do that, I think because the
files are outside of any directory or project structure that it knows about.
This is a pretty annoying limitation, perhaps caused by the single-rooted
problem mentioned in the summary. I could use the Import command perhaps,
but I don't want to import and modify my projects, I just want to view a
file with one of the nice Eclipse editors. I can't even create a blank
document for scribbling on without giving it a name on disk first and
assigning it to some project and giving it a type, etc. etc..
7. Finally our particular build tool works best if I don't actually have any
files locally except the ones I'm currently modifying. It gets the rest from
a live mirror of the repository on the network, eliminating most
synchronization needs. If the project model could support that, for example
making temporary read-only copies of files I'm viewing when I double-click
on them in the navigator and actually doing a team checkout if I try and
modify the file, that would be a big help for us.
Advantages:
1. One advantage of the current system compared to Visual Studio is that
it's a no-brainer to create a project in Eclipse. With VS I have to add each
file individually to a project and try to keep the project resource list up
to date with the 'make' files, which is almost more trouble than it's worth.
2. With Visual Studio you can easily get yourself in trouble including
resources from all over the place. For example I came back to a VS project
once and couldn't build it because I had removed or moved some of the
resource files which were in a totally unrelated directory. I know I
shouldn't have done that but Eclipse's more inflexible nature would have
prevented it in the first place.
Hope this helps.
--Ed
(remove no.spam. from address)
"John Arthorne" <john_arthorne@o_ti.com> wrote in message
news:3D920CC0.4010009@o_ti.com...
> The reason I'm posting here is that so far we only have java-specific
> use-cases where these problems arise. I would like to know if CDT users
> and developers experience similar problems. If so, can you describe
> some problematic use-cases that arise in the course of C development
> that are related to this area? In scoping out solutions to these
> problems, we need to decide whether to go for a generic solution or for
> more JDT-specific solutions. Knowing of similar cases in the non-Java
> realm will help us do this. Thanks.
>
|
|
|
| Re: Inflexible project structure problem [message #42877 is a reply to message #42845] |
Thu, 26 September 2002 09:56 |
| Eclipse User |
|
|
|
Originally posted by: dschaefer.rational.com
Great summary, Ed. The points you mention are all things that a lot of CDT
users will run into.
I just want to highlight that we will want to be able to introduce Eclipse
CDT into groups that have large amounts of legacy artifacts sitting around
and, as in Ed's case, it would not be acceptable to change the file
structure to meet the restrictions of the IDE. While having the Eclipse
resource structure map directly to the file system makes it easy to manage
(especially from a source control perspective), we will need the flexibility
of including resources from other locations in projects to enable
adoptability by a large block of the C/C++ development community.
From a build perspective, we probably have a more complicated requirement
that probably isn't best handled by the Eclipse core. There are situations
where we will need to be able to support multiple build targets (different
platforms, different options settings) and to be able to include/exclude
individual resources from builds of those targets. This target concept and
the mechanisms to handle builds for this will need to be supplied by the
CDT. During this work we'll try to identify concepts we think would be
better handled by the core. Certainly if the core offers something to take
care of some of this, we'll use it.
- Doug
"Ed Burnette" <ed.burnette@no.spam.sas.com> wrote in message
news:amtcu0$20k$1@rogue.oti.com...
> I'm a new CDT user and I ran into problems right away trying to get it to
> work with our existing directory structure, which cannot change. We have a
> large structure with thousands of directories and source files. I'm only
> working on a small part of that of course. The directory structure looks
> something like:
>
> /toplevel
> /toplevel/component1
> /toplevel/component1/src - C source files
> /toplevel/component1/h - C header files
> /toplevel/component1/doc - HTML documentation files
> /toplevel/component1/testsrc - Test files
> /toplevel/component1/testbin - Big binary database source files
> /toplevel/component1/obj - Object modules (generated)
> /toplevel/component1/com - Dlls and executables (generated)
> /toplevel/component2
> (more of the same)
> /toplevel/component3
> (etc..)
>
> Problems:
>
> 1. The first problem was just trying to find the right directory level to
> map to a 'project'. I can't use /toplevel because it would pull in waaaay
> too much. So my workaround is currently to have separate projects for each
> component I currently care about at the moment, which causes some problems
> of its own because a unit of work will often touch several different
> component directories.
>
> 2. Also we ran into is what the summary calls the 'all-inclusive' problem.
> When I do a build the generated directories start appearing in the
Navigator
> and C++ Projects view. If I delete them from the view they go away on disk
> too (which is sometimes what I want, sometimes not). There's no way to
> filter them from either view (the views do have a filter command but the
> patterns I might be able to use are not on the list).
>
> 3. We have the non-overlapping problem too. For example the 3 component
> directories I work with most often really contain a dozen or more
different
> logical 'projects' spread across them (with references to many other
> component directories that I'm not modifying). I can't group them together
> for building or synchronization purposes.
>
> 4. Even though I created the component projects from the CVS Perspective
and
> used CVS modules that only included the source, header, and doc files,
when
> I do a resynchronize for some reason it wants to resync every directory
that
> is in CVS including the ones with the big binary files I don't care about.
> That will either crash the CVS server or take so long so as to be not
> useful.
>
> 5. This may be a CDT specific problem but debugging and launching requires
> that I give it the name of some starting program file which is in one of
the
> projects. Well, it ain't. I haven't figured out a workaround for that one
> yet so I have to launch and debug outside of Eclipse.
>
> 6. With Visual Studio or an IDE wannabe like TextPad I can drag a file
from
> the desktop onto the tool or do a File...Open in the tool to look at any
> file using the built-in editor. Eclipse doesn't do that, I think because
the
> files are outside of any directory or project structure that it knows
about.
> This is a pretty annoying limitation, perhaps caused by the single-rooted
> problem mentioned in the summary. I could use the Import command perhaps,
> but I don't want to import and modify my projects, I just want to view a
> file with one of the nice Eclipse editors. I can't even create a blank
> document for scribbling on without giving it a name on disk first and
> assigning it to some project and giving it a type, etc. etc..
>
> 7. Finally our particular build tool works best if I don't actually have
any
> files locally except the ones I'm currently modifying. It gets the rest
from
> a live mirror of the repository on the network, eliminating most
> synchronization needs. If the project model could support that, for
example
> making temporary read-only copies of files I'm viewing when I double-click
> on them in the navigator and actually doing a team checkout if I try and
> modify the file, that would be a big help for us.
>
> Advantages:
>
> 1. One advantage of the current system compared to Visual Studio is that
> it's a no-brainer to create a project in Eclipse. With VS I have to add
each
> file individually to a project and try to keep the project resource list
up
> to date with the 'make' files, which is almost more trouble than it's
worth.
>
> 2. With Visual Studio you can easily get yourself in trouble including
> resources from all over the place. For example I came back to a VS project
> once and couldn't build it because I had removed or moved some of the
> resource files which were in a totally unrelated directory. I know I
> shouldn't have done that but Eclipse's more inflexible nature would have
> prevented it in the first place.
>
> Hope this helps.
> --Ed
> (remove no.spam. from address)
>
>
> "John Arthorne" <john_arthorne@o_ti.com> wrote in message
> news:3D920CC0.4010009@o_ti.com...
> > The reason I'm posting here is that so far we only have java-specific
> > use-cases where these problems arise. I would like to know if CDT users
> > and developers experience similar problems. If so, can you describe
> > some problematic use-cases that arise in the course of C development
> > that are related to this area? In scoping out solutions to these
> > problems, we need to decide whether to go for a generic solution or for
> > more JDT-specific solutions. Knowing of similar cases in the non-Java
> > realm will help us do this. Thanks.
> >
>
>
|
|
|
| Re: Inflexible project structure problem [message #42908 is a reply to message #42877] |
Thu, 26 September 2002 10:26 |
| Eclipse User |
|
|
|
Originally posted by: cpklapper.yahoo.com
Not only legacy, but also cross-organizational code presents a problem for
the fixed directory structure model. Now if all the world had UNIX soft
linking, we would be fine, but since it doesn't, perhaps eclipse ought to
provide a project-level soft linking instead. The project itself would
have its home location, but every element (both source and target) in the
makefile would have its full URL. Each kind of file would have its
default location for newly created elements which, by default, would be
under the project directory.
Defaulting makes it easy; customization makes it flexible.
Doug Schaefer wrote:
> Great summary, Ed. The points you mention are all things that a lot of CDT
> users will run into.
> I just want to highlight that we will want to be able to introduce Eclipse
> CDT into groups that have large amounts of legacy artifacts sitting around
> and, as in Ed's case, it would not be acceptable to change the file
> structure to meet the restrictions of the IDE. While having the Eclipse
> resource structure map directly to the file system makes it easy to manage
> (especially from a source control perspective), we will need the flexibility
> of including resources from other locations in projects to enable
> adoptability by a large block of the C/C++ development community.
> From a build perspective, we probably have a more complicated requirement
> that probably isn't best handled by the Eclipse core. There are situations
> where we will need to be able to support multiple build targets (different
> platforms, different options settings) and to be able to include/exclude
> individual resources from builds of those targets. This target concept and
> the mechanisms to handle builds for this will need to be supplied by the
> CDT. During this work we'll try to identify concepts we think would be
> better handled by the core. Certainly if the core offers something to take
> care of some of this, we'll use it.
> - Doug
> "Ed Burnette" <ed.burnette@no.spam.sas.com> wrote in message
> news:amtcu0$20k$1@rogue.oti.com...
> > I'm a new CDT user and I ran into problems right away trying to get it to
> > work with our existing directory structure, which cannot change. We have a
> > large structure with thousands of directories and source files. I'm only
> > working on a small part of that of course. The directory structure looks
> > something like:
> >
> > /toplevel
> > /toplevel/component1
> > /toplevel/component1/src - C source files
> > /toplevel/component1/h - C header files
> > /toplevel/component1/doc - HTML documentation files
> > /toplevel/component1/testsrc - Test files
> > /toplevel/component1/testbin - Big binary database source files
> > /toplevel/component1/obj - Object modules (generated)
> > /toplevel/component1/com - Dlls and executables (generated)
> > /toplevel/component2
> > (more of the same)
> > /toplevel/component3
> > (etc..)
> >
> > Problems:
> >
> > 1. The first problem was just trying to find the right directory level to
> > map to a 'project'. I can't use /toplevel because it would pull in waaaay
> > too much. So my workaround is currently to have separate projects for each
> > component I currently care about at the moment, which causes some problems
> > of its own because a unit of work will often touch several different
> > component directories.
> >
> > 2. Also we ran into is what the summary calls the 'all-inclusive' problem.
> > When I do a build the generated directories start appearing in the
> Navigator
> > and C++ Projects view. If I delete them from the view they go away on disk
> > too (which is sometimes what I want, sometimes not). There's no way to
> > filter them from either view (the views do have a filter command but the
> > patterns I might be able to use are not on the list).
> >
> > 3. We have the non-overlapping problem too. For example the 3 component
> > directories I work with most often really contain a dozen or more
> different
> > logical 'projects' spread across them (with references to many other
> > component directories that I'm not modifying). I can't group them together
> > for building or synchronization purposes.
> >
> > 4. Even though I created the component projects from the CVS Perspective
> and
> > used CVS modules that only included the source, header, and doc files,
> when
> > I do a resynchronize for some reason it wants to resync every directory
> that
> > is in CVS including the ones with the big binary files I don't care about.
> > That will either crash the CVS server or take so long so as to be not
> > useful.
> >
> > 5. This may be a CDT specific problem but debugging and launching requires
> > that I give it the name of some starting program file which is in one of
> the
> > projects. Well, it ain't. I haven't figured out a workaround for that one
> > yet so I have to launch and debug outside of Eclipse.
> >
> > 6. With Visual Studio or an IDE wannabe like TextPad I can drag a file
> from
> > the desktop onto the tool or do a File...Open in the tool to look at any
> > file using the built-in editor. Eclipse doesn't do that, I think because
> the
> > files are outside of any directory or project structure that it knows
> about.
> > This is a pretty annoying limitation, perhaps caused by the single-rooted
> > problem mentioned in the summary. I could use the Import command perhaps,
> > but I don't want to import and modify my projects, I just want to view a
> > file with one of the nice Eclipse editors. I can't even create a blank
> > document for scribbling on without giving it a name on disk first and
> > assigning it to some project and giving it a type, etc. etc..
> >
> > 7. Finally our particular build tool works best if I don't actually have
> any
> > files locally except the ones I'm currently modifying. It gets the rest
> from
> > a live mirror of the repository on the network, eliminating most
> > synchronization needs. If the project model could support that, for
> example
> > making temporary read-only copies of files I'm viewing when I double-click
> > on them in the navigator and actually doing a team checkout if I try and
> > modify the file, that would be a big help for us.
> >
> > Advantages:
> >
> > 1. One advantage of the current system compared to Visual Studio is that
> > it's a no-brainer to create a project in Eclipse. With VS I have to add
> each
> > file individually to a project and try to keep the project resource list
> up
> > to date with the 'make' files, which is almost more trouble than it's
> worth.
> >
> > 2. With Visual Studio you can easily get yourself in trouble including
> > resources from all over the place. For example I came back to a VS project
> > once and couldn't build it because I had removed or moved some of the
> > resource files which were in a totally unrelated directory. I know I
> > shouldn't have done that but Eclipse's more inflexible nature would have
> > prevented it in the first place.
> >
> > Hope this helps.
> > --Ed
> > (remove no.spam. from address)
> >
> >
> > "John Arthorne" <john_arthorne@o_ti.com> wrote in message
> > news:3D920CC0.4010009@o_ti.com...
> > > The reason I'm posting here is that so far we only have java-specific
> > > use-cases where these problems arise. I would like to know if CDT users
> > > and developers experience similar problems. If so, can you describe
> > > some problematic use-cases that arise in the course of C development
> > > that are related to this area? In scoping out solutions to these
> > > problems, we need to decide whether to go for a generic solution or for
> > > more JDT-specific solutions. Knowing of similar cases in the non-Java
> > > realm will help us do this. Thanks.
> > >
> >
> >
|
|
|
| Re: Inflexible project structure problem [message #42940 is a reply to message #42845] |
Thu, 26 September 2002 12:35 |
| Eclipse User |
|
|
|
Originally posted by: john_arthorne.o_ti.com
Ed, thank you very much for that feedback. I suspected that CDT uses
would have similar issues to java developers, but it's great to have
this concrete list. The comparison with Visual Studio was also
insightful. Just a couple of minor comments below:
Ed Burnette wrote:
>I'm a new CDT user and I ran into problems right away trying to get it to
>work with our existing directory structure, which cannot change. We have a
>large structure with thousands of directories and source files. I'm only
>working on a small part of that of course. The directory structure looks
>something like:
>
>/toplevel
> /toplevel/component1
> /toplevel/component1/src - C source files
> /toplevel/component1/h - C header files
> /toplevel/component1/doc - HTML documentation files
> /toplevel/component1/testsrc - Test files
> /toplevel/component1/testbin - Big binary database source files
> /toplevel/component1/obj - Object modules (generated)
> /toplevel/component1/com - Dlls and executables (generated)
> /toplevel/component2
> (more of the same)
> /toplevel/component3
> (etc..)
>
>1. The first problem was just trying to find the right directory level to
>map to a 'project'. I can't use /toplevel because it would pull in waaaay
>too much. So my workaround is currently to have separate projects for each
>component I currently care about at the moment, which causes some problems
>of its own because a unit of work will often touch several different
>component directories.
>
This is actually the directory structure that the Eclipse workspace was
designed to support. Each "component" in this structure would map to a
single Eclipse project. Can you elaborate a bit more on the problems
with this arrangement? Exactly which resources would you like to see in
a single Eclipse project? Is the logical structure of an Eclipse
project a matter of preference or are there some constraints introduced
by the tooling that requires a certain Eclipse project layout? Does the
CDT builder not support building code that spans Eclipse projects?
>2. Also we ran into is what the summary calls the 'all-inclusive' problem.
>When I do a build the generated directories start appearing in the Navigator
>and C++ Projects view. If I delete them from the view they go away on disk
>too (which is sometimes what I want, sometimes not). There's no way to
>filter them from either view (the views do have a filter command but the
>patterns I might be able to use are not on the list).
>
So just to be clear, you want these generated files to remain part of
the project, but you would like to hide them in certain views? This is
solved in the JDT tooling by providing a rich set of filters: filter
non-java components, filter a working set, filter a pattern, etc.
>4. Even though I created the component projects from the CVS Perspective and
>used CVS modules that only included the source, header, and doc files, when
>I do a resynchronize for some reason it wants to resync every directory that
>is in CVS including the ones with the big binary files I don't care about.
>That will either crash the CVS server or take so long so as to be not
>useful.
>
I will ask someone from the CVS development team to follow up on this one.
>6. With Visual Studio or an IDE wannabe like TextPad I can drag a file from
>the desktop onto the tool or do a File...Open in the tool to look at any
>file using the built-in editor. Eclipse doesn't do that, I think because the
>files are outside of any directory or project structure that it knows about.
>This is a pretty annoying limitation, perhaps caused by the single-rooted
>problem mentioned in the summary. I could use the Import command perhaps,
>but I don't want to import and modify my projects, I just want to view a
>file with one of the nice Eclipse editors. I can't even create a blank
>document for scribbling on without giving it a name on disk first and
>assigning it to some project and giving it a type, etc. etc..
>
This is being pursued as a separate work item. See bugs 4922 and 21973
to follow progress on these items.
|
|
|
| Re: Inflexible project structure problem [message #43002 is a reply to message #42940] |
Fri, 27 September 2002 00:13 |
| Eclipse User |
|
|
|
Originally posted by: ed.burnette.no.spam.sas.com
"John Arthorne" <john_arthorne@o_ti.com> wrote in message
news:3D933748.7080400@o_ti.com...
> Ed, thank you very much for that feedback. I suspected that CDT uses ...
Np. There's really a lot in common between programming in just about every
language so I look foward to the efforts to unify all the DT's. That's one
thing I liked about VS.NET (compared to VS6 for instance) - if you want to
program in C++, in VB, C#, in J#, in whatever.. you pretty much have the
same tools and IDE capabilities for whatever language you feel like
programming in. I don't see why eclipse couldn't do that too. I want to see
a *DT for C# and maybe a couple proprietary languages we have here but doing
a JDT-quality environment seems like such a huge hurdle right now.
>
> Ed Burnette wrote:
> >I'm a new CDT user and I ran into problems right away trying to get it
to...
> >
> >1. The first problem was just trying to find the right directory level
to...
> >
> This is actually the directory structure that the Eclipse workspace was
> designed to support. Each "component" in this structure would map to a
> single Eclipse project. Can you elaborate a bit more on the problems
> with this arrangement? Exactly which resources would you like to see in
> a single Eclipse project? Is the logical structure of an Eclipse
> project a matter of preference or are there some constraints introduced
> by the tooling that requires a certain Eclipse project layout? Does the
> CDT builder not support building code that spans Eclipse projects?
Some of both. One constraint is doing a Team sync. It looks like I have to
select each subdirectory that I want to synchronize which takes several
control-clicks to get just the ones I want (because if I select all the
projects it will pull down more then just the source modules I need). With
Visual Studio and our VSS clone I could click once once on the top level
project (which included a subproject for each component) and do a 'Get
latest' to update only the source files that I cared about.
The way build targets work with the CDT builder leaves something to be
desired too. Even though I'm building a dll which uses stuff from several of
these component directories, I have to decide on one of them to define the
build target in. And one component directory ('project' to eclipse) needs to
have several build targets. That works, although the build targets are hard
to find in amongst all the other directories. I'm still learning how to use
eclipse and CDT so I'm hoping I'll discover a better way to do this. With
Visual Studio I could define a current project which had a command to build
it, and then I could just hit F7 to do the build.
This is CDT-builder's problem but I can't use the overall build-everything
command in eclipse because of the syntax it imposes on the build command - I
think it wants to run the default build command with no arguments which is
ok for Make but I'm not using Make. And I can't use 'build clean' because it
wants to stick a 'clean' keyword on the command which isn't liked by our
build tool either. VS had project options to set these keywords but I had to
set them on every single component project which was a pain in its own way.
I like the general idea of build targets though; I got tired of changing
that build command in VS whenever I wanted to build something different in a
particular component directory.
I'm not sure exactly what model would work best, maybe some concept of a
perspective at the project level? So when I'm doing development on X I see
the structure one way, but if I'm fixing bugs in Y I see it another way,
maybe using filters. Perhaps the JDT filter tech you mention later would
help here. If I could get global CVS ignored-resources list to work that
would be helpful too - I can't see any evidence that it's doing anything in
the current release.
I should note that VS never caught on much here because of the hassle of
setting up its project definitions (and cost), so maybe I shouldn't keep
using it as an example :).
>
> >2. Also we ran into is what the summary calls the 'all-inclusive'
problem.
> >When I do a build the generated directories start appearing in the
Navigator...
> >
> So just to be clear, you want these generated files to remain part of
> the project, but you would like to hide them in certain views? This is
> solved in the JDT tooling by providing a rich set of filters: filter
> non-java components, filter a working set, filter a pattern, etc.
Well, the generated files and directories do exist but I don't want to see
them so I'm not sure if I care whether they're excluded from the project or
in the project but hidden. I don't want CVS trying to mess with them though.
I haven't read about the JDT filters yet so maybe that would do it. It would
be nice if CDT and JDT and whateverDT could share a lot of this code. (I
know that's a goal for the future).
|
|
|
| Re: Inflexible project structure problem [message #43070 is a reply to message #43002] |
Fri, 27 September 2002 11:10 |
| Eclipse User |
|
|
|
Originally posted by: cpklapper.yahoo.com
>Ed Burnette wrote:
> "John Arthorne" <john_arthorne@o_ti.com> wrote in message
> news:3D933748.7080400@o_ti.com...
> > Ed, thank you very much for that feedback. I suspected that CDT uses ...
> Np. There's really a lot in common between programming in just about every
> language so I look foward to the efforts to unify all the DT's. That's one
> thing I liked about VS.NET (compared to VS6 for instance) - if you want to
> program in C++, in VB, C#, in J#, in whatever.. you pretty much have the
> same tools and IDE capabilities for whatever language you feel like
> programming in. I don't see why eclipse couldn't do that too. I want to see
> a *DT for C# and maybe a couple proprietary languages we have here but doing
> a JDT-quality environment seems like such a huge hurdle right now.
Unfortunately, Microsoft is phasing out MFC and VB in favor of C#. Those
of us with a large investment in MFC and VB, especially with a common code
base with UNIX back ends, are looking for a replacement tool, but an IDE
sans dialog editor will not cut it.
> I should note that VS never caught on much here because of the hassle of
> setting up its project definitions (and cost), so maybe I shouldn't keep
> using it as an example :).
VS is established here, but are putting off adoption of VS.Net for as long
as possible. The reason is that C# is useless for us (call us when they
have the UNIX compiler for it) and .Net has dropped the MFC wizards.
|
|
| |
| Re: Inflexible project structure problem [message #43701 is a reply to message #42845] |
Wed, 02 October 2002 14:29 |
| Eclipse User |
|
|
|
Originally posted by: Michael_Valenta.oti.com
Ed,
Just to let you know, a feature has been released to the 2.1 development
stream that will help you out on point 4 below (CVS sucking in unwanted
directories). Check out bug 21541
(http://dev.eclipse.org/bugs/show_bug.cgi?id=21541) for a summary of the
fix.
Michael
Ed Burnette wrote:
> I'm a new CDT user and I ran into problems right away trying to get it to
> work with our existing directory structure, which cannot change. We have a
> large structure with thousands of directories and source files. I'm only
> working on a small part of that of course. The directory structure looks
> something like:
>
> /toplevel
> /toplevel/component1
> /toplevel/component1/src - C source files
> /toplevel/component1/h - C header files
> /toplevel/component1/doc - HTML documentation files
> /toplevel/component1/testsrc - Test files
> /toplevel/component1/testbin - Big binary database source files
> /toplevel/component1/obj - Object modules (generated)
> /toplevel/component1/com - Dlls and executables (generated)
> /toplevel/component2
> (more of the same)
> /toplevel/component3
> (etc..)
>
> Problems:
>
> 1. The first problem was just trying to find the right directory level to
> map to a 'project'. I can't use /toplevel because it would pull in waaaay
> too much. So my workaround is currently to have separate projects for each
> component I currently care about at the moment, which causes some problems
> of its own because a unit of work will often touch several different
> component directories.
>
> 2. Also we ran into is what the summary calls the 'all-inclusive' problem.
> When I do a build the generated directories start appearing in the Navigator
> and C++ Projects view. If I delete them from the view they go away on disk
> too (which is sometimes what I want, sometimes not). There's no way to
> filter them from either view (the views do have a filter command but the
> patterns I might be able to use are not on the list).
>
> 3. We have the non-overlapping problem too. For example the 3 component
> directories I work with most often really contain a dozen or more different
> logical 'projects' spread across them (with references to many other
> component directories that I'm not modifying). I can't group them together
> for building or synchronization purposes.
>
> 4. Even though I created the component projects from the CVS Perspective and
> used CVS modules that only included the source, header, and doc files, when
> I do a resynchronize for some reason it wants to resync every directory that
> is in CVS including the ones with the big binary files I don't care about.
> That will either crash the CVS server or take so long so as to be not
> useful.
>
> 5. This may be a CDT specific problem but debugging and launching requires
> that I give it the name of some starting program file which is in one of the
> projects. Well, it ain't. I haven't figured out a workaround for that one
> yet so I have to launch and debug outside of Eclipse.
>
> 6. With Visual Studio or an IDE wannabe like TextPad I can drag a file from
> the desktop onto the tool or do a File...Open in the tool to look at any
> file using the built-in editor. Eclipse doesn't do that, I think because the
> files are outside of any directory or project structure that it knows about.
> This is a pretty annoying limitation, perhaps caused by the single-rooted
> problem mentioned in the summary. I could use the Import command perhaps,
> but I don't want to import and modify my projects, I just want to view a
> file with one of the nice Eclipse editors. I can't even create a blank
> document for scribbling on without giving it a name on disk first and
> assigning it to some project and giving it a type, etc. etc..
>
> 7. Finally our particular build tool works best if I don't actually have any
> files locally except the ones I'm currently modifying. It gets the rest from
> a live mirror of the repository on the network, eliminating most
> synchronization needs. If the project model could support that, for example
> making temporary read-only copies of files I'm viewing when I double-click
> on them in the navigator and actually doing a team checkout if I try and
> modify the file, that would be a big help for us.
>
> Advantages:
>
> 1. One advantage of the current system compared to Visual Studio is that
> it's a no-brainer to create a project in Eclipse. With VS I have to add each
> file individually to a project and try to keep the project resource list up
> to date with the 'make' files, which is almost more trouble than it's worth.
>
> 2. With Visual Studio you can easily get yourself in trouble including
> resources from all over the place. For example I came back to a VS project
> once and couldn't build it because I had removed or moved some of the
> resource files which were in a totally unrelated directory. I know I
> shouldn't have done that but Eclipse's more inflexible nature would have
> prevented it in the first place.
>
> Hope this helps.
> --Ed
> (remove no.spam. from address)
>
>
> "John Arthorne" <john_arthorne@o_ti.com> wrote in message
> news:3D920CC0.4010009@o_ti.com...
>
>>The reason I'm posting here is that so far we only have java-specific
>>use-cases where these problems arise. I would like to know if CDT users
>>and developers experience similar problems. If so, can you describe
>>some problematic use-cases that arise in the course of C development
>>that are related to this area? In scoping out solutions to these
>>problems, we need to decide whether to go for a generic solution or for
>>more JDT-specific solutions. Knowing of similar cases in the non-Java
>>realm will help us do this. Thanks.
>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Tue Nov 04 11:09:41 EST 2025
Powered by FUDForum. Page generated in 0.05957 seconds |
Home