Re: make IDEs aware of the headers

2023-01-25 Thread Andrey Butirsky

Initially, I thought it's a Qt Creator problem too and filed an issue there:
https://bugreports.qt.io/browse/QTCREATORBUG-28638

It happened out it's not a bug but a feature, also backed by CMake 
maintainers (see the link in the OP):


   The build system is our source of truth for which file belongs to
   which project. Earlier versions of Qt Creator attempted to work
   around incomplete project files using heuristics, which lead to
   various problems. We don't want to go back to that.

So the issue was closed as "Won't fix" upstream, and the only way to fix 
it seems to be adjust our CMake files.


We also tried to do it in the other places:
polkit-kde-agent-1!18 (merged) 


So I really hope it won't face much resistance here, too.


On 18.01.2023 15:01, David Redondo wrote:

Am Samstag, 7. Januar 2023, 16:40:27 CET schrieb Andrey Butirsky:

Other IDEs should benefit too.

KDevelop (and I think Kate too) displays headers in "Project" view without
this. I am not convinced of this amount of work (and cluttering of our CMake
files) to workaround IDE/editor deficiencies. While I don't know how easy it
is to get at CMake is likely to have include info.

David




Re: make IDEs aware of the headers

2023-01-18 Thread David Redondo
Am Samstag, 7. Januar 2023, 16:40:27 CET schrieb Andrey Butirsky:


> > Other IDEs should benefit too.

KDevelop (and I think Kate too) displays headers in "Project" view without 
this. I am not convinced of this amount of work (and cluttering of our CMake 
files) to workaround IDE/editor deficiencies. While I don't know how easy it 
is to get at CMake is likely to have include info.

David





make IDEs aware of the headers

2023-01-18 Thread Andrey Butirsky

Hi all,

let me introduce my finding we probably want for all KDE's CMake-based 
projects eventually.


The idea is, wherever we add a source files to a project, we should also 
add a headers alongside:


|add_library(my_lib [STATIC|SHARED|MODULE] [source.cpp source.h ...]) 
add_executable(my_exe [source.cpp source.h]) target_sources(my_target 
 [source.cpp source.h])|


That has zero impact for building the project, as the headers do not get 
compiled directly,
but declaring headers in a such way helps IDEs (Qt Creator, etc.) be 
aware of them and work with them properly.


For now, KWin MR 
 exists which 
adds the most essential headers, but even to fully cover KWin alone that 
would probably require some sort of automation as it contains ~138 
CMakeLists.txt files.


Until that automation method is not found, I hope it's OK to add the 
headers manually or semi-automated 
.



Hereby is the MR message with all the details:

Nowadays, it's generally recommended to add headers alongside with 
sources in CMake:



note that .h header files were specified as sources too, not just
the .cpp implementation files. *Headers listed as sources don’t
get compiled directly on their own, but the effect of adding them
is for the benefit of IDE generators* like Visual Studio, Xcode,
Qt Creator, etc. This causes those headers to be listed in the
project’s file list within the IDE, even if no source file refers
to it via #include. This can make those headers easier to find
during development and potentially aid things like refactoring
functionality, etc.

https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/ 



Recent Qt Creator depends on it heavily:


This means that the header files will get the same treatment
as the source files.

  * clang-tidy and clazy will be able to analyze them
  * The TODO plugin can find the TODOs in header files
  * The Test plugin can find the Google Tests defined in
header files


https://www.qt.io/blog/qt-creator-6-cmake-update
In my personal observations it should also help with source/header 
jumps as it sometimes doesn't work reliably otherwise.


Other IDEs should benefit too.