header file not found #65
Comments
|
Thanks for the link to the actual repo/workflow, that is most helpful! With that said, your extensive CMake presets are a bit difficult to follow for such a simple test. There may be a problem with docker file system not seeing fmt/format.h in the runner's file system. If you need to use a custom env (typically for non-std libs or cross-compiling), then I'd recommend trying the windows example workflow in the readme. You don't need to use windows, you just need to understand how to use this action's source as a python installable package. I put together an example based on the snippet you posted in the OP: on:
pull_request:
types: [opened, reopened] # let PR-synchronize events be handled by push events
push:
jobs:
cpp-linter:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-python@v3
- name: Install clang-tools
uses: KyleMayes/install-llvm-action@v1
with:
version: 14
# specifying an install path is not required for ubuntu
# directory: ${{ runner.temp }}/llvm
- name: Install linter python package
run: python3 -m pip install git+https://github.com/cpp-linter/cpp-linter-action@v1
- name: run linter as a python package
id: linter
run: cpp-linter --version=14 --style=file --tidy-checks='' --database=build/ci-linux-clang
- name: Fail fast?!
if: steps.linter.outputs.checks-failed > 0
run: echo "Some files failed the linting checks!"
# for actual deployment
# run: exit 1 |
|
BTW, that conan pkg mgr is a cool tool. Thanks for the lead on that! |
- changed main.cpp to trigger - using cpp-linter python package [header file not found #65]( cpp-linter/cpp-linter-action#65) - in cmake.yml, using hashFiles('conanfile.txt') since it's on root
- changed main.cpp to trigger - using cpp-linter python package [header file not found #65]( cpp-linter/cpp-linter-action#65) - in cmake.yml, using hashFiles('conanfile.txt') since it's on root
|
@ibis-hdl Don't forget the step that installs LLVM: - name: Install clang-tools
uses: KyleMayes/install-llvm-action@v1
with:
version: 14This is important because you're not using the docker container for this action since you changed to using this action's python source code on the runner file system. |
- changed main.cpp to trigger - using cpp-linter python package [header file not found #65]( cpp-linter/cpp-linter-action#65) - in cmake.yml, using hashFiles('conanfile.txt') since it's on root
- changed main.cpp to trigger - using cpp-linter python package [header file not found #65]( cpp-linter/cpp-linter-action#65) - in cmake.yml, using hashFiles('conanfile.txt') since it's on root
- changed main.cpp to trigger - using cpp-linter python package [header file not found #65]( cpp-linter/cpp-linter-action#65) - in cmake.yml, using hashFiles('conanfile.txt') since it's on root
- changed main.cpp to trigger - using cpp-linter python package [header file not found #65]( cpp-linter/cpp-linter-action#65) - in cmake.yml, using hashFiles('conanfile.txt') since it's on root
Thanks, even I use Ubuntu-22.04 which has bundled clang-14 (and which seems to work)?? Anyway, I've changed the action to use the installable package a121d28 and run into same issue: I'm also confused about |
|
Oh I didn't see that step in your workflow (hidden in the diff).
TL;DR don't worry about that.The debug statement is just telling me what folders it is crawling. In this instance it is actually looking for files that were explicitly not ignored with the ignored parent folder...
Believe it or not I think we're getting closer to solving this. Now that you've got the action running in your runner's File system, it is just a matter of making sure clang-tidy knows where to look for
|
Conan builds the binaries and installs them into an own directory, e.g. on Linux using conan.cmake one is able to use the generated CMake Find... (concrete which explains, why the CMake's generated compile_commands.json: It seems to me that this isn't found or even not used; otherwise it would find the include/lib directories. |
|
I'm trying to build your project locally, but the CMake setup is so complex that I'm having trouble. I did notice a rather slight difference between the example in the conan README and your project's find_package(fmt CONFIG)
add_executable(main main.cpp)
target_link_libraries(main fmt::fmt)whereas you're using target_include_directories(${PROJECT_NAME}
PUBLIC
$<INSTALL_INTERFACE:include>
PRIVATE
$<BUILD_INTERFACE:${fmt_INCLUDE_DIR}>
)I don't really use CMake's generator statements, so I don't know what I need to see exactly where conan is putting |
|
ok I finally got cmake to generate successfully, and I ran clang-tidy without complaints. There must be something else going on with the CI runner... Still trying to figure this one out. These are the cmds I ended up using: |
thanks you for investigating.
You are right, the
are you looking for Same procedure on Windows, but (my) paths are different (since I set explicit conan's storage path to D:\.conan); default is I agree, my Hope this helps! BTW; cmake > 3.20 is required due to use of CMake's presets. |
|
I suspect there's a limit to what clang-tidy can access on the CI runner's FS. I'll have to continue with this tomorrow (its getting late here). I intend on delving into the GH actions docs to see about runner's FS access. I suspect the home folder isn't a good place for install. Does the runner successfully compile the project?
Yeah I ran into that also. I'm working from WSL (Ubuntu bash for Windows) because I appreciate having an isolated env for testing other's projects. |
yes, here on Windows and runs also as CMake build #62 which is the 'base' for my |
- changed main.cpp to trigger - using cpp-linter python package [header file not found #65]( cpp-linter/cpp-linter-action#65) - in cmake.yml, using hashFiles('conanfile.txt') since it's on root - simplification
understandable :) Actually I can't use WSL here since WSL haven't internet connection (my admin doesn't know why) and hence I can't install anything there, but later on I can do it at another Windows box (or even I start my Fedora dual-boot). BTW, WSL(2) with Ubuntu 22.04 is required. Then the bundled tools are sufficient, no ppa etc. |
|
Pretty sure my WSL Ubuntu is still on 20.04, and I just had to update CMake to make it work. |
|
Are any further formations required; shall I still run it on Linux box? I would expect the same behavior. |
|
Sorry, I completely forgot about this. I don't have anything new for you. It wouldn't hurt to try in on a Linux runner (if it works then, it would help narrow things down). |
2bndy5
added
bug
|
The thing that alludes me is that it works on a local machine, but not on the workflow runner's VM. The Compilation database from CMake is using absolute paths, so there shouldn't be a difference in locating the external lib. |
|
I ran into the same problem and found the cause: The prepended base path is incorrectly computed. As you can see in my attempts to integrate this, the checkout action clones the repository However, given while it should be I worked around this by using |
|
Thanks for reporting this fix. Just my luck that it turned out to be something simple... Not sure how or if there should be a alteration to the code since build paths can be wildly different per project. Once I confirm this, I'll probably update the readme with an example usage of the |
|
Why prepend a base path at all and not just pass it to |
|
IIRC, the prepended path was to keep compatibility with using the docker image (which uses a sequestered File System). If we remove the prepended path, then it would be even more confusing for people using the docker image. |
|
@BurningEnlightenment Please direct you queries about prepending the database to #73 . I'm not dismissing the idea, but it needs a separate thread. |
|
I just found out there's another bug in the code that hides the warning from clang-tidy when it can't find the database (and uses "default flags"). cpp-linter-action/cpp_linter/run.py Lines 443 to 444 in d24e622 To reveal this warning in a consistent manner, the above snippet should be if results.stderr:
logger.warning( |
|
This might be solved with the latest changes to the main branch. All relative paths given to the database option are made absolute. However, the database option seems broken when using the docker env -- using as a python pkg is preferred for the database path to be correctly accessed. |
I see. Thanks for answer. Thanks for this action and your time to support!
Meanwhile, I run into another issue with regard to clang tidy's database (I'm not sure to open another issue - it's at yours). My action looks like
where
CMakePresets.jsoncontainsThe action's log shows that it fails:
Otherwise, running VS Code's devcontainer shows relative path seems to work:
I haven't the experience with clang-tidy using CLI arguments and python, so my guess is that's there is a wrong path (otherwise not very likely) :(
If relevant, the action is here
Originally posted by @ibis-hdl in #64 (comment)
The text was updated successfully, but these errors were encountered: