Bug 274551

What version of eclipse-cdt are you using?  I am not seeing the exact behavior
you document (described later on).  Can you specify some more detail?

There is a feature of Eclipse for automatically building projects which is on by
default.  The feature causes a build to occur for a project when the project is
changed.  Unfortunately, this feature is global for the workspace.  I personally
would like to see this be project-specific so a project such as ours could turn
it off, however, this is not currently the case.

To turn off the feature, click on Project->Build Automatically if the check mark
is currently found there. You will have to manually start builds from that point
unless you reenable it (again by clicking the option).  It can also be changed
by using the Window->Preferences->Workspace menu.

When I create a new Autotools project (File->New->Other->C->GNU C Autotools
Project) with the automatic build feature on, I get a build occurring
immediately, which of course fails since there is no Makefile or any file in
general and no way to make the Makefile.  If I then edit a new C file, I am not
seeing a new build occur until I save the file or press ok or apply from the
project options menu.  If I create a brand new C file after that, I am seeing
the autobuild kick in. 

This undesired behavior likely has to do with the fact that we are categorized
as a ManagedMake Project which normally manages the Makefile for you (i.e.
adding a new file would require a change to the Makefile).  Ideally, I would
like to change the CDT behavior to only trigger the autobuild when an option has
actually changed or a file change has been confirmed via save.  This would still
be an annoyance until you get an actual Makefile or configuration files in place
so turning off autobuild makes the most sense.

Another change I see would be to return an error from Buildfile generation if no
configuration files are found and no Makefile currently exists.  This won't
solve your problem, but it will give a more meaningful error message.

With regards to turning off the builder, this won't help you.  The project is
still autobuilding and fails when it can't find a Makefile (i.e. after the
makefile building step).

(In reply to comment #1)
> What version of eclipse-cdt are you using?  I am not seeing the exact behavior
> you document (described later on).  Can you specify some more detail?

version specified in the bug report

> 
> There is a feature of Eclipse for automatically building projects which is on by
> default.  The feature causes a build to occur for a project when the project is
> changed.  Unfortunately, this feature is global for the workspace.  I personally
> would like to see this be project-specific so a project such as ours could turn
> it off, however, this is not currently the case.
> 
> To turn off the feature, click on Project->Build Automatically if the check mark
> is currently found there. You will have to manually start builds from that point
> unless you reenable it (again by clicking the option).  It can also be changed
> by using the Window->Preferences->Workspace menu.
> 

bug report specify that this is disabled

> When I create a new Autotools project (File->New->Other->C->GNU C Autotools
> Project) with the automatic build feature on, I get a build occurring
> immediately, which of course fails since there is no Makefile or any file in
> general and no way to make the Makefile.  If I then edit a new C file, I am not
> seeing a new build occur until I save the file or press ok or apply from the
> project options menu.  If I create a brand new C file after that, I am seeing
> the autobuild kick in. 
> 

i actually don't see anything happen in the eclipse built-in console, but can
see make processes launched by eclipse using "ps auxf"

the Makefile are present and well working, the problem is that C++ compilation
is CPU hungry

> This undesired behavior likely has to do with the fact that we are categorized
> as a ManagedMake Project which normally manages the Makefile for you (i.e.
> adding a new file would require a change to the Makefile).  Ideally, I would
> like to change the CDT behavior to only trigger the autobuild when an option has
> actually changed or a file change has been confirmed via save.  This would still
> be an annoyance until you get an actual Makefile or configuration files in place
> so turning off autobuild makes the most sense.
> 
> Another change I see would be to return an error from Buildfile generation if no
> configuration files are found and no Makefile currently exists.  This won't
> solve your problem, but it will give a more meaningful error message.
> 
> With regards to turning off the builder, this won't help you.  The project is
> still autobuilding and fails when it can't find a Makefile (i.e. after the
> makefile building step).

sorry to not be able to give you more details.

here are the steps i used if you care:

-use subclipse to download vlc from svn, creating the project as an autotools one.
-generate configure
-make the full thing
-open one file, trying to change a string to another one
-see that eclipse spawns make processes

(In reply to comment #2)
> (In reply to comment #1)
> > What version of eclipse-cdt are you using?  I am not seeing the exact behavior
> > you document (described later on).  Can you specify some more detail?
> 
> version specified in the bug report
> 

Sorry, not paying enough attention - virtual monday after a holiday.  Didn't
catch you were only using the update site.  We ship an eclipse-cdt-4.0.0-xxx rpm
package which has the CDT plus the Autotools plugin and 4.0.0-xxx was the number
I was asking for.

> > 
> > There is a feature of Eclipse for automatically building projects which is on by
> > default.  The feature causes a build to occur for a project when the project is
> > changed.  Unfortunately, this feature is global for the workspace.  I personally
> > would like to see this be project-specific so a project such as ours could turn
> > it off, however, this is not currently the case.
> > 
> > To turn off the feature, click on Project->Build Automatically if the check mark
> > is currently found there. You will have to manually start builds from that point
> > unless you reenable it (again by clicking the option).  It can also be changed
> > by using the Window->Preferences->Workspace menu.
> > 
> 
> bug report specify that this is disabled
> 

My bad again.  Saw what looked like an autobuild problem and didn't pay close
enough attention to the fact you said it was disabled.

> > When I create a new Autotools project (File->New->Other->C->GNU C Autotools
> > Project) with the automatic build feature on, I get a build occurring
> > immediately, which of course fails since there is no Makefile or any file in
> > general and no way to make the Makefile.  If I then edit a new C file, I am not
> > seeing a new build occur until I save the file or press ok or apply from the
> > project options menu.  If I create a brand new C file after that, I am seeing
> > the autobuild kick in. 
> > 
> 
> i actually don't see anything happen in the eclipse built-in console, but can
> see make processes launched by eclipse using "ps auxf"
> 
> the Makefile are present and well working, the problem is that C++ compilation
> is CPU hungry
> 
> > This undesired behavior likely has to do with the fact that we are categorized
> > as a ManagedMake Project which normally manages the Makefile for you (i.e.
> > adding a new file would require a change to the Makefile).  Ideally, I would
> > like to change the CDT behavior to only trigger the autobuild when an option has
> > actually changed or a file change has been confirmed via save.  This would still
> > be an annoyance until you get an actual Makefile or configuration files in place
> > so turning off autobuild makes the most sense.
> > 
> > Another change I see would be to return an error from Buildfile generation if no
> > configuration files are found and no Makefile currently exists.  This won't
> > solve your problem, but it will give a more meaningful error message.
> > 
> > With regards to turning off the builder, this won't help you.  The project is
> > still autobuilding and fails when it can't find a Makefile (i.e. after the
> > makefile building step).
> 
> sorry to not be able to give you more details.
> 
> here are the steps i used if you care:
> 
> -use subclipse to download vlc from svn, creating the project as an autotools one.
> -generate configure
> -make the full thing
> -open one file, trying to change a string to another one
> -see that eclipse spawns make processes

Thanks.  Will look at it closer.

Just let let you know the current progress.  I have recreated the problem.  I
know what is happening, but not why.  

The make call is due to the Autotools scanner attempting to find out the actual
include path and defined symbols used to build the file.  This information is
only available via the Makefile(s).  The scanner kicks off a make -n (dry-run)
with a what-if (-W) the file in question was changed so as to see the actual
compile options passed to it during compile.  This should only be done once when
the file is opened and cached from then on so the delay should all have been up
front when you opened the file.  The editor reconciler is automatically calling
the scanner interfaces (getIncludePaths(), getDefinedSymbols()) after changes
and unfortunately, this is keying off yet more make calls because the data
wasn't successfully cached from before and so on and so on.

Strange..

As for me make would execute each ~10 characters change with no saving i.e.

open,
start typing,
<bug, wait>
continue typing,
<bug, wait>
continue typing,
<bug, wait>
save,
type again,
<bug, wait>
bored,
quit :)

i'm glad to know i'm not cursed, maybe the issue will reveal itself in the future.

please note i don't use eclipse anymore (nor any ide, because eclipse was the
only one i tried that fit my needs).

so maybe a few users are actually seeing this behaviour hopefully :/

thanks,

Rafaël

I have posted a fix on the update site (Autotools 0.9.3).  Please try it out and
see if it fixes your problem.  The code was not prepared for the case whereby a
file did not participate in the build so the make returned no data of use.

bug still happens with 0.9.3 :(

here's an extract of ps xuf showing the make processes:

 7236 ?        Sl     3:50 ./eclipse
15295 ?        S      0:00  \_ make -n all MAKE=make -W main_interface.cpp
15298 ?        S      0:00      \_ make -W main_interface.cpp all-recursive
15299 ?        S      0:00          \_ /bin/sh -c failcom='exit 1'; \?for f in x
$MAKEFLAGS; do \?  case $f in \?    *=* | --[!k]*);; \?   
15314 ?        S      0:00              \_ /bin/sh -c failcom='exit 1'; \?for f
in x $MAKEFLAGS; do \?  case $f in \?    *=* | --[!k]*);; \
15315 ?        S      0:00                  \_ make -W main_interface.cpp all
15316 ?        S      0:00                      \_ /bin/sh -c failcom='exit 1';
\?for f in x $MAKEFLAGS; do \?  case $f in \?    *=* | --[!
15470 ?        S      0:00                          \_ /bin/sh -c failcom='exit
1'; \?for f in x $MAKEFLAGS; do \?  case $f in \?    *=* | 
15471 ?        S      0:00                              \_ make -W
main_interface.cpp all
15477 ?        S      0:00                                  \_ make -W
main_interface.cpp all-recursive
15478 ?        S      0:00                                      \_ /bin/sh -c
failcom='exit 1'; \?for f in x $MAKEFLAGS; do \?  case $f in 
15495 ?        S      0:00                                          \_ /bin/sh
-c failcom='exit 1'; \?for f in x $MAKEFLAGS; do \?  case $f
15496 ?        S      0:00                                              \_ make
-W main_interface.cpp all
15497 ?        S      0:00                                                  \_
/bin/sh -c set fnord $MAKEFLAGS; amf=$2; targets=`\?z=$(top_
15498 ?        S      0:00                                                     
\_ /bin/sh -c set fnord $MAKEFLAGS; amf=$2; targets=`\?z=$(
15499 ?        S      0:00                                                     
    \_ /bin/sh -c set fnord $MAKEFLAGS; amf=$2; targets=`\?
15500 ?        R      0:00                                                     
        \_ /bin/sh ../../../vlc-config --list plugin


i don't understand why all these things are needed :/
maybe that can be useful: no Makefile.am or Makefile.in are part of the project
(i.e. listed in the file browser) as they are generated by autogen.sh)
except ./Makefile.am (at the root folder)

i forget to precise that this doesn't happen anymore on editing, that first part
is fixed.

it now happens when opening (!!!), and when saving the edited file.

(In reply to comment #7)
> bug still happens with 0.9.3 :(
> 
> here's an extract of ps xuf showing the make processes:
> 

> i don't understand why all these things are needed :/
> maybe that can be useful: no Makefile.am or Makefile.in are part of the project
> (i.e. listed in the file browser) as they are generated by autogen.sh)
> except ./Makefile.am (at the root folder)

The reason this occurs is that we need to know the actual include path that is
used to build the file in question.  We need this information for two different
reasons:

  1. the indexer is trying to reconcile types/variables/function prototypes
     in the file you are editing (e.g. you have the wrong number of args to
     a function that is declared in XXX.h).  Well, it needs to know how to
     find XXX.h.  There might be forty of them out there and your file is
     using a particular one properly.

  2. the outline view allows you to click on a header file and open that
     particular header file.  Well, that is useless if the editor doesn't
     know where to find the file in question.
 
You have to remember that neither the CDT nor Autotools knows anything about
your project.  The way to get the actual include path is by running down the
Makefile chain.  For example, the top-level Makefile might specify -I
/xxxx/include is passed down to a subdir.  That subdir's Makefile could append
-I /yyyy/include and so on and so on.  The bottom level Makefile could choose to
add to this set of flags or simply ignore the previous settings and specify its
own path.

Currently, the way this information is being extracted is to run the top-level
Makefile with the options -n (don't really run) and -W (pretend the following
file has changed).  When each Makefile kicks off another make, you see a new
process.  Admittedly, this does not scale well for such a complex project
because we actually just want to go down the one directory chain directly (we
don't care about building everything - just the one file).  Ideally, a parser
that could figure this out would be the best answer, but one currently is not in
place.

I definitely want to look at how best to do this as I want this plugin to scale
for all types of projects.  A simple idea would be to provide an option to turn
dynamic include scanning off and allow the user to specify a fixed path to look in.

Situation number 1 above occurs when the indexer is on.  You can work around
that by turning off the indexer for the project.  By default, it is on and set
to the fast indexer.

Situation number 2 should be lazy and only occur when it is needed (i.e. you
actually click on the header file).

In either case, the Autotools plugin is caching the information so the resultant
makes to extract the information should only occur the one time.  The fix I made
was to ensure that the data was properly cached and that we properly recognized
if a file was not even part of the build.

eclipse-cdt-3.1.2-8.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

> The reason this occurs is that we need to know the actual include path that is
> used to build the file in question.  We need this information for two different
> reasons:
> 
>   1. the indexer is trying to reconcile types/variables/function prototypes
>      in the file you are editing (e.g. you have the wrong number of args to
>      a function that is declared in XXX.h).  Well, it needs to know how to
>      find XXX.h.  There might be forty of them out there and your file is
>      using a particular one properly.

I tryed disabling the indexer, same problem.
More over, i'm just editing C comments, and the file compile without warning.

>   2. the outline view allows you to click on a header file and open that
>      particular header file.  Well, that is useless if the editor doesn't
>      know where to find the file in question.

there is some headers in the outline view, but i would suppose they are
remembered, and checked only if i add an #include in the file, or if one of the
headers changed.

> You have to remember that neither the CDT nor Autotools knows anything about
> your project.  The way to get the actual include path is by running down the
> Makefile chain.  For example, the top-level Makefile might specify -I
> /xxxx/include is passed down to a subdir.  That subdir's Makefile could append
> -I /yyyy/include and so on and so on.  The bottom level Makefile could choose to
> add to this set of flags or simply ignore the previous settings and specify its
> own path.
> 
> Currently, the way this information is being extracted is to run the top-level
> Makefile with the options -n (don't really run) and -W (pretend the following
> file has changed).  When each Makefile kicks off another make, you see a new

the -n option isn't recursively passed to make subprocesses that may be the
problem :/

> process.  Admittedly, this does not scale well for such a complex project
> because we actually just want to go down the one directory chain directly (we
> don't care about building everything - just the one file).  Ideally, a parser
> that could figure this out would be the best answer, but one currently is not in
> place.

:/ i think it's hard to do it that way

> I definitely want to look at how best to do this as I want this plugin to scale
> for all types of projects.  A simple idea would be to provide an option to turn
> dynamic include scanning off and allow the user to specify a fixed path to
look in.
> 
> Situation number 1 above occurs when the indexer is on.  You can work around
> that by turning off the indexer for the project.  By default, it is on and set
> to the fast indexer.

set it off

> Situation number 2 should be lazy and only occur when it is needed (i.e. you
> actually click on the header file).

no, happens also while editing comments

> In either case, the Autotools plugin is caching the information so the resultant
> makes to extract the information should only occur the one time.  The fix I made
> was to ensure that the data was properly cached and that we properly recognized
> if a file was not even part of the build.

the file i'm editing is always part of the build

(In reply to comment #10)
> eclipse-cdt-3.1.2-8.fc7 has been pushed to the Fedora 7 testing repository. 
If problems still persist, please make note of it in this bug report.

Hi botty bot :)

sorry but I don't use fedora

(In reply to comment #11)
> > The reason this occurs is that we need to know the actual include path that is
> > used to build the file in question.  We need this information for two different
> > reasons:
> > 
> >   1. the indexer is trying to reconcile types/variables/function prototypes
> >      in the file you are editing (e.g. you have the wrong number of args to
> >      a function that is declared in XXX.h).  Well, it needs to know how to
> >      find XXX.h.  There might be forty of them out there and your file is
> >      using a particular one properly.
> 
> I tryed disabling the indexer, same problem.
> More over, i'm just editing C comments, and the file compile without warning.
> 

An editor isn't necessarily that smart when it reconciles changes to the file. 
The reconciler might just call the scanner regardless of the changes.

> >   2. the outline view allows you to click on a header file and open that
> >      particular header file.  Well, that is useless if the editor doesn't
> >      know where to find the file in question.
> 
> there is some headers in the outline view, but i would suppose they are
> remembered, and checked only if i add an #include in the file, or if one of the
> headers changed.
> 

The Autotools scanner is currently not saving the info across closes/opens of
the file/project/workspace.  So I do expect it to occur once each time you open
the file, but you are seeing a second set of makes occurring at save time
(correct?).

> > You have to remember that neither the CDT nor Autotools knows anything about
> > your project.  The way to get the actual include path is by running down the
> > Makefile chain.  For example, the top-level Makefile might specify -I
> > /xxxx/include is passed down to a subdir.  That subdir's Makefile could append
> > -I /yyyy/include and so on and so on.  The bottom level Makefile could choose to
> > add to this set of flags or simply ignore the previous settings and specify its
> > own path.
> > 
> > Currently, the way this information is being extracted is to run the top-level
> > Makefile with the options -n (don't really run) and -W (pretend the following
> > file has changed).  When each Makefile kicks off another make, you see a new
> 
> the -n option isn't recursively passed to make subprocesses that may be the
> problem :/
>

Actually, no, I have confirmed that it does the right thing by running make -n
directly from the command line on the vlc/build directory.  It is only listing
the commands.  The problem is that this process takes over 11 seconds to
complete with the complexity of this project.

Now, I did think of a cheat to scale that number way down.  If I chmod -x on all
build subdirs I am not interested in, working down to the subdir of interest,
and I also use the -k flag (keep going on error), I get that number down to 1.6
secs which would perhaps be reasonable when the file is opened.
 
> > process.  Admittedly, this does not scale well for such a complex project
> > because we actually just want to go down the one directory chain directly (we
> > don't care about building everything - just the one file).  Ideally, a parser
> > that could figure this out would be the best answer, but one currently is not in
> > place.
> 
> :/ i think it's hard to do it that way
> 

Yes, I agree.  See my cheat above.

> > I definitely want to look at how best to do this as I want this plugin to scale
> > for all types of projects.  A simple idea would be to provide an option to turn
> > dynamic include scanning off and allow the user to specify a fixed path to
> look in.
> > 
> > Situation number 1 above occurs when the indexer is on.  You can work around
> > that by turning off the indexer for the project.  By default, it is on and set
> > to the fast indexer.
> 
> set it off
> 
> > Situation number 2 should be lazy and only occur when it is needed (i.e. you
> > actually click on the header file).
> 
> no, happens also while editing comments
>

That means the reconciler is calling the scanner, but you said earlier you are
not seeing it invoked while editing anymore.  Is this behavior from before the fix??

> > In either case, the Autotools plugin is caching the information so the resultant
> > makes to extract the information should only occur the one time.  The fix I made
> > was to ensure that the data was properly cached and that we properly recognized
> > if a file was not even part of the build.
> 
> the file i'm editing is always part of the build

> That means the reconciler is calling the scanner, but you said earlier you are
> not seeing it invoked while editing anymore.  Is this behavior from before the
fix??

yes, earlier the scanner would run if i edited only comments

eclipse-cdt-3.1.2-8.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Reopening.  The scanner will be changed to use the Standard Make logic.  A
temporary work-around will be put in to turn off the scanner unless specifically
enabled.  The work-around will remain in place until the replacement scanner is
available.

Two things.  First of all, there have been some editor performance fixes in the
CDT 4.0.1 so please try upgrading.  Secondly, I have posted an Autotools update:
0.9.5.1 on the update site and will shortly be building an F8 build with it.  It
has a work-around for the scanner issue whereby by default, the make -w -n
scanner mechanism will be disabled.  The include path will end being the default
gcc include path.  For the Outline view, header files not found on the default
include path will be searched for in the project.  For those projects that use
additional external include paths or need the correct defined symbols from the
Makefile or have a precedence issue with the default include path, a new
Autotools property tab has been added: Project -> Properties -> C/C++ Build ->
Settings -> Autotools.  This allows one to turn the option back on.  This is a
temporary work-around until the proper Standard Make logic can be merged into
the ManagedBuild base that Autotools sits on.

Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
rawhide.
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Is this issue still happening?

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

This is no longer happening.