Home » Language IDEs » C / C++ IDE (CDT) » "Updating project..." is killing me
| "Updating project..." is killing me [message #165335] |
Tue, 07 March 2006 11:06  |
Eclipse User |
|
|
|
Every time I build, I have to wait 40 seconds while Eclipse says it is
updating project. Even if the build immediately fails with only a couple
of lines of output, I still have this delay.
I have all binary parsers turned off, indexing is off.
If I wanted to try to hack CDT to disable this - could someone point me
in the right direction?
|
|
| | |
| Re: "Updating project..." is killing me [message #165359 is a reply to message #165351] |
Tue, 07 March 2006 17:22  |
| Eclipse User |
|
|
|
Originally posted by: maarten.bodewes.gmail.com
Keath Milligan wrote:
> arne anka wrote:
>
>> look into your project's properties->builders and disable the
>> "scanner configuration builder" -- maybe it helps?
>>
>> On Tue, 07 Mar 2006 17:06:38 +0100, Keath Milligan
>> <keath@keathmilligan.net> wrote:
>>
>>> Every time I build, I have to wait 40 seconds while Eclipse says it
>>> is updating project. Even if the build immediately fails with only a
>>> couple of lines of output, I still have this delay.
>>>
>>> I have all binary parsers turned off, indexing is off.
>>>
>>> If I wanted to try to hack CDT to disable this - could someone point
>>> me in the right direction?
>
>
> Yeah, I have that off too. Doesn't make a difference.
>
> It's a large project and it looks like Eclipse wants to walk through the
> entire tree every time you build for some reason.
I have the same problem. Especially if you even change the smallest
setting, for which an entire build is unnecessary it will rebuild all
the stuff. If I change 1 file, rebuild. Hopeless. Maybe I've gotten lazy
with Java, but even Visual Studio 6 seems to do a better job (on this).
Hopefully there is an answer, because I like this IDE (add-on) a lot. I
am trying to debug some C++ libraries for use in my Java binary usenet
reader (par2 & unrar libraries), but debugging them with the CDT proves
to be a lot harder than I had hoped for.
Maarten
|
|
|
| Re: "Updating project..." is killing me [message #165408 is a reply to message #165359] |
Tue, 07 March 2006 23:52 |
| Eclipse User |
|
|
|
Maarten Bodewes wrote:
> Keath Milligan wrote:
>> arne anka wrote:
>>
>>> look into your project's properties->builders and disable the
>>> "scanner configuration builder" -- maybe it helps?
>>>
>>> On Tue, 07 Mar 2006 17:06:38 +0100, Keath Milligan
>>> <keath@keathmilligan.net> wrote:
>>>
>>>> Every time I build, I have to wait 40 seconds while Eclipse says it
>>>> is updating project. Even if the build immediately fails with only
>>>> a couple of lines of output, I still have this delay.
>>>>
>>>> I have all binary parsers turned off, indexing is off.
>>>>
>>>> If I wanted to try to hack CDT to disable this - could someone point
>>>> me in the right direction?
>>
>>
>> Yeah, I have that off too. Doesn't make a difference.
>>
>> It's a large project and it looks like Eclipse wants to walk through
>> the entire tree every time you build for some reason.
>
> I have the same problem. Especially if you even change the smallest
> setting, for which an entire build is unnecessary it will rebuild all
> the stuff. If I change 1 file, rebuild. Hopeless. Maybe I've gotten lazy
> with Java, but even Visual Studio 6 seems to do a better job (on this).
>
> Hopefully there is an answer, because I like this IDE (add-on) a lot. I
> am trying to debug some C++ libraries for use in my Java binary usenet
> reader (par2 & unrar libraries), but debugging them with the CDT proves
> to be a lot harder than I had hoped for.
>
> Maarten
That sounds like it might be a different problem. I'm using a standard
make project and it's not rebuilding everything - the build itself is
completing quickly - but Eclipse is going through a long process of
refreshing the entire project tree - In my case, this means walking
through hundreds of directories and stat'ing thousands of files.
I now have a hack that bypasses this refresh, but it is a hack, and
depending on your project, it may cause other problems for you. In my
case, I don't care about the files the build produces (at least, I don't
want Eclipse to care that is), so not refreshing the project every time
I build isn't a problem. I can manually force a refresh if I need to.
Here is the hack:
* You'll probably need the SDK version of the CDT installed for this.
I'm using version 3.0.2.
* Switch to Plug-in Development Perspective.
* In the Plug-Ins list, right click on org.eclipse.cdt.make.core and
select Import | As Source Project
* Now switch to the Package Explorer and locate MakeBuilder.java under
src-cdtmakecore/org.eclipse.cdt.make.core/
* Down around line 230, find the lines:
monitor.subTask(MakeMessages.getString("MakeBuilder.Updating_project "));
//$NON-NLS-1$
try {
// Do not allow the cancel of the refresh, since the builder is external
// to Eclipse, files may have been created/modified and we will be
out-of-sync.
// The caveat is for hugue projects, it may take sometimes at every
build.
currProject.refreshLocal(IResource.DEPTH_INFINITE, null);
} catch (CoreException e) {
}
* Comment these lines out. As you can see, it looks like the developer
considered the impact of this operation on large projects.
* Click on the project name and Build All
* You can test your changes now if you like by using Run As | Eclipse
Application
* To export the new version of the plug-in, select Export... |Deployable
plug-ins and fragments
* Select "Directory" as the Export Destination and choose a temporary
directory to save the exported plug-in in and click Finish. This will
leave the new plugin in <dir>/plugins/org.eclipse.cdt.make.core
* Shut down Eclipse
Now you can replace the plugins/org.eclipse.cdt.make.core folder in your
Eclipse directory with the one you just created. Save the old one away
first though in case something doesn't work.
Like I said, this is a hack and it may cause you other issues depending
on how your project is structured. No warranties, your mileage may vary,
don't run with scissors and all that...
|
|
|
| Re: "Updating project..." is killing me [message #166784 is a reply to message #165408] |
Wed, 29 March 2006 12:53 |
| Eclipse User |
|
|
|
Me too!
Filed a bug at https://bugs.eclipse.org/bugs/show_bug.cgi?id=133881
Aleks
Keath Milligan wrote:
> Maarten Bodewes wrote:
>> Keath Milligan wrote:
>>> arne anka wrote:
>>>
>>>> look into your project's properties->builders and disable the
>>>> "scanner configuration builder" -- maybe it helps?
>>>>
>>>> On Tue, 07 Mar 2006 17:06:38 +0100, Keath Milligan
>>>> <keath@keathmilligan.net> wrote:
>>>>
>>>>> Every time I build, I have to wait 40 seconds while Eclipse says it
>>>>> is updating project. Even if the build immediately fails with only
>>>>> a couple of lines of output, I still have this delay.
>>>>>
>>>>> I have all binary parsers turned off, indexing is off.
>>>>>
>>>>> If I wanted to try to hack CDT to disable this - could someone
>>>>> point me in the right direction?
>>>
>>>
>>> Yeah, I have that off too. Doesn't make a difference.
>>>
>>> It's a large project and it looks like Eclipse wants to walk through
>>> the entire tree every time you build for some reason.
>>
>> I have the same problem. Especially if you even change the smallest
>> setting, for which an entire build is unnecessary it will rebuild all
>> the stuff. If I change 1 file, rebuild. Hopeless. Maybe I've gotten
>> lazy with Java, but even Visual Studio 6 seems to do a better job (on
>> this).
>>
>> Hopefully there is an answer, because I like this IDE (add-on) a lot.
>> I am trying to debug some C++ libraries for use in my Java binary
>> usenet reader (par2 & unrar libraries), but debugging them with the
>> CDT proves to be a lot harder than I had hoped for.
>>
>> Maarten
>
> That sounds like it might be a different problem. I'm using a standard
> make project and it's not rebuilding everything - the build itself is
> completing quickly - but Eclipse is going through a long process of
> refreshing the entire project tree - In my case, this means walking
> through hundreds of directories and stat'ing thousands of files.
>
> I now have a hack that bypasses this refresh, but it is a hack, and
> depending on your project, it may cause other problems for you. In my
> case, I don't care about the files the build produces (at least, I don't
> want Eclipse to care that is), so not refreshing the project every time
> I build isn't a problem. I can manually force a refresh if I need to.
>
> Here is the hack:
>
> * You'll probably need the SDK version of the CDT installed for this.
> I'm using version 3.0.2.
> * Switch to Plug-in Development Perspective.
> * In the Plug-Ins list, right click on org.eclipse.cdt.make.core and
> select Import | As Source Project
> * Now switch to the Package Explorer and locate MakeBuilder.java under
> src-cdtmakecore/org.eclipse.cdt.make.core/
> * Down around line 230, find the lines:
>
> monitor.subTask(MakeMessages.getString("MakeBuilder.Updating_project "));
> //$NON-NLS-1$
>
> try {
>
> // Do not allow the cancel of the refresh, since the builder is external
> // to Eclipse, files may have been created/modified and we will be
> out-of-sync.
> // The caveat is for hugue projects, it may take sometimes at every
> build.
>
> currProject.refreshLocal(IResource.DEPTH_INFINITE, null);
> } catch (CoreException e) {
> }
>
>
> * Comment these lines out. As you can see, it looks like the developer
> considered the impact of this operation on large projects.
> * Click on the project name and Build All
> * You can test your changes now if you like by using Run As | Eclipse
> Application
> * To export the new version of the plug-in, select Export... |Deployable
> plug-ins and fragments
> * Select "Directory" as the Export Destination and choose a temporary
> directory to save the exported plug-in in and click Finish. This will
> leave the new plugin in <dir>/plugins/org.eclipse.cdt.make.core
> * Shut down Eclipse
>
> Now you can replace the plugins/org.eclipse.cdt.make.core folder in your
> Eclipse directory with the one you just created. Save the old one away
> first though in case something doesn't work.
>
> Like I said, this is a hack and it may cause you other issues depending
> on how your project is structured. No warranties, your mileage may vary,
> don't run with scissors and all that...
|
|
|
Goto Forum:
Current Time: Wed Apr 30 10:36:20 EDT 2025
Powered by FUDForum. Page generated in 0.03977 seconds |
Home