D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

Friedrich W. H. Kossebau noreply at phabricator.kde.org
Thu Sep 16 07:19:59 BST 2021


kossebau added a comment.


  In D19565#678799 <https://phabricator.kde.org/D19565#678799>, @alex wrote:
  
  > I am wondering if there is really a need for it. SourceExtension seems completely unused and HeaderExtension is only used in okteta.
  >
  > Though in KDE code, Qt code  (and most other that I know of) it is the ".h" extension is the most common one for headers.
  >
  > Are there any reasons for having it that I am not aware of?
  
  
  KF targets also consumers outside of KDE spheres, which are not bound to KDE's suffix tradition/culture (and any need to stay backward-compatible to that), so just looking at Qt & KDE is not enough. The world is bigger ;)
  
  Try e.g.`find /usr/include/ -name "*.hxx"` and `find /usr/include/ -name "*.hpp"` to see that developers of other projects prefer those suffixes for C++ headers.  Using `.h`, so the same suffix as used for C headers, has the disadvantage that one cannot tell the type by just the siuffix, and most MIME type guessers also fall flat due to not reliable magic bytes.
  
  When it comes to the source suffix, there also are bigger subcultures preferring something else than `.cpp`, not sure where the others are coming from.
  
  https://en.wikipedia.org/wiki/C++ lists these suffixes being more widely used: .C, .cc, .cpp, .cxx, .c++, .h, .H, .hh, .hpp, .hxx, .h++. And while the C++ Core guidelines these days recommend .h and .cpp for new-from-scratch projects (see https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-file-suffix) they also acknowledge there are other traditions. And there are people who think the reasoning for using .h (mixing C and C++) is poor when it comes to C++-only headers. and for the before-mentioned reasons having a dedicated own suffix for headers would be better.
  
  All in all these flags allows for nicer integration of kocnfigcompiler generated code over forcing KDE's current traditions onto others. If you ask me, actually more of KDE should switch to use some non-h suffix for headers as well where possible, less guess work needed whether a header is C or C++..

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D19565

To: kossebau, #frameworks, apol
Cc: alex, apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ahmadsamir, ngraham, bruns, vkrause
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20210916/ea76ae26/attachment.htm>


More information about the Kde-frameworks-devel mailing list