(In reply to comment #0)
> Building from latest git (8cbe699c0dd9b8d4accf1eaa570689f813aa3c2f) and it
> fails with the following error:
> 
> In file included from glsl_parser_extras.h:35:0,
>                  from ast.h:30,
>                  from glsl_parser.yy:29:
> glsl_symbol_table.h:32:34: fatal error: program/symbol_table.h: No such file or
> directory
> compilation terminated.
> make[2]: *** [glsl_parser.o] Error 1

I've run into this error too, and I think it means you have an old version of glsl_lexer.cc and glsl_parser.cc left over from a different build.  Try deleting
src/glsl/glsl_lexer.cc and src/glsl/glsl_parser.cc and then build again.

You should run `git clean -dfx` and rerun autogen.sh after changes to Mesa.

(In reply to comment #2)
> You should run `git clean -dfx` and rerun autogen.sh after changes to Mesa.

I'll try it tomorrow. However, I'm suprised since I always do a "make realclean" before getting new commits and compiling. Shouldn't it clean everything by itself? Or should I run "git clean -dfx" instead or in combination with "make realclean"?

If it is necessary to run "git clean -dfx" after every change
to mesa that means nothing but that the build system is broken
and should be fixed.

knut

(In reply to comment #2)
> You should run `git clean -dfx` and rerun autogen.sh after changes to Mesa.

I run into this error too.
Running git clean -dfx doesn't solve this issue.
Installing a new mesa clone still shows this compilation error.
Building mesa-8.0-rc2 too does not work, the compilation ends with the
same error.

(In reply to comment #4)
> If it is necessary to run "git clean -dfx" after every change
> to mesa that means nothing but that the build system is broken
> and should be fixed.

How do you expect `make clean` (ie, the build system) to know to clean files that have been removed from git?

(In reply to comment #5)
> (In reply to comment #2)
> > You should run `git clean -dfx` and rerun autogen.sh after changes to Mesa.
> 
> I run into this error too.
> Running git clean -dfx doesn't solve this issue.
> Installing a new mesa clone still shows this compilation error.
> Building mesa-8.0-rc2 too does not work, the compilation ends with the
> same error.

Huh. If you can reproduce it with Mesa-8.0-rc then I'm off the hook. :)

(I cannot reproduce the problem.)

I tried using "git clean -dfx" as suggested, which means I run both git clean
-dfx and make realclean. The build ends up with an error anyway. However, the
error is not the same:

In file included from ../../src/mesa/main/api_exec_es2_remap_helper.h:29:0,
                 from main/api_exec_es2.c:2222:
../../src/mesa/main/remap.h:34:1: error: expected ‘)’ before ‘struct’


I'm building with "make -j", but if I just run "make" after that error to retry
where it exited, I'm able to finish the build. So there still is a problem with
the build. I tried building without "-j" from the start and it ends up
correctly on the first run.

About what I'm experiencing, I think I'm now dealing with a different bug.
However, it seems the original problem shouldn't occure in the first place and
we should find why files are not generated as they should if they are different
from the ones already available. Finally, one of us seems to be experiencing
the same problem, but the proposed solution doesn't work, so I think we should
also ask ourselves why. What should be the next step to dig deeper?

After a closer look I noticed that the error I get isn't exactly the same as the one mentioned by Alexandre Demers:
---
In file included from glsl_parser_extras.h:35:0,
                 from ast.h:30,
                 from glsl_lexer.ll:27:
glsl_symbol_table.h:29:15: fatal error: new: No such file or directory
compilation terminated.
make[2]: *** [glsl_lexer.o] Error 1
---

(In reply to comment #6)
> (In reply to comment #4)
> > If it is necessary to run "git clean -dfx" after every change
> > to mesa that means nothing but that the build system is broken
> > and should be fixed.
> 
> How do you expect `make clean` (ie, the build system) to know to clean files
> that have been removed from git?

First of all: git clean -dfx helped in my case.

What should a "make distclean/realclean" do? Up to now I expected a result according to http://www.gnu.org/software/automake/manual/html_node/Clean.html - iow delete anything generated by autogen.sh and make.

Obviously that is not the case. After a mesa build with my configuration parameters (only i915) "make realclean" fails to delete 360 files generated during the build process, 20 of these are *.h, *.c or *.h files. I´d call that broken.

Granted, a "make clean/realclean/distclean" might fail to delete a stale file that does not belong to the current version of the sources, but how could that cause any harm? Such a file should not be referenced in any Makefile and so it should be simply ignored.

(In reply to comment #8)
> After a closer look I noticed that the error I get isn't exactly the same as
> the one mentioned by Alexandre Demers:
> ---
> In file included from glsl_parser_extras.h:35:0,
>                  from ast.h:30,
>                  from glsl_lexer.ll:27:
> glsl_symbol_table.h:29:15: fatal error: new: No such file or directory
> compilation terminated.
> make[2]: *** [glsl_lexer.o] Error 1
> ---

Uh.  Sounds like it's not using a C++ compiler...

(In reply to comment #10)

> Uh.  Sounds like it's not using a C++ compiler...

I was using gcc-4.7 version 4.7-20120205-1:amd64 from Debian Experimental.
Reverting to gcc-4.6 (4.6.2-12) solves this issue.

The issue started some days ago presumably after the latest upgrade of gcc-4.7.

Correction:

I mentioned a wrong gcc-4.7 version.
I was using gcc-4.7 version 4.7-20120129-1 which caused the issue,
after upgrading to 4.7-20120205-1 (debian experimental) [trunk revision 183903]
no more compilation problems.

Sounds like a transitory GCC 4.7 issue then.  Can we close this, or is someone still having trouble?

Should we open differents bugs if "make realclean" doesn't clean everything as it should? If so, then I think we can close this bug.

(In reply to comment #14)
> Should we open differents bugs if "make realclean" doesn't clean everything as
> it should? If so, then I think we can close this bug.

Yes.