D10450: Generate a custom target in kcoreaddons_desktop_to_json

2018-02-18 Thread Raphael Kubo da Costa
rakuco added a comment.


  I agree this can be abandoned -- whatever solution we agree upon should 
probably be done in plasma-desktop.

REPOSITORY
  R244 KCoreAddons

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

To: tcberner, #freebsd, mpyne, bshah, dfaure, rakuco
Cc: bcooksley, rikmills, rakuco, kfunk, adridg, kossebau, #frameworks, michaelh


D10450: Generate a custom target in kcoreaddons_desktop_to_json

2018-02-17 Thread Raphael Kubo da Costa
rakuco added a comment.


  > This isn't just a problem on KDE Neon though, is it? I thought FreeBSD is 
also affected?
  
  To be clear, FreeBSD is affected by not having any fix in the tree (i.e. the 
json file not being present when moc is invoked), whereas Neon fails with 
D10485  applied.

REPOSITORY
  R244 KCoreAddons

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

To: tcberner, #freebsd, mpyne, bshah, dfaure, rakuco
Cc: bcooksley, rikmills, rakuco, kfunk, adridg, kossebau, #frameworks, michaelh


D10450: Generate a custom target in kcoreaddons_desktop_to_json

2018-02-17 Thread Raphael Kubo da Costa
rakuco added a comment.


  Per my previous comment, I still don't see how changing this to a target 
would solve anything.
  
  For one, the CMake implementation 

 allows both files and targets to be specified there.
  
  Additionally, this would just add a different kind of dependency to 
`kcm_lookandfeel`, but not change `lookandfeel`'s dependencies -- the problem 
persists if target B depends on a source file that target A depends on, but 
only target A depends on the generation of a file that this source file depends 
on.

REPOSITORY
  R244 KCoreAddons

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

To: tcberner, #freebsd, mpyne, bshah, dfaure, rakuco
Cc: rikmills, rakuco, kfunk, adridg, kossebau, #frameworks, michaelh


D10450: Generate a custom target in kcoreaddons_desktop_to_json

2018-02-12 Thread Raphael Kubo da Costa
rakuco requested changes to this revision.
rakuco added a comment.
This revision now requires changes to proceed.


  @kossebau's right: the problem lies in `lookandfeeltool` depending on 
`kcm.cpp`, while the `kcoreaddons_desktop_to_json()` call makes the 
`kcm_lookandfeel` target depend on the generation of the json file. It's pretty 
easy to reproduce this bug by running `make lookandfeeltool_autogen` with a 
fresh build directory.
  
  > For this very patch, I am still lost on how cmake generates the rules for 
automoc stuff, so no clue if switching to an explicit intermediate target 
improves something.
  
  In terms of generated `Makefile`s, without the patch in this review request 
we have 
`$BUILDDIR/kcms/lookandfeel/CMakeFiles/kcm_lookandfeel_autogen.dir/build.make` 
with the right dependencies 
(`kcms/lookandfeel/CMakeFiles/kcm_lookandfeel_autogen` depends on 
`kcms/lookandfeel/kcm_lookandfeel.json`, which calls `desktoptojson`). With 
this patch applied, the difference is that the dependency is moved to 
`$BUILDDIR/CMakeFiles/Makefile2`, where 
`kcms/lookandfeel/CMakeFiles/kcm_lookandfeel_autogen.dir/all` depends on 
`kcms/lookandfeel/CMakeFiles/desktop_to_json_.dir/all`. 
`kcms/lookandfeel/CMakeFiles/lookandfeeltool_autogen.dir/all` still doesn't 
depend on anything though, so the bug persists if I run `make  
lookandfeeltool_autogen` directly.

REPOSITORY
  R244 KCoreAddons

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

To: tcberner, #freebsd, mpyne, bshah, dfaure, rakuco
Cc: rakuco, kfunk, adridg, kossebau, #frameworks, michaelh


D6076: Do not depend on bash uncessarily, and do not validate icons by default.

2017-06-03 Thread Raphael Kubo da Costa
rakuco added a comment.


  See also: https://git.reviewboard.kde.org/r/129246/

REPOSITORY
  R266 Breeze Icons

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

To: tcberner, #freebsd, winterz
Cc: rakuco, #frameworks


[Differential] [Commented On] D3850: Pass -fno-operator-names when supported

2016-12-29 Thread rakuco (Raphael Kubo da Costa)
rakuco added a comment.


  Isn't it better to use `check_cxx_compiler_flag` to see if the flag is 
supported and enable it in case it is?

REPOSITORY
  R240 Extra CMake Modules

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

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

To: kfunk, #frameworks, ivan, #buildsystem
Cc: rakuco, elvisangelaccio


Review Request 129246: validate_svg: Increase portability

2016-10-23 Thread Raphael Kubo da Costa

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

Review request for KDE Frameworks and Jos van den Oever.


Repository: breeze-icons


Description
---

- Instead of hardcoding the call to the xmllint binary, look for it in
  CMake first and pass its full path to validate_svg.sh.
- Stop creating xmlerrors in the source tree, which is not removed when
  there are no errors in the validation.
- Switch to sh(1) instead of requiring bash, we are just invoking
  find(1) and there is nothing bash-specific in the script.
- Stop setting SVGS in CMake. It increases the configuration time while
  providing no benefit other than perhaps adding the SVG files to an IDE
  project.


Diffs
-

  CMakeLists.txt 2591a3a0c9c397a729243ceb414251f296895888 
  validate_svg.sh adaf26f95a645b57f8a588fdd49d2281f24b684a 

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


Testing
---

Configuration continues to work, as well as the `breeze-validate-svg` continues 
working.


Thanks,

Raphael Kubo da Costa



Re: OSX/CI: ark fails to build on branch frameworks

2015-01-16 Thread Raphael Kubo da Costa
Marko Käning  writes:

> Hi Raphael,
>
> On 14 Jan 2015, at 22:11 , Raphael Kubo da Costa  wrote:
>> Is the full build log available somewhere, preferably with `make
>> VERBOSE=1'? This really smells like OS X having an older (< 3.0) version
>> of libarchive in its "base" system, a more recent version being
>> installed by `port' (found by CMake) and the older version being picked
>> up for linking.
>
> yes, that’s correct. The system’s libarchive is being found.
>
> Will send details as PM.

So to summarize: my hunch was correct and a libarchive shipped by OS X
itself in /usr/lib/libarchive.dynlib was being picked up by CMake (why
it got recognized as being recent enough I do not know) even though
there was a more recent libarchive version installed by MacPorts into
/opt/local.

Since CMake itself was installed into a different prefix, it wasn't
looking at /opt/local by default, so we've fixed this by setting
CMAKE_PREFIX_PATH to that location.

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: OSX/CI: ark fails to build on branch frameworks

2015-01-14 Thread Raphael Kubo da Costa
David Faure  writes:

> On Wednesday 14 January 2015 08:49:15 Marko Käning wrote:
>> What’s going on?
>
> I'm not sure the ark developers read kde-frameworks-devel...
> This is related to libarchive, and therefore unrelated to KF5 itself.

That's true, thanks Marko for sending me an email and poking me with a
stick :-)

Is the full build log available somewhere, preferably with `make
VERBOSE=1'? This really smells like OS X having an older (< 3.0) version
of libarchive in its "base" system, a more recent version being
installed by `port' (found by CMake) and the older version being picked
up for linking.

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: Review Request 119289: Remove api_searchbox.html.

2014-07-15 Thread Raphael Kubo da Costa

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

(Updated July 15, 2014, 7:20 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Alex Merry and Aurélien Gâteau.


Repository: kapidox


Description
---

It's been part of base.html itself since 
07b35f28a334584114be89a5f293cd39ff003cd6.


Diffs
-

  src/kapidox/data/api_searchbox.html 9fd1ade894680f7f41ca498d0bc4a8dd684c0e98 

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


Testing
---


Thanks,

Raphael Kubo da Costa

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: Review Request 119289: Remove api_searchbox.html.

2014-07-15 Thread Raphael Kubo da Costa

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

(Updated July 15, 2014, 9:21 p.m.)


Review request for KDE Frameworks, Alex Merry and Aurélien Gâteau.


Repository: kapidox


Description
---

It's been part of base.html itself since 
07b35f28a334584114be89a5f293cd39ff003cd6.


Diffs
-

  src/kapidox/data/api_searchbox.html 9fd1ade894680f7f41ca498d0bc4a8dd684c0e98 

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


Testing
---


Thanks,

Raphael Kubo da Costa

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: Review Request 119291: Use an for the search box.

2014-07-15 Thread Raphael Kubo da Costa

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

(Updated July 15, 2014, 6:20 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Alex Merry and Aurélien Gâteau.


Repository: kapidox


Description
---

Use an `` with a proper type and a placeholder: this allows the platform 
to style it differently if necessary, and the use of the placeholder attribute 
lets us to get rid of the custom script to clean up its value.


Diffs
-

  src/kapidox/data/templates/base.html 10f8aa6dae14e0ad6e649bdb28fcba81b7d39341 

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


Testing
---


Thanks,

Raphael Kubo da Costa

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Review Request 119291: Use an for the search box.

2014-07-15 Thread Raphael Kubo da Costa

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

Review request for KDE Frameworks, Alex Merry and Aurélien Gâteau.


Repository: kapidox


Description
---

Use an `` with a proper type and a placeholder: this allows the platform 
to style it differently if necessary, and the use of the placeholder attribute 
lets us to get rid of the custom script to clean up its value.


Diffs
-

  src/kapidox/data/templates/base.html 10f8aa6dae14e0ad6e649bdb28fcba81b7d39341 

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


Testing
---


Thanks,

Raphael Kubo da Costa

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Review Request 119289: Remove api_searchbox.html.

2014-07-15 Thread Raphael Kubo da Costa

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

Review request for KDE Frameworks and Aurélien Gâteau.


Repository: kapidox


Description
---

It's been part of base.html itself since 
07b35f28a334584114be89a5f293cd39ff003cd6.


Diffs
-

  src/kapidox/data/api_searchbox.html 9fd1ade894680f7f41ca498d0bc4a8dd684c0e98 

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


Testing
---


Thanks,

Raphael Kubo da Costa

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: Review Request 115395: Also pass -fno-exceptions when building with clang

2014-03-04 Thread Raphael Kubo da Costa

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

Ship it!


Let's give it a try as the situation in frameworks land looks better than the 
one in KDE4.

- Raphael Kubo da Costa


On March 4, 2014, 11:02 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115395/
> ---
> 
> (Updated March 4, 2014, 11:02 p.m.)
> 
> 
> Review request for Build System, Extra Cmake Modules and KDE Frameworks.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Also pass -fno-exceptions when building with clang
> 
> All of KF5 + kate + kde-workspace compile with clang and -fno-exceptions
> 
> The only problem related to clang and -fno-exceptions I could find was
> http://llvm.org/bugs/show_bug.cgi?id=10910 and that is fixed since
> clang version 3.0 which was released in December 2011
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake 
> 5225b167106481db700e4bd906a1063e737102d4 
> 
> Diff: https://git.reviewboard.kde.org/r/115395/diff/
> 
> 
> Testing
> ---
> 
> compiled all of kf5 + kate + kde-workspace without any issues using clang 3.3
> 
> Would be good if someone with an older clang version could test it and see 
> whether it works.
> May also be related to the libstdc++ headers (4.8 installed here).
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: Review Request 115395: Also pass -fno-exceptions when building with clang

2014-02-03 Thread Raphael Kubo da Costa


> On Feb. 3, 2014, 8:07 p.m., Raphael Kubo da Costa wrote:
> > Please see the big comment below the elseif line, the link to the 
> > kde-core-devel and 
> > http://lists.kde.org/?l=kde-core-devel&m=138244424421211&w=2: the issue 
> > here is that if you pass -fno-exceptions to clang you need to guarantee it 
> > is not going to include any headers that throw exceptions either, even if 
> > it is in some template code that never gets instantiated.
> > 
> > For example, this does not build with clang++ -fno-exceptions, but does 
> > with GCC 4.8:
> > 
> >   #include 
> >   template 
> >   struct S { void f() { throw std::exception(); } };
> > 
> > This was a problem for kdelibs including OpenEXR headers, or kdepim 
> > including pimlibs headers that all fell into this case.
> >
> 
> Alex Merry wrote:
> Arguably, the solution here is to always enable exceptions for code that 
> encounters this (as we do for the OpenEXR QImage format plugin, for example).
> 
> Alexander Richardson wrote:
> It works with all the STL headers, the question is should we have 
> everything built with clang be 7% bigger, or just enable exceptions in those 
> cases where it breaks compilation? I don't really mind either way, I just 
> realized that all of frameworks builds fine even with -fno-exceptions.

The situation might be easier with frameworks and we can choose to selectively 
enable exceptions where necessary; I only worry about ending up having to play 
catch up with libraries that suddenly end up including headers that throw 
exceptions via a dependency of a dependency, or issues going undetected due to 
everyone using GCC.


- Raphael


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


On Jan. 30, 2014, 1:18 a.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115395/
> ---
> 
> (Updated Jan. 30, 2014, 1:18 a.m.)
> 
> 
> Review request for Build System, Extra Cmake Modules and KDE Frameworks.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Also pass -fno-exceptions when building with clang
> 
> All of KF5 + kate + kde-workspace compile with clang and -fno-exceptions
> 
> The only problem related to clang and -fno-exceptions I could find was
> http://llvm.org/bugs/show_bug.cgi?id=10910 and that is fixed since
> clang version 3.0 which was released in December 2011
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake 
> 335e1270d19f8342e41b22e7081dea3f7ac0fbfc 
> 
> Diff: https://git.reviewboard.kde.org/r/115395/diff/
> 
> 
> Testing
> ---
> 
> compiled all of kf5 + kate + kde-workspace without any issues using clang 3.3
> 
> Would be good if someone with an older clang version could test it and see 
> whether it works.
> May also be related to the libstdc++ headers (4.8 installed here).
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: Review Request 115395: Also pass -fno-exceptions when building with clang

2014-02-03 Thread Raphael Kubo da Costa

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


Please see the big comment below the elseif line, the link to the 
kde-core-devel and 
http://lists.kde.org/?l=kde-core-devel&m=138244424421211&w=2: the issue here is 
that if you pass -fno-exceptions to clang you need to guarantee it is not going 
to include any headers that throw exceptions either, even if it is in some 
template code that never gets instantiated.

For example, this does not build with clang++ -fno-exceptions, but does with 
GCC 4.8:

  #include 
  template 
  struct S { void f() { throw std::exception(); } };

This was a problem for kdelibs including OpenEXR headers, or kdepim including 
pimlibs headers that all fell into this case.


- Raphael Kubo da Costa


On Jan. 30, 2014, 1:18 a.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115395/
> ---
> 
> (Updated Jan. 30, 2014, 1:18 a.m.)
> 
> 
> Review request for Build System, Extra Cmake Modules and KDE Frameworks.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Also pass -fno-exceptions when building with clang
> 
> All of KF5 + kate + kde-workspace compile with clang and -fno-exceptions
> 
> The only problem related to clang and -fno-exceptions I could find was
> http://llvm.org/bugs/show_bug.cgi?id=10910 and that is fixed since
> clang version 3.0 which was released in December 2011
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake 
> 335e1270d19f8342e41b22e7081dea3f7ac0fbfc 
> 
> Diff: https://git.reviewboard.kde.org/r/115395/diff/
> 
> 
> Testing
> ---
> 
> compiled all of kf5 + kate + kde-workspace without any issues using clang 3.3
> 
> Would be good if someone with an older clang version could test it and see 
> whether it works.
> May also be related to the libstdc++ headers (4.8 installed here).
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel