#303 Quex generates header that includes itself without guard

[Jędrzej Dudkiewicz]

This is copy of [question that I asked onstackoverflow. Basically after generating lexer from attached file using latest version (0.69.4) installed from .deb I get header file having single line which is #include <the file="" same="">. This prevents compilation of source code. I tried both using:</the>

quex -i ../lexer.qx -o zs_expr_eng --output-directory . --foreign-token-id-file ../../grammar/grammar.h --token-id-prefix RULE_TOKEN_ --fes xx

and

quex -i ../lexer.qx -o zs_expr_eng --output-directory . --token-id-prefix RULE_TOKEN_ --fes xx

but final result is identical in both cases.

[Jędrzej Dudkiewicz]

It seems that generator breaks down if --fes option is used. Without it everything (after required changes) everything works as expected. But it means that --fes option is probably broken.

[Frank-Rene Schäfer]

The issue has been identified. It was due to a confusion between header files and header file implementations. It does not occur, since the default extensions deal with it properly, already.
Regression test is implemented, next release (very soon) will contain the fix.

[Frank-Rene Schäfer]

Resolved in 0.70.0; Please confirm.

[Jędrzej Dudkiewicz]

Unfortunately same thing happens after installing 0.70.0. I'll veryfiy everything once again and prepare sources to reproduce this issue. Sadly I can't prioritize it as I can live without --fes option, but it would be nice to have consistent file naming scheme.

[Jędrzej Dudkiewicz]

Sorry for taking THREE MONTHS to answer, but I had to take a great detour. Attached file quex-fes-error.txz is a full example of what goes wrong. You can build this example by running build.sh scipt available in the archive. You should probably change CXX and CC to something sensible, I compiled g++-9.2.0 myself and use it extensively. I compiled on Debian and have quex installed from 0.70 deb.

[Jędrzej Dudkiewicz]

Hello, were you maybe able to look at this? Sorry again for giving feedback after so much time, but I really were unable to do it earlier.

[Jędrzej Dudkiewicz]

Hi, were you able to look at this?

[Frank-Rene Schäfer]

Did you try 0.70.0?
I was not able to reproduce the error.

[Jędrzej Dudkiewicz]

Yes, original bug was with 0.69.4, but later example was compiled with 0.70.0. Have you tried generating lexer from attached files? I no longer use --fes option, but aforementioned example definitely displayed described behaviour.

[Frank-Rene Schäfer]

You're talking about quex-fes-error.tgz? I will try again, this (Germany) afternoon.

[Jędrzej Dudkiewicz]

Yes, exactly this file. Sorry that it took to long to respond, I don't know why I did not receive email with notification about your question.

[Frank-Rene Schäfer]

I am sorry, but I still cannot reproduce the issue.

[Jędrzej Dudkiewicz]

Well, I could reproduce it each time, so probably this is something in my environment. I use Debian 9.11, and have two version of python: 2.7.13 and 3.5.3.

If this doesn't help, then I think this bug can be pretty safely ignored - I already moved away from --fes switch and if nobody else experiences this problem then maybe it is some peculiar part of my build environment - though I have to admit that I had it on two older Debian versions and currently have on two separate environments - but they have lots and lots of libraries, plugins, cross-compilers and other tools installed (and all older system had it too), so maybe there is something repeating itself on all machines.

Also note that since we use do not use python in our company it can be simply problem of some package being really old - Debian isn't exactly known for being on the bleeding edge when it comes to packaging software (for Christ's sake, 9.11 still ships with gcc 6.3.0, which is no longer supported AFAIK!).

Anyway, thanks for your help and great lexer :)

[Frank-Rene Schäfer]

Are you sure, that you invoke the right version of quex? Look at your QUEX_PATH, too.

[Jędrzej Dudkiewicz]

Yes, definitely. There is only one version of quex on my machine, and if you'll look at build.sh script in package that I uploaded earlier you will find that QUEX_PATH is there, explicitly exported and set to where quex is installed - I think it points exactly where it should.

I will try to install newest Debian or Ubuntu, update all Python packages and try to build it - I think outdated Python can be a reason for failure - I don't know why and how, but this is the only thing I really haven't tried.

[Frank-Rene Schäfer]

No, I do not thinks it is python.
I want to get this sorted out. If you can send me a minimalist example to reproduce this, I will look into it again.