After compilation, there are only pqxx files but no pqxx.hxx files. Is this normal?

[RageCPP]

# root CMakeLists.txt
FetchContent_Declare(libpqxx
  GIT_REPOSITORY git@github.com:jtv/libpqxx.git
  GIT_TAG 2ffb711bc4e9b086bf0c549a9c22b19f61ab5476 # v7.9.0
  OVERRIDE_FIND_PACKAGE
  GIT_SHALLOW ON
)
FetchContent_MakeAvailable(libpqxx)

# use libpqxx target CMakeLists.txt
find_package(libpqxx REQUIRED)

target_link_libraries(${PROJECT_NAME} PUBLIC
  pqxx)

after build my include folder just had pqxx, not have pqxx.hxx pqxx content but when use it in neovim tell me error.

[RageCPP]

I would like to add that although an error is reported, when I use the definition jump, I can jump successfully.

[jtv]

Yes, it is normal that there is no pqxx.hxx file. There is no need for such a file.

[tt4g]

pqxx/pqxx.hxx file does not exist in this repository. And the include error is probably a Neovim problem.

[RageCPP]

Can I create a file with .hxx suffix to help identify it? I think it may be a problem with clangd, but I haven’t found a solution yet.

[tt4g]

Since you have imported libpqxx as part of your project, isn't clangd recognizing the local header files? As far as the clangd documentation is reading, you need to create compile_commands.json or compile_flags.txt and make clangd recognize the compile flag.

It also says that compile_commands.json is generated by cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=1.

[jtv]

Of course you can create whatever files you like on your system, but first I'd do a bit more searching to find out what the actual problem might be. It looks likely that somebody else will have run into it.

None of the headers in the C++ standard library have a suffix like ".hxx" to their names, and presumably neovim works with those. But perhaps the error you're seeing is indicative of a different problem, several layers of #include down. So perhaps open pqxx in neovim and see whether this error comes from one of the #include directives in there?

[RageCPP]

Since you have imported libpqxx as part of your project, isn't clangd recognizing the local header files? As far as the clangd documentation is reading, you need to create compile_commands.json or compile_flags.txt and make clangd recognize the compile flag.

It also says that compile_commands.json is generated by cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=1.

Other imported packages can recognize header files, but it may not be correct because pgxx does not have a suffix, but I can't be sure.

[RageCPP]

Of course you can create whatever files you like on your system, but first I'd do a bit more searching to find out what the actual problem might be. It looks likely that somebody else will have run into it.

None of the headers in the C++ standard library have a suffix like ".hxx" to their names, and presumably neovim works with those. But perhaps the error you're seeing is indicative of a different problem, several layers of #include down. So perhaps open pqxx in neovim and see whether this error comes from one of the #include directives in there?

I tried to change pqxx to pqxx.hpp or pqxx.hxx and the file could not be found.

[tt4g]

STL header files such as vector and utility also have no suffix. It seems strange that only pqxx is not recognized.

[tt4g]

Have you generated compile_commands.json? Also, if you are using some plugin to use LSP in neovim, have you checked how to use compile_commands.json in that plugin? For example, neovim-lsp seems to have a restriction that it only recognizes compile_commands.json in the project root directory: https://github.com/neovim/nvim-lspconfig/blob/v0.1.7/doc/server_configurations.md#clangd

[RageCPP]

Have you generated compile_commands.json? Also, if you are using some plugin to use LSP in neovim, have you checked how to use compile_commands.json in that plugin? For example, neovim-lsp seems to have a restriction that it only recognizes compile_commands.json in the project root directory: https://github.com/neovim/nvim-lspconfig/blob/v0.1.7/doc/server_configurations.md#clangd

I'm sure it was generated

I tried adding hxx but it had no effect

[tt4g]

What LSP plugin do you use? The failure to recognize the header files provided by libpqxx is a problem with the LSP plugin or clangd and should be asked in those communities. No one in the libpqxx repository will know the cause.

[RageCPP]

What LSP plugin do you use? The failure to recognize the header files provided by libpqxx is a problem with the LSP plugin or clangd and should be asked in those communities. No one in the libpqxx repository will know the cause.

Yes, I posted a link to this issue in the clangd community, but no one has answered me yet.

[RageCPP]

clangd.log

[tt4g]

Even if we look at the clangd logs, we cannot investigate the problem from there.

[RageCPP]

I rechecked compile_commands.json, I found this

{
  "directory": "/home/rage/code/chessmeta/build/_deps/libpqxx-build/src",
  "command": "/usr/bin/g++-13  -I/home/rage/code/chessmeta/build/_deps/libpqxx-build/include -I/home/rage/code/chessmeta/build/_deps/libpqxx-src/include -I/usr/include/pgsql -std=c++17 -o CMakeFiles/pqxx.dir/binarystring.cxx.o -c /home/rage/code/chessmeta/build/_deps/libpqxx-src/src/binarystring.cxx",
  "file": "/home/rage/code/chessmeta/build/_deps/libpqxx-src/src/binarystring.cxx",
  "output": "_deps/libpqxx-build/src/CMakeFiles/pqxx.dir/binarystring.cxx.o"
},

rage@localhost:~/code/chessmeta/include/pqxx> ls /home/rage/code/chessmeta/build/_deps/libpqxx-build/include/pqxx/
config_cmake.h.in  config-internal-compiler.h  config-internal-libpq.h  config-public-compiler.h
rage@localhost:~/code/chessmeta/include/pqxx> ls /home/rage/code/chessmeta/build/_deps/libpqxx-build/include
CMakeFiles  cmake_install.cmake  Makefile  pqxx

There doesn't seem to be any problem

[tt4g]

@RageCPP Did you make a comment here by mistake, thinking it was a clangd community?

[RageCPP]

@RageCPP Did you make a comment here by mistake, thinking it was a clangd community?

Well, I think this problem may occur in many people who use nvim and pqxx, so I want to leave a record here so that people who have doubts can check it later. Should I stop what I submit here?

[tt4g]

I think it is a great idea to record the problem in case others encounter the same problem. However, the cost of all the information other than cause and solution also makes it difficult to find the really important information. It is better to just comment on how to solve the problem when it is solved.

[RageCPP]

I think it is a great idea to record the problem in case others encounter the same problem. However, the cost of all the information other than cause and solution also makes it difficult to find the really important information. It is better to just comment on how to solve the problem when it is solved.

Hello, I think I found the problem, but now I can't continue to troubleshoot. Does libpqxx have a discussion forum similar to discord? I will delete all irrelevant comments later and only keep the solutions.

When I delete these lines under the pqxx file, the error is no longer reported

#include "pqxx/array.hxx"
#include "pqxx/binarystring.hxx"
#include "pqxx/blob.hxx"
#include "pqxx/connection.hxx"
#include "pqxx/cursor.hxx"
#include "pqxx/errorhandler.hxx"
#include "pqxx/except.hxx"
#include "pqxx/largeobject.hxx"
#include "pqxx/nontransaction.hxx"
#include "pqxx/notification.hxx"
#include "pqxx/params.hxx"
#include "pqxx/pipeline.hxx"
#include "pqxx/prepared_statement.hxx"
#include "pqxx/range.hxx"
#include "pqxx/result.hxx"
#include "pqxx/internal/result_iterator.hxx"
#include "pqxx/internal/result_iter.hxx"
#include "pqxx/robusttransaction.hxx"
#include "pqxx/row.hxx"
#include "pqxx/stream_from.hxx"
#include "pqxx/stream_to.hxx"
#include "pqxx/subtransaction.hxx"
#include "pqxx/time.hxx"
#include "pqxx/transaction.hxx"
#include "pqxx/transactor.hxx"

I moved the discussion here https://github.com/jtv/libpqxx/discussions/830

[tt4g]

There is no Discord, etc. It is a clangd or LSP problem that the header file is not recognized properly, so you should look for a Discord or something like that. And changing include/pqxx/pqxx will affect many users badly.

[RageCPP]

I think I may have found the final cause of the problem

// C++20: Assume support.
#if __has_include(<ranges>)
#include <ranges>
#endif

There is a problem with this code. Not all compilation options that support cpp20 contain this header file. my g++13 compiler

rage@localhost:/usr> g++-13 --version
g++-13 (SUSE Linux) 13.2.1 20240206 [revision 67ac78caf31f7cb3202177e6428a46d829b70f23]
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and i am sure i use it

[tt4g]

Since the existence of the header is checked by #if __has_include(<ranges>), if <ranges> is not provided, then #include <ranges> is ignored.

[RageCPP]

Since the existence of the header is checked by #if __has_include(<ranges>), if <ranges> is not provided, then #include <ranges> is ignored.

But it doesn't seem to work, It looks like it determines that I have this header file, but clangd tells me I don't have. I commented the #include <ranges> code in all files, and finally nvim no longer reported errors. I see what you mean, it may be a false positive from clangd

[tt4g]

it may be a false positive from clangd

Yes.

[RageCPP]

issue end

[RageCPP]

!!! use clang17 not use clang15

[jtv]

We do have a Discussions forum by the way.

But it does seem to me that libpqxx can work around this by adding a configure-time feature check for ranges support, and make the `#include

` conditional on _that,_ rather than on the header's presence. The annoying thing is that various static analysis tools will then start spewing false positives on C++17 setups, because the header is not present there. But since I'm trying to work towards a C++20-and-up release anyway, I can live with that On Sat, 11 May 2024 at 09:14, RageCPP ***@***.***> wrote: > !!! use clang17 not use clang15 > > — > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > You are receiving this because you commented.Message ID: > ***@***.***> >

[jtv]

@RageCPP @tt4g We do have a Discussions forum.

For a moment I thought that it might help for me to add a configure-time check for ranges support. But no — ranges support is used in the headers only. I don't think it would make sense to nail that down at configure time.

[tt4g]

@jtv Perhaps this is a clangd or Language Server issue. I am assuming that the project configuration was not loaded correctly because the header files that actually existed were not detected.

[jtv]

I see. Thanks @tt4.