[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Make Target View
|
On 6/16/08, James Blackburn <james.blackburn@xxxxxxxxxxxx> wrote:
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