| 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