New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request for supporting input file suffix ".i", ".ii", ".mi", "mii" #3365

Closed
weitjong opened this Issue Apr 16, 2015 · 9 comments

Comments

Projects
None yet
2 participants
@weitjong
Contributor

weitjong commented Apr 16, 2015

These input files are output of preprocessing step from C, C++, Objective-C, Objective-C++ source files, respectively. The emcc/em++ should be able to handle them as input file, except that they should not be preprocessed again internally.

Use case: I am trying to use ccache with Emscripten compiler toolchain. It does not work due to this error.

 ERROR root: /home/weitjong/.ccache/tmp/testCCompi.tmp.igloo.13910.i:
  Input file has an unknown suffix, don't know what to do with it!

Apparently ccache has preprocessed the input source file in its own internal step to check whether a cache is hit. If it misses then it calls the actual compiler toolchain to do the actual work. But since it has already a preprocessed input file with the ".i" extension, it passes this to emcc and hence the error.

In my build system I have successfully enabled ccache for MinGW, Raspberry-Pi, and Android compiler toolchains. Emscripten compiler toolchain should not be any difference when this feature request is implemented. Thanks.

@weitjong

This comment has been minimized.

Show comment
Hide comment
@weitjong

weitjong Apr 16, 2015

Contributor

BTW, these input file suffix are supported by Clang and GCC. Obviously the other cross-compiling toolchains that I mentioned earlier support these suffixes too.

Contributor

weitjong commented Apr 16, 2015

BTW, these input file suffix are supported by Clang and GCC. Obviously the other cross-compiling toolchains that I mentioned earlier support these suffixes too.

weitjong added a commit to urho3d/Urho3D that referenced this issue Apr 16, 2015

@weitjong

This comment has been minimized.

Show comment
Hide comment
@weitjong

weitjong Apr 17, 2015

Contributor

I have made a little progress today to enable ccache support for Emscripten compiler toolchain. Fortunately ccache provides an option to fallback to always pass the original input source file regardless to the actual compiler. This is done by exporting 'CCACHE_CPP2=1' environment variable. So far so good, until Emscripten compiler toolchain hit another error (i.e. it gave exit status 254) when it encountered source file with precompiled header enabled. For the PCH to work, the build system has to pass the exact same compiler defines and flags at the time when precompiling the header and also at the time when using the precompiled header. My build system has done so (as it works for all the other cross-compiling toolchains with ccache and PCH support enabled). I have turned on em++ "-v" option to see what's going on and here is my observation from the stacktrace. When em++ is invoked with '-E' to just run the preprocessor step, it does not produce the same list of compiler flags as when it is invoked with '-c' option. What break the PCH usage is the missing -std=c++03 compiler flag. I workaround the problem by explicitly adding this missing flag in my build system and now I can make ccache works with Emscripten!

Below are the complete list of program argument discrepencies between '-E' and '-c' when calling the underlying clang-3.4:

  • -Wno-warn-absolute-paths not removed
  • missing -std=c++03
  • missing -isystem/home/weitjong/SDKs/emsdk_portable/emscripten/master/system/include/SDL
  • missing -disable-llvm-optzns

It looks like the emcc python script has a bug in handling the '-E' option and should be reported as another issue but I decided not to since it is related to this issue. Let me know if you want me to raise a new one though.

Contributor

weitjong commented Apr 17, 2015

I have made a little progress today to enable ccache support for Emscripten compiler toolchain. Fortunately ccache provides an option to fallback to always pass the original input source file regardless to the actual compiler. This is done by exporting 'CCACHE_CPP2=1' environment variable. So far so good, until Emscripten compiler toolchain hit another error (i.e. it gave exit status 254) when it encountered source file with precompiled header enabled. For the PCH to work, the build system has to pass the exact same compiler defines and flags at the time when precompiling the header and also at the time when using the precompiled header. My build system has done so (as it works for all the other cross-compiling toolchains with ccache and PCH support enabled). I have turned on em++ "-v" option to see what's going on and here is my observation from the stacktrace. When em++ is invoked with '-E' to just run the preprocessor step, it does not produce the same list of compiler flags as when it is invoked with '-c' option. What break the PCH usage is the missing -std=c++03 compiler flag. I workaround the problem by explicitly adding this missing flag in my build system and now I can make ccache works with Emscripten!

Below are the complete list of program argument discrepencies between '-E' and '-c' when calling the underlying clang-3.4:

  • -Wno-warn-absolute-paths not removed
  • missing -std=c++03
  • missing -isystem/home/weitjong/SDKs/emsdk_portable/emscripten/master/system/include/SDL
  • missing -disable-llvm-optzns

It looks like the emcc python script has a bug in handling the '-E' option and should be reported as another issue but I decided not to since it is related to this issue. Let me know if you want me to raise a new one though.

kripken added a commit that referenced this issue Apr 17, 2015

@kripken

This comment has been minimized.

Show comment
Hide comment
@kripken

kripken Apr 17, 2015

Owner

Ok, .i,.ii etc suffixes are fixed on incoming.

I think I understand the issues in the last comment, but I'm not 100% sure on how to test to make sure they are fixed. What are the very concrete steps to take to see the issue?

Owner

kripken commented Apr 17, 2015

Ok, .i,.ii etc suffixes are fixed on incoming.

I think I understand the issues in the last comment, but I'm not 100% sure on how to test to make sure they are fixed. What are the very concrete steps to take to see the issue?

@kripken

This comment has been minimized.

Show comment
Hide comment
@kripken

kripken Apr 17, 2015

Owner

(No need for a new issue.)

Owner

kripken commented Apr 17, 2015

(No need for a new issue.)

@weitjong

This comment has been minimized.

Show comment
Hide comment
@weitjong

weitjong Apr 18, 2015

Contributor

, but I'm not 100% sure on how to test to make sure they are fixed. What are the very concrete steps to take to see the issue?

I am not sure you are asking for the minimal steps to reproduce the '-E' vs '-c' program argument discrepancies or the minimal steps to reproduce my actual issue (ccache + PCH + emscripten). I will just provide now the former as it is easier to do:

  1. em++ -v -c -Wno-warn-absolute-paths tests/hello_world.cpp -o /dev/null 2>/tmp/dash-c.out
  2. em++ -v -E -Wno-warn-absolute-paths tests/hello_world.cpp -o /dev/null 2>/tmp/dash-E.out
  3. diff dash-c.out dash-E.out

Barring some differences in the diff output that are rightfully exist between '-c' and '-E' options, you can clearly see the problem with emcc handling on the '-E' option. Notably:

  1. The Emscripten specific flag -Wno-warn-absolute-paths is not removed.
  2. The -std=c++03 is not consistently added.

Interestingly, the dash-c.out also shows below in this simple test case.

-isystem/home/weitjong/SDKs/emsdk_portable/emscripten/master/system/include/SDL

Although I did not specify USE_SDL setting in the above minimal steps. I guess that is yet another issue.

Contributor

weitjong commented Apr 18, 2015

, but I'm not 100% sure on how to test to make sure they are fixed. What are the very concrete steps to take to see the issue?

I am not sure you are asking for the minimal steps to reproduce the '-E' vs '-c' program argument discrepancies or the minimal steps to reproduce my actual issue (ccache + PCH + emscripten). I will just provide now the former as it is easier to do:

  1. em++ -v -c -Wno-warn-absolute-paths tests/hello_world.cpp -o /dev/null 2>/tmp/dash-c.out
  2. em++ -v -E -Wno-warn-absolute-paths tests/hello_world.cpp -o /dev/null 2>/tmp/dash-E.out
  3. diff dash-c.out dash-E.out

Barring some differences in the diff output that are rightfully exist between '-c' and '-E' options, you can clearly see the problem with emcc handling on the '-E' option. Notably:

  1. The Emscripten specific flag -Wno-warn-absolute-paths is not removed.
  2. The -std=c++03 is not consistently added.

Interestingly, the dash-c.out also shows below in this simple test case.

-isystem/home/weitjong/SDKs/emsdk_portable/emscripten/master/system/include/SDL

Although I did not specify USE_SDL setting in the above minimal steps. I guess that is yet another issue.

@weitjong

This comment has been minimized.

Show comment
Hide comment
@weitjong

weitjong Apr 18, 2015

Contributor

And when throwing --bind emcc flag into the mix then the emcc '-E' option failed to run all together.

em++ -v -E --bind -Wno-warn-absolute-paths tests/hello_world.cpp -o /dev/null
clang-3.4: error: unsupported option '--bind'
clang version 3.5.0 
Target: asmjs-unknown-emscripten
Thread model: posix

I think the underlying root cause is the same as above, i.e. emcc fails to remove Emscripten specific compiler flags before passing to clang. If it were then the call would have been successful but the c++ standard (now should be changed to -std=c++11 due embind) would be missing in '-E ' handling.

Contributor

weitjong commented Apr 18, 2015

And when throwing --bind emcc flag into the mix then the emcc '-E' option failed to run all together.

em++ -v -E --bind -Wno-warn-absolute-paths tests/hello_world.cpp -o /dev/null
clang-3.4: error: unsupported option '--bind'
clang version 3.5.0 
Target: asmjs-unknown-emscripten
Thread model: posix

I think the underlying root cause is the same as above, i.e. emcc fails to remove Emscripten specific compiler flags before passing to clang. If it were then the call would have been successful but the c++ standard (now should be changed to -std=c++11 due embind) would be missing in '-E ' handling.

@kripken

This comment has been minimized.

Show comment
Hide comment
@kripken

kripken Apr 20, 2015

Owner

Ok, this should now be fixed on incoming.

Owner

kripken commented Apr 20, 2015

Ok, this should now be fixed on incoming.

@weitjong

This comment has been minimized.

Show comment
Hide comment
@weitjong

weitjong Apr 21, 2015

Contributor

Thanks Alon. That was fast.

BTW, the '.i' should be treated as C file ending.

Contributor

weitjong commented Apr 21, 2015

Thanks Alon. That was fast.

BTW, the '.i' should be treated as C file ending.

kripken added a commit that referenced this issue Apr 21, 2015

@kripken

This comment has been minimized.

Show comment
Hide comment
@kripken

kripken Apr 21, 2015

Owner

Thanks, I fixed that as well.

Owner

kripken commented Apr 21, 2015

Thanks, I fixed that as well.

@kripken kripken closed this Apr 21, 2015

weitjong added a commit to urho3d/Urho3D that referenced this issue Apr 22, 2015

Enable ccache support for Emscripten (incoming) without the caveat.
The upstream issue kripken/emscripten#3365 has been fixed now in Emscripten's incoming branch.

urho3d-travis-ci added a commit to urho3d/urho3d.github.io that referenced this issue Apr 22, 2015

Travis CI: site documentation update at 2015-04-22 02:46:32 UTC.
Commit: urho3d/Urho3D@f2b21ee

Message: Enable ccache support for Emscripten (incoming) without the caveat.
The upstream issue kripken/emscripten#3365 has been fixed now in Emscripten's incoming branch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment