D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

[Friedrich W. H. Kossebau]

kossebau added a comment.


  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=Code=advsearch==
  
  
  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...

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

D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

[Alexander Lohnau]

alex added a comment.


  However the option seems pretty unused, even from a github search: 
https://github.com/search?q=HeaderExtension%3D+extension%3Akcfgc=Code=advsearch==
  
  > 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.

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

Re: Extending the license policy to include ODbL-1.0

[David Faure]

+1

On mercredi 15 septembre 2021 17:26:57 CEST Volker Krause wrote:
> Hi,
> 
> there's a MR [1] for ki18n containing data tables generated from OSM data,
> which implies the ODbL-1.0 license [2]. We also already have other places
> ([3], [4]) actually doing this.
> 
> However that's a license not yet covered by our license policy, so I suggest
> we add it.
> 
> ODbL is essentially LGPL-y but for data rather than code, so conceptually
> compatible with our existing licensing.
> 
> It's also not like there's any viable alternative to OSM data, so not doing
> this would imply not being able to implement features integrating
> OSM-derived data.
> 
> The proposed addition to the policy section of https://community.kde.org/
> Policies/Licensing_Policy would be:
> 
> 
> # ''Geographic data'', in particular data based on or derived from
> OpenStreetMap may be licensed under the '''[https://spdx.org/licenses/
> ODbL-1.0.html Open Data Commons Open Database License v1.0]'''.
> 
> 
> What do you think?
> 
> Regards,
> Volker
> 
> [1] https://invent.kde.org/frameworks/ki18n/-/merge_requests/19
> [2] https://spdx.org/licenses/ODbL-1.0.html
> [3] https://invent.kde.org/pim/kitinerary/-/blob/master/src/lib/knowledgedb/
> timezonedb_data.cpp
> [4] https://invent.kde.org/libraries/kpublictransport/-/blob/master/src/lib/
> knowledgedb/linemetadata_data.cpp


-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

[Friedrich W. H. Kossebau]

kossebau added a comment.


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

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