| Re: [cdt-dev] Make Target View |
Hi,I came up with enhanced dialog, could you take a look and share your thoughts about it? The most significant part is a relation of a Build Target to Configuration and Project Builders. How does it fit to overall concept and does it connect well to Managed Build?
We had a similar desire: https://bugs.eclipse.org/bugs/show_bug.cgi?id=224640 . Our Make Target dialog is almost identical to yours -- we have a grouping for tying the Make Target to a particular build configuration. Presumably you put in some additional infrastructure to run the Scanner Discovery builder in the context of the specified configuration?
Consider my email rather as invitation to discussion, kind of collecting requirements thing. I wanted to make improvements to the Make Target dialog and discovered a bunch of related ussues in Bugzilla. I suppose if we consider majority of user requirements and redesign the view commiters would put it to CDT 5.X? Or would they? It does not seem that many patches were accepted in this area recently.
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.
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?
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.
Andrew
Cheers,
James