kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension
ClosedPublic

Authored by kossebau on Mar 6 2019, 12:55 PM.

Details

Summary

When using kconfig_compiler generated sources in projects where the used
file extensions for C++ files are not ".h" and/or ".cpp", the include for
the generated header looks a bit alien to the project, as well as the
generated source file if one looks closer at it.

This code adds new optional flags HeaderExtension & SourceExtension which
can be used to control the file extensions used for the generated files.

Test Plan

All unit tests and the new test_fileextensions pass, existing projects using
kcfg without & with the new flags build fine.

Diff Detail

Repository
R237 KConfig
Branch
configfileextensions
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 9249
Build 9267: arc lint + arc unit
kossebau created this revision.Mar 6 2019, 12:55 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptMar 6 2019, 12:55 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
kossebau requested review of this revision.Mar 6 2019, 12:55 PM
kossebau updated this revision to Diff 53273.Mar 6 2019, 1:16 PM

fixup: correct default cpp for SourceExtension in README.dox

apol added a subscriber: apol.Mar 6 2019, 3:00 PM

+1 LGTM

kossebau updated this revision to Diff 53299.Mar 6 2019, 4:46 PM

update to latest master

@apol Thanks for review.

No further comments anyone? Would then proceed to push this next Monday, March 18th, if no-one objects.

apol accepted this revision.Mar 13 2019, 2:30 PM
This revision is now accepted and ready to land.Mar 13 2019, 2:30 PM
This revision was automatically updated to reflect the committed changes.
alex added a subscriber: alex.Sep 15 2021, 8:10 PM

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?

In 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++..

alex added a comment.Sep 16 2021, 6:09 PM

However the option seems pretty unused, even from a github search: https://github.com/search?q=HeaderExtension%3D+extension%3Akcfgc&type=Code&ref=advsearch&l=&l=

KF targets also consumers outside of KDE spheres

Also I think there are currently quite a lot of kcfgc options, which makes is more difficult to work with IMHO. That might also be more true for third party users which are not very familiar with the API.

to see that developers of other projects prefer those suffixes for C++ headers. Using .h, so the same suffix as used for C headers

Though from having a quick look it seems like (pretty much all) of those headers are not using any of KDE/Qt libs. Which means that they would not be a very likely audience anyways.
If we want to attract our frameworks to more users, making them slimmer is also a possibility one needs to consider.

In D19565#678804, @alex wrote:

However the option seems pretty unused, even from a github search: https://github.com/search?q=HeaderExtension%3D+extension%3Akcfgc&type=Code&ref=advsearch&l=&l=

In comparison to how many non KDE users of kconfigcompiler? ;) Also is github only giving a partial view of the world with htose fine with MS GitHub or having put their code in public anyway. After all KF is LGPL, to allow in-house/proprietary use. And those often have their subcultures using their own peferred suffices, I found :) ).

KF targets also consumers outside of KDE spheres

Also I think there are currently quite a lot of kcfgc options, which makes is more difficult to work with IMHO. That might also be more true for third party users which are not very familiar with the API.

Can you report any who were confused by those rather straightforward options? I would expect almost all are not challenged by those bits, removing them should not imrpive their experience a lot. Do we have reports/research?

Though from having a quick look it seems like (pretty much all) of those headers are not using any of KDE/Qt libs. Which means that they would not be a very likely audience anyways.

I was giving you examples of what C++ developers use. And it's C++ developer who are the primary target of our libraries, as everyone else has a hard time due to no real bindings.

If we want to attract our frameworks to more users, making them slimmer is also a possibility one needs to consider.

I would not agree that cutting features and reducing flexibility makes things more attractive to others. Rather the opposite. Why using a primitive solution that only partially fits when one can instead do a home-grown perfect fit with full control...