[Differential] [Changed Subscribers] D2854: New: ECMGenerateApiDox, for generating qch & tag files

[kossebau (Friedrich W. H. Kossebau)]

kossebau added subscribers: winterz, staniek.

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau
Cc: staniek, winterz, ochurlaud, #kdevelop, #frameworks

[Differential] [Updated] D2854: New: ECMGenerateApiDox, for generating qch & tag files

[kossebau (Friedrich W. H. Kossebau)]

kossebau updated the summary for this revision.

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau
Cc: ochurlaud, #kdevelop, #frameworks

[Differential] [Request, 598 lines] D2854: New: ECMGenerateApiDox, for generating qch & tag files

[kossebau (Friedrich W. H. Kossebau)]

kossebau created this revision.
kossebau added subscribers: Frameworks, KDevelop, ochurlaud.

REVISION SUMMARY
  To enable creation of qch files during a normal build, 
  for documenting the public API of a lib.
  These macros are especially done with release builds in mind,
  so distributed packages (like from Linux distributions) can
  include qch files matching the version of the library and will be
  also automatically updated on new versions of the libary.
  
  Next to that the macros also supports linking between different
  qch files, so a subclass from another library for which there also
  is a qch file installed will be linked to the entry in that other
  qch file.
  
  This should be a nice addition to the online service like api.kde.org,
  like qassitent/qt qhc files are to doc.qt.io
  
  Open questions:
  a) recommended install path for qch and tag files?
  What would KDevelop & Co. like for easy automatic discovery of qch files?
  What would be a nice var name for such dirs to be used with KDEInstallDirs?
  
  b) best way to specify sources to use for created API docs?
  SOURCE_DIRS in this draft is the only option to specify the input to
  doxygen, following the inspiration of kde-dev-scripts/kdedoxyqt.sh.
  Being part of the buildsystem and having access to more data like sources
  for a library target or even special target metadata, supporting other 
variants
  might be nice to have. Looking for proposals from experienced target
  metadata users here.
  
  c) sharing metadata with kapidox
  Initially I placed these macros into the kapidox module, as this seems the
  logic place. And would match what kdoctools does for user manuals.
  Just, that would create a build dependency on kapidox which complicates usage
  a little. Having these macros in ECM delivers them with no extra effort
  needed.
  The data in metainfo.yaml is partially duplicated with the data feed into
  the macros. How to deduplicate that is still open. Especially with the need
  to not depend on external data sources like identify.kde.org.
  
  d) naming pattern for cmake config variables for qch & tag files sane?
  
  Issues:
  
  - doxygen for me currently creates broken inter-qch links.
  - KDevelop for some created qch does not show the content (but assistant
  
  does).
  
  - html style in assistant sometimes covers class names

BRANCH
  addGenerateApiDox

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

AFFECTED FILES
  modules/ECMDoxygenQCH.config.in
  modules/ECMGenerateApiDox.cmake

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau
Cc: ochurlaud, #kdevelop, #frameworks

Re: Review Request 129012: kwallet: Add missing boost header

[Andreas Sturmlechner]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129012/
---

(Updated Sept. 25, 2016, 10:34 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 0ae542bfa6e266ead736d6cca5f979dac75e24f2 by Andreas 
Sturmlechner to branch master.


Repository: kwallet


Description
---

Fixes build error with GpgME-1.7.0 (which was ported away from boost).

A second commit also removes a duplicate search for KF5DocTools with wrong 
version requirement (done from root CMakeLists.txt already)


Diffs
-

  docs/kwallet-query/CMakeLists.txt c4ef9c73a9fb41dbd94d237e7af90c48fdd3828f 
  src/runtime/kwalletd/kwalletwizard.cpp 
bf36f3b37795d39d0f523175dc72a7294ab9257b 

Diff: https://git.reviewboard.kde.org/r/129012/diff/


Testing
---


Thanks,

Andreas Sturmlechner

Re: Review Request 129012: kwallet: Add missing boost header

[Aleix Pol Gonzalez]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129012/#review99517
---


Ship it!




Ship It!

- Aleix Pol Gonzalez


On Sept. 25, 2016, 3:07 p.m., Andreas Sturmlechner wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129012/
> ---
> 
> (Updated Sept. 25, 2016, 3:07 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kwallet
> 
> 
> Description
> ---
> 
> Fixes build error with GpgME-1.7.0 (which was ported away from boost).
> 
> A second commit also removes a duplicate search for KF5DocTools with wrong 
> version requirement (done from root CMakeLists.txt already)
> 
> 
> Diffs
> -
> 
>   docs/kwallet-query/CMakeLists.txt c4ef9c73a9fb41dbd94d237e7af90c48fdd3828f 
>   src/runtime/kwalletd/kwalletwizard.cpp 
> bf36f3b37795d39d0f523175dc72a7294ab9257b 
> 
> Diff: https://git.reviewboard.kde.org/r/129012/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sturmlechner
> 
>

Re: Review Request 129012: kwallet: Add missing boost header

[Andreas Sturmlechner]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129012/
---

(Updated Sept. 25, 2016, 1:07 p.m.)


Review request for KDE Frameworks.


Changes
---

fixed $summary...


Summary (updated)
-

kwallet: Add missing boost header


Repository: kwallet


Description (updated)
---

Fixes build error with GpgME-1.7.0 (which was ported away from boost).

A second commit also removes a duplicate search for KF5DocTools with wrong 
version requirement (done from root CMakeLists.txt already)


Diffs
-

  docs/kwallet-query/CMakeLists.txt c4ef9c73a9fb41dbd94d237e7af90c48fdd3828f 
  src/runtime/kwalletd/kwalletwizard.cpp 
bf36f3b37795d39d0f523175dc72a7294ab9257b 

Diff: https://git.reviewboard.kde.org/r/129012/diff/


Testing
---


Thanks,

Andreas Sturmlechner

Review Request 129012: Remove duplicate search for KF5DocTools

[Andreas Sturmlechner]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129012/
---

Review request for KDE Frameworks.


Repository: kwallet


Description
---

Add missing boost header

Fixes build error with GpgME-1.7.0 (which was ported away from boost).


Diffs
-

  docs/kwallet-query/CMakeLists.txt c4ef9c73a9fb41dbd94d237e7af90c48fdd3828f 
  src/runtime/kwalletd/kwalletwizard.cpp 
bf36f3b37795d39d0f523175dc72a7294ab9257b 

Diff: https://git.reviewboard.kde.org/r/129012/diff/


Testing
---


Thanks,

Andreas Sturmlechner

Re: Review Request 129010: kded: remove dbus calls to ksplash.

[Luigi Toscano]

> On Set. 24, 2016, 2:15 p.m., Luigi Toscano wrote:
> > Wouldn't this break the compatibility with older Plasma (one can argue that 
> > Plasma should be updated, but it's a behavioral change).
> 
> David Faure wrote:
> Yes it would. Can you suggest an appropriate time frame for this cleanup? 
> I was hoping two plasma releases (5.7 and 5.8) was OK, I can wait more, but 
> I'd like to keep cleaning up kded from workspace stuff at some point, it 
> really doesn't belong there.

I don't have an answer. it boils down to the promise of binary compatibility in 
Frameworks. If it includes behavioral compatibility, this couldn't 
theoretically be changed in the lifetime of 5. That said, I guess that the only 
user of this specific change is Plasma, so this specific case could be a really 
specific exception which would be announced making sure that it's well known.


- Luigi


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129010/#review99501
---


On Set. 24, 2016, 2:09 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129010/
> ---
> 
> (Updated Set. 24, 2016, 2:09 p.m.)
> 
> 
> Review request for KDE Frameworks and David Edmundson.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> Not needed anymore since June (b6058a0 in plasma-workspace, i.e. Plasma 5.7).
> 
> 
> Diffs
> -
> 
>   src/kded.cpp 6b3ec1e93f5c1ae3620204190af2c8cee3736a11 
> 
> Diff: https://git.reviewboard.kde.org/r/129010/diff/
> 
> 
> Testing
> ---
> 
> None.
> 
> 
> Thanks,
> 
> David Faure
> 
>

Re: Review Request 128790: Call utempter manually

[Oswald Buddenhagen]

> On Sept. 23, 2016, 5:17 a.m., Oswald Buddenhagen wrote:
> > cmake/FindUTEMPTER.cmake, line 53
> > 
> >
> > i suppose it would make sense to keep it, but with the executable.
> 
> Martin Tobias Holmedahl Sandsmark wrote:
> I don't think mark_as_advanced() is appropriate, it makes sense to allow 
> packagers to manually specify the path.

the question is whether an average build-from-source user would ever need it. i 
don't think so.


- Oswald


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128790/#review99479
---


On Sept. 9, 2016, 4:50 a.m., Martin Tobias Holmedahl Sandsmark wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128790/
> ---
> 
> (Updated Sept. 9, 2016, 4:50 a.m.)
> 
> 
> Review request for KDE Frameworks, David Faure, Kurt Hindenburg, Oswald 
> Buddenhagen, Rex Dieter, and Thiago Macieira.
> 
> 
> Bugs: 364779
> https://bugs.kde.org/show_bug.cgi?id=364779
> 
> 
> Repository: kpty
> 
> 
> Description
> ---
> 
> According to the investigation in https://bugs.kde.org/show_bug.cgi?id=364779 
> utempter does stuff in a way that isn't compatible with 
> QProcess/KProcess/KPtyProcess (calling sigaction() before launching its child 
> process).
> 
> So instead we invoke it manually with QProcess.
> 
> 
> Diffs
> -
> 
>   cmake/FindUTEMPTER.cmake a3ea06a 
>   src/CMakeLists.txt caab96f 
>   src/kpty.cpp 15c3b81 
>   src/kpty_p.h 192bf1c 
> 
> Diff: https://git.reviewboard.kde.org/r/128790/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Tobias Holmedahl Sandsmark
> 
>

Re: Review Request 128790: Call utempter manually

[Martin Tobias Holmedahl Sandsmark]

> On Sept. 23, 2016, 5:17 a.m., Oswald Buddenhagen wrote:
> > a bit of delay due to vacation ...

no problem, I was in shenzhen myself.


> On Sept. 23, 2016, 5:17 a.m., Oswald Buddenhagen wrote:
> > cmake/FindUTEMPTER.cmake, line 53
> > 
> >
> > i suppose it would make sense to keep it, but with the executable.

I don't think mark_as_advanced() is appropriate, it makes sense to allow 
packagers to manually specify the path.


- Martin Tobias Holmedahl


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128790/#review99479
---


On Sept. 9, 2016, 4:50 a.m., Martin Tobias Holmedahl Sandsmark wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128790/
> ---
> 
> (Updated Sept. 9, 2016, 4:50 a.m.)
> 
> 
> Review request for KDE Frameworks, David Faure, Kurt Hindenburg, Oswald 
> Buddenhagen, Rex Dieter, and Thiago Macieira.
> 
> 
> Bugs: 364779
> https://bugs.kde.org/show_bug.cgi?id=364779
> 
> 
> Repository: kpty
> 
> 
> Description
> ---
> 
> According to the investigation in https://bugs.kde.org/show_bug.cgi?id=364779 
> utempter does stuff in a way that isn't compatible with 
> QProcess/KProcess/KPtyProcess (calling sigaction() before launching its child 
> process).
> 
> So instead we invoke it manually with QProcess.
> 
> 
> Diffs
> -
> 
>   cmake/FindUTEMPTER.cmake a3ea06a 
>   src/CMakeLists.txt caab96f 
>   src/kpty.cpp 15c3b81 
>   src/kpty_p.h 192bf1c 
> 
> Diff: https://git.reviewboard.kde.org/r/128790/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Tobias Holmedahl Sandsmark
> 
>

Re: Review Request 129010: kded: remove dbus calls to ksplash.

[David Faure]

> On Sept. 24, 2016, 12:15 p.m., Luigi Toscano wrote:
> > Wouldn't this break the compatibility with older Plasma (one can argue that 
> > Plasma should be updated, but it's a behavioral change).

Yes it would. Can you suggest an appropriate time frame for this cleanup? I was 
hoping two plasma releases (5.7 and 5.8) was OK, I can wait more, but I'd like 
to keep cleaning up kded from workspace stuff at some point, it really doesn't 
belong there.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129010/#review99501
---


On Sept. 24, 2016, 12:09 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129010/
> ---
> 
> (Updated Sept. 24, 2016, 12:09 p.m.)
> 
> 
> Review request for KDE Frameworks and David Edmundson.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> Not needed anymore since June (b6058a0 in plasma-workspace, i.e. Plasma 5.7).
> 
> 
> Diffs
> -
> 
>   src/kded.cpp 6b3ec1e93f5c1ae3620204190af2c8cee3736a11 
> 
> Diff: https://git.reviewboard.kde.org/r/129010/diff/
> 
> 
> Testing
> ---
> 
> None.
> 
> 
> Thanks,
> 
> David Faure
> 
>