CMake project not recognizing header files in sysroot/usr/local/include

Sysprogs forums Forums VisualGDB CMake project not recognizing header files in sysroot/usr/local/include

This topic contains 14 replies, has 2 voices, and was last updated by  support 3 weeks, 4 days ago.

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #26074

    nOlander
    Participant

    I have been using VisualGDB for a bit to cross-compile a project for a Raspberry Pi. I’ve synchronized the sysroot from the Raspberry Pi successfully, and I know the header files are present in the local sysroot, but I can’t get Visual Studio to compile, it just reports Error snap7.h: No such file or directory for whatever header it is unable to find.

    Interestingly, the Clang autocomplete works fine with those headers, it just appears that the build is not properly including the usr/local/include folder in the sysroot. It also compiles correctly if I copy the header files from usr/local/include to /usr/include, but I don’t intend on doing that on the remote system and I feel like this should be configurable without having to manually adjust the sysroot.

    Where should I be looking in my configuration to resolve this? I’m using a CMake project that I imported from an already existing CMake project that I had manually created on Visual Studio 2017 Professional with VisualGDB Custom 5.4R12.

    • This topic was modified 1 month, 4 weeks ago by  nOlander.
    #26080

    support
    Keymaster

    Hi,

    Please ensure you are using the Advanced CMake Project Subsystem. Then you will be able to use the automatic header discovery to fix the project settings automatically.

    If you prefer to configure everything by hand, you would need to find the target (i.e. an library or an executable) that contains the faulty source file and add the directory containing the source file to its include directories under VS properties for that target.

    If you still cannot find the corresponding settings, please let us know your project type (Advanced CMake/Regular CMake) and we will provide more detailed instructions.

    #26115

    nOlander
    Participant

    I’m fairly certain I have it configured as an Advanced CMake project, but how would I tell?

    I’ve tried to use the automatic header discovery and I’ll get the notification about “Found one additional include directory required by the current file”, which edits the appropriate CMake file, but it only seems to resolve the autocomplete/red squiggles error and I still get the compilation error.

    If possible, I would prefer to leave the CMake files untouched as much as possible because I know they work with the directory structure on the Linux system, but I will make changes if needed. When you say “VS properties for that target”, what do you mean? I’ve selected the specific .a item in the solution explorer and added the sysroot/usr/local/include directory to the include directories list, but it hasn’t made a change in the build.

     

    Attachments:
    You must be logged in to view attached files.
    #26117

    support
    Keymaster

    Sorry, it’s hard to suggest anything specific without knowing more details (how exactly is the target declared, what is the current directory with the header file and exactly is is spelled in the Makefile, what exactly gets edited in the CMakeLists.txt file).

    One possible cause for this would be CMakeLists.txt using the regular /path/on/target syntax to specify include directories instead of ${CMAKE_SYSROOT}/path/on/target. The former syntax will only work when compiling directly, while the latter will work both when building on Linux and Windows.

    VS properties for the target can be opened by right-clicking on the target (specific executable or library) in Solution Explorer and selecting “Properties”.

    Edit: the VisualGDB 5.5 development branch does automatically use the ${CMAKE_SYSROOT} syntax for automatically discovered directories (e.g. VisualGDB-5.5.1.3300.msi), however it hasn’t fully passed all our internal tests and may be less reliable than the stable v5.4 release.

    • This reply was modified 1 month, 4 weeks ago by  support.
    #26127

    nOlander
    Participant

    This is how the CMake file is set up:

    The directory with the header file that’s not being found is  C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/usr/local/include and it gets added to the CMakeLists.txt via this line: target_include_directories(Snap7-Wrapper PRIVATE ../../=/usr/local/include). I did notice that it was being inserted above the already existing target_include_directories for that target, so I tried manually editing it in to the existing one but it didn’t make a difference.

    You mentioned making sure to utilize ${CMAKE_SYSROOT}/path/to/include format, but I noticed that the line inserted automatically didn’t do that and instead used ../../=/usr/local/include.

    Do those help at all?

    I also checked the VS Properties for the project and under Type it says “CMake Project”. Is this a regular CMake Project like you said and if so, how can I change it to and Advanced CMake Project?

    #26128

    support
    Keymaster

    Thanks, this indeed helps understand what is going on.

    Indeed, the ../../=/usr/local/include syntax is incorrect (the correct one should be ${CMAKE_SYSROOT}/usr/local/include). The development branch of VisualGDB 5.5 should already use the correct syntax, but if you don’t want to upgrade before v5.5 reaches the stable release stage, simply try replacing C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot with ${CMAKE_SYSROOT} and the project should build both on Linux and Windows.

    #26135

    nOlander
    Participant

    I made that change in my CMake file, but it’s still reporting No such file or directory even after changing the CMakeLists.txt and clean/rebuild the entire solution. Is there any way to view the output of CMake generating the make command? I can only find the output for the build, not including CMake.

    #26146

    support
    Keymaster

    Strange. Please try enabling verbose build (add “-v” to Ninja command-line arguments or “VERBOSE=1” to GNU Make command line arguments via VisualGDB Project Properties -> CMake Proejct Settings -> Ninja/Make command) and then build the project again.

    It will show the exact command lines used by the build system for each file. Please locate the command line for any file from that library and check what is going on (e.g. ${CMAKE_SYSROOT} got expanded incorrectly, or the path is not present in the command line at all).

    If you are not sure, please post the corresponding command line from the build log and your updated target_include_directories() statement and we will help you understand it.

    P.S. You can also try using our CMake Debugger to quickly understand what is going on. It allows stepping through CMake statements and will evaluate variables like ${CMAKE_SYSROOT}.

    #26154

    nOlander
    Participant

    When I output the value of ${CMAKE_SYSROOT} it is printing the correct path to the sysroot but I’m still getting that same error when I build. This seems to be the affected due to you

    which outputs

     

    My make output is the following:

    Does this help you in resolving the issue all?

    • This reply was modified 1 month, 3 weeks ago by  nOlander.
    #26158

    support
    Keymaster

    Sorry, it looks like you did not add “VERBOSE=1” to the GNU Make command-line arguments (see our previous reply), hence Make did not dump the gcc command lines.

    Please try adding it as suggested and share the updated log that should include the exact gcc command lines used to build the code.

    #26288

    nOlander
    Participant

    My apologies for the delay in response. I believe I resolved that and got this output:

    Does that clarify the issue at all? It seems a bit more verbose than the previous one.

    #26289

    support
    Keymaster

    Yes, here’s the relevant command line:

    However, it doesn’t seem to mention /usr/local/include at all, so most likely your project somehow overrides or resets the include directory list for the target. As the CMakeLists.txt structure was not created by VisualGDB, it’s hard to suggest a specific spot where it could be happening.

    That said, if you have trouble navigating the CMakeLists files of this project, please consider re-creating it from scratch using the VisualGDB GUI for adding targets and setting their properties. This will ensure that all target properties will be stored consistently and won’t conflict with each other.

    #26291

    nOlander
    Participant

    I believe I may have resolved this. In this section:

    I switched the sysroot line to the PUBLIC section and it seemed to work.

    I’m not 100% certain, but it is no longer reporting the snap7.h not found on building. I will complete some testing and report the success here.

    #26421

    nOlander
    Participant

    Just realized I never responded to this, but this resolved the issue and it has been building properly

    #26422

    support
    Keymaster

    No worries and good to know it works. As we don’t know the internal structure of your project, it’s hard to comment anything regarding the solution, but just a heads up that you can use the VisualGDB GUI to edit the public includes of a target via the “Exported Settings -> Public” page of its VS Properties window.

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic.