[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] Make Target View
|
While the above worked, I didn't
submit a patch due to the massive performance problems I encountered.
Make targets are most useful for people who do not have a single 'make all'
target which builds their tree.
I would think that most people
using make targets are using it for the reason that they already have
makefiles, i.e. people working with legacy projects and trying to use eclipse
niceties as C/C++ editor and error parsers. I believe that a typical situation
in this case a project root folder makefile/makefiles and perhaps folder level
makefiles.
Indeed, I think you misunderstood me. Yes they're
bringing their own Makefiles, but if they're running 'make all' in the project
root, then that's no different to building a managed make project... The
usefullness of the make targets view is in having multiple targets within the
tree. In one of our trees, we build multiple very similar apps from the
same set of source files. The problem then is to have the user's view of
the code be consistent with what's built into the
app.
They may have multiple targets that
build the same files with different -Ds and -Is producing different
binaries. It's then natural to tie some target(s) to a given
configuration. I did this using the PerFileSICollector -- not wanting
to make any assumptions on what was defined / undefined on per file basis.
The resulting cproject file grew to a few megabytes in size, with any
subsequent operations on the Project model taking 10s of seconds using
hundreds of megabytes of memory. I had Eclipse taking >1min to load
the .cproject file and start up, and was experiencing OOM exceptions doing
simple things like changing a build
setting.
Why do you tie a configuration to
a single file? Naively thinking, there would be not more than a few logical
groups of -Ds, -Is and $ENVs and each group you'd assign to a configuration,
no? Do you have a separate makefile or make target for each file?
I
don't tie a configuration to a single file. Just as in the Managed
Build world, you have a bunch of project level defines and includes plus a few
resource level (file/folder) level overrides. The same is the case for a
Makefile Project. If you want the source navigation, preprocessor
collapsing etc. to work correctly for _every_ file in a non-trivial Project,
then you need to ensure that you have the correct defines and includes for that
file. This is especially true when you have multiple make
targets that build logically different configurations (otherwise there would be
no need for separate build configuration at all, would
there?).
The
result was I gave up, and did this instead https://bugs.eclipse.org/bugs/show_bug.cgi?id=236872 .
Have you experienced serious issues with scalability doing what
you're doing? Are you using the PerProject or PerFile collector? I'd
be very interested to know if and how you got this working
successfully...
Well, I'd say we face rather different kinds of challenges. We compile
remotely on AIX and locally+remotely on Linux. Editing is done on Linux or
Windows, sending remotely via rsync. We use our own build system based on
gmake. It got its own scalability issues compiling hundreds/thousands of files
but this is a different story... CDT and Eclipse help tremendously, very
impressive work.
CDT does work very well. The problem is getting
the information it needs for all its wizardry to work from the external Makefile
into its Project model. If what's there already works fine for you, then
great!
James