Jenkins-kde-ci: kservice master kf5-qt5 » Linux,gcc - Build # 50 - Failure!

2015-09-08 Thread no-reply 

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/50/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 09 Sep 2015 06:52:33 +
Build duration: 1 min 57 sec

CHANGE SET
Revision c297f89dcb9a34972c1a03b6ecf564b8e46bb486 by David Faure: (Rename 
ksycocatest to kservicegroup_dumper, remove outdated test code in)
  change: add tests/kservicegroup_dumper.cpp
  change: delete tests/ksycocatest.cpp
  change: edit tests/CMakeLists.txt
Revision d9eb9f2285b1af6e62e619e0c32eba6689b7eae8 by David Faure: (KSycoca: add 
unittest for global header check)
  change: add autotests/ksycocatest.cpp
  change: edit autotests/CMakeLists.txt
  change: edit autotests/ksycocadicttest.cpp
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kservice master stable-kf5-qt5 » Linux,gcc - Build # 50 - Failure!

2015-09-08 Thread no-reply 

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/50/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 09 Sep 2015 06:52:28 +
Build duration: 1 min 56 sec

CHANGE SET
Revision c297f89dcb9a34972c1a03b6ecf564b8e46bb486 by David Faure: (Rename 
ksycocatest to kservicegroup_dumper, remove outdated test code in)
  change: add tests/kservicegroup_dumper.cpp
  change: delete tests/ksycocatest.cpp
  change: edit tests/CMakeLists.txt
Revision d9eb9f2285b1af6e62e619e0c32eba6689b7eae8 by David Faure: (KSycoca: add 
unittest for global header check)
  change: add autotests/ksycocatest.cpp
  change: edit autotests/ksycocadicttest.cpp
  change: edit autotests/CMakeLists.txt
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125106: Minor optimizations

2015-09-08 Thread Albert Astals Cid 


> On set. 8, 2015, 4:46 p.m., Milian Wolff wrote:
> > src/kconf_update/kconf_update.cpp, line 523
> > 
> >
> > QLatin1String

This was already a QLatin1String :D


> On set. 8, 2015, 4:46 p.m., Milian Wolff wrote:
> > src/kconf_update/kconf_update.cpp, line 250
> > 
> >
> > QLatin1String

Seems like a bug in clazy, sometimes it knows that it should use QLatin1String 
but it seems it didn't in this case.


- Albert


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


On set. 8, 2015, 4:17 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125106/
> ---
> 
> (Updated set. 8, 2015, 4:17 p.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> Ran the clazy tool 
> (http://www.kdab.com/use-static-analysis-improve-performance/)
> 
> Mostly QStringLiteral/QLatin1String additions
> A few const & additions to non public methods
> 
> 
> Diffs
> -
> 
>   src/core/kauthorized.cpp 4280524 
>   src/core/kconfig.cpp 4be9e6d 
>   src/core/kconfigbackend.cpp 67bdefa 
>   src/core/kconfigini.cpp 856b7b7 
>   src/core/kcoreconfigskeleton_p.h d098ef6 
>   src/core/kdesktopfile.cpp 49f37c3 
>   src/core/ksharedconfig.cpp e059b87 
>   src/gui/kwindowconfig.cpp a32c6cc 
>   src/kconf_update/kconf_update.cpp a1c98cb 
>   src/kconfig_compiler/kconfig_compiler.cpp 5c515f4 
> 
> Diff: https://git.reviewboard.kde.org/r/125106/diff/
> 
> 
> Testing
> ---
> 
> Compiles, test pass
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

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

Review Request 125108: kbuildsycoca: remove code for --checkstamps and --nocheckfiles.

2015-09-08 Thread David Faure 

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

Review request for KDE Frameworks and Albert Astals Cid.


Repository: kservice


Description
---

(the options are kept to avoid breaking hypothetic callers, but do nothing 
anymore)

--checkstamps was a timestamp comparison to find out if kbuildsycoca should
do nothing. Let's not just call it in that case ;) A similar timestamp check
is in ksycoca.cpp since recently.

--nocheckfiles was an experimental and marked dangerous option,
to speed up KDE startup by only checking the global header (lang and dirs),
but not checking for modified desktop files. I guess the idea was for
binary packages to always ensure that ksycoca is updated. That's a very
long term plan with a fdo desktop-file-index, but not really applicable until 
then
(what if you install something from sources, on a distro set up that way...).


Diffs
-

  docs/kbuildsycoca5/man-kbuildsycoca5.8.docbook 
68e58db26262b7923adcdfc080bf18ffb7c805f6 
  src/kbuildsycoca/kbuildsycoca.cpp 3ce7ae425cfdfeac3264c5f4ecff440402402f7d 

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


Testing
---

kservice unittests pass (but they don't really test these unused options ;)


Thanks,

David Faure

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

Re: KService, ksycoca and translations

2015-09-08 Thread David Faure 
On Monday 07 September 2015 23:34:54 Albert Astals Cid wrote:
> El Dilluns, 7 de setembre de 2015, a les 23:28:40, Albert Astals Cid va 
> escriure:
> > Running
> >LANGUAGE=de kcmshell5 --list
> > 
> > in my catalan based system gives me almost everything in catalan.
> > 
> > That is because most of the strings come from kservice and my sycoca is in
> > catalan.

It's funny that you hit this now, one day after I offer a solution for it, 
because it has
worked this way for 15 years :-)

> > Possible ways forward i see:
> >  1) When recreating the sycoca fall back to calling kbuildsycoca ourselves
> > (there's code for that already) when the version matches but not the
> > language 

Yes.

> > Actually does anyone know why we're calling kded to call kbuildsycoca if we
> > could (and have code to) call kbuildsycoca directly.

Your patch is for old kservice code btw. I changed it on Aug 22 to not mention
kded anywhere anymore. So if you were using current sources your patch
would have worked :-)

But anyway, I'm reworking this.
 
> Anything i can do to help there?

You can give your input in that other thread in case you see any pitfall I 
might have missed.
One thing I'm unsure about is how to avoid 10 apps rebuilding sycoca at the 
same time;
QSaveFile avoids corruption but not unnecessary work. QLockFile avoids parallel 
work
but avoiding unnecessary work by figuring out if something changed after the 
last rebuild...
well ok we could read the global header of the built-by-someone-else sycoca, and
redo the checkTimestamp logic (to compare dirs mtime with that timestamp).

You can also review the patches I'm writing right now once they are on 
reviewboard ;)
I'll add you as reviewer.

Right now my problem is how to cut this work into individual pieces.
I think I'll start by removing --checkstamps and --nocheckfiles, then I'll 
separate the main()
from kbuildsycoca.cpp, to prepare for a future move of the "build" classes into 
the lib.

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

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

Re: Review Request 125048: Use JSON files directly instead of kcoreaddons_desktop_to_json()

2015-09-08 Thread Alex Richardson 

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

(Updated Sept. 8, 2015, 7:28 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Changes
---

Submitted with commit 6db255388532a4fd0788aa971c83798e1849d479 by Alex 
Richardson to branch master.


Repository: kio


Description
---

Use JSON files directly instead of kcoreaddons_desktop_to_json()


Diffs
-

  src/ioslaves/http/kcookiejar/CMakeLists.txt 
7b4778d1f67c1ad9f9edcaa4692b39ee6fe3f365 
  src/ioslaves/http/kcookiejar/kcookiejar.desktop 
3ea56abdc134cae22b69d7b7636ce6dd415a3d9b 
  src/ioslaves/http/kcookiejar/kcookiejar.json PRE-CREATION 
  src/kpac/CMakeLists.txt fc5989714480ca49b5bd72e1c7b458b26bd0d9bc 
  src/kpac/proxyscout.desktop a545f3d6ef2fd18b1a2c85ebff15c9f2513d87f1 
  src/kpac/proxyscout.json PRE-CREATION 
  src/kpasswdserver/CMakeLists.txt 11c30201012fbe413ff58561b54255e88c2c55b9 
  src/kpasswdserver/kpasswdserver.desktop 
bc788e5665e3d9d43309da241c3a3f5ac3cd0fc9 
  src/kpasswdserver/kpasswdserver.json PRE-CREATION 
  src/kssld/CMakeLists.txt bf6970c2741a6edd01e36b86744d643e70046889 
  src/kssld/kssld.desktop 86581b208ffc89fa5235f9284395d9d7ccebc472 
  src/kssld/kssld.json PRE-CREATION 

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


Testing
---


Thanks,

Alex Richardson

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

Re: Review Request 125106: Minor optimizations

2015-09-08 Thread Milian Wolff 

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


in general +1, but I think some occassions should use QLatin1String in favor of 
QStringLiteral. Sergio, is your tool always suggesting QStringLiteral?


src/core/kauthorized.cpp (line 57)


should be QLatin1String



src/kconf_update/kconf_update.cpp (line 250)


QLatin1String



src/kconf_update/kconf_update.cpp (line 257)


QLatin1String



src/kconf_update/kconf_update.cpp (line 263)


QLatin1String



src/kconf_update/kconf_update.cpp (line 334)


QLatin1String



src/kconf_update/kconf_update.cpp (line 523)


QLatin1String



src/kconfig_compiler/kconfig_compiler.cpp (line 506)


ost of the concatenations below should also use QLatin1String.

are we enabling QStringBuilder for this repo btw?


- Milian Wolff


On Sept. 8, 2015, 4:17 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125106/
> ---
> 
> (Updated Sept. 8, 2015, 4:17 p.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> Ran the clazy tool 
> (http://www.kdab.com/use-static-analysis-improve-performance/)
> 
> Mostly QStringLiteral/QLatin1String additions
> A few const & additions to non public methods
> 
> 
> Diffs
> -
> 
>   src/core/kauthorized.cpp 4280524 
>   src/core/kconfig.cpp 4be9e6d 
>   src/core/kconfigbackend.cpp 67bdefa 
>   src/core/kconfigini.cpp 856b7b7 
>   src/core/kcoreconfigskeleton_p.h d098ef6 
>   src/core/kdesktopfile.cpp 49f37c3 
>   src/core/ksharedconfig.cpp e059b87 
>   src/gui/kwindowconfig.cpp a32c6cc 
>   src/kconf_update/kconf_update.cpp a1c98cb 
>   src/kconfig_compiler/kconfig_compiler.cpp 5c515f4 
> 
> Diff: https://git.reviewboard.kde.org/r/125106/diff/
> 
> 
> Testing
> ---
> 
> Compiles, test pass
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

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

Review Request 125106: Minor optimizations

2015-09-08 Thread Albert Astals Cid 

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

Review request for KDE Frameworks and Matthew Dawson.


Repository: kconfig


Description
---

Ran the clazy tool 
(http://www.kdab.com/use-static-analysis-improve-performance/)

Mostly QStringLiteral/QLatin1String additions
A few const & additions to non public methods


Diffs
-

  src/core/kauthorized.cpp 4280524 
  src/core/kconfig.cpp 4be9e6d 
  src/core/kconfigbackend.cpp 67bdefa 
  src/core/kconfigini.cpp 856b7b7 
  src/core/kcoreconfigskeleton_p.h d098ef6 
  src/core/kdesktopfile.cpp 49f37c3 
  src/core/ksharedconfig.cpp e059b87 
  src/gui/kwindowconfig.cpp a32c6cc 
  src/kconf_update/kconf_update.cpp a1c98cb 
  src/kconfig_compiler/kconfig_compiler.cpp 5c515f4 

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


Testing
---

Compiles, test pass


Thanks,

Albert Astals Cid

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

Re: Review Request 125104: When using scalable icons use still only use sizes defined by index metadata

2015-09-08 Thread andreas kainz 

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

Ship it!


Ship It!

- andreas kainz


On Sept. 8, 2015, 2:27 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125104/
> ---
> 
> (Updated Sept. 8, 2015, 2:27 p.m.)
> 
> 
> Review request for KDE Frameworks, andreas kainz and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Icon metadata contains an entry of what sizes should be used for toolbars.
> 
> If a folder for an icon size contains scalable icons, the current code will 
> list every possible pixel size which could possibly be used. (The toolbar 
> then has code to reduce this back down to 10 "random" entries!)
> 
> Breeze icon designers say this is undesirable as it makes the
> ToolbarSizes config entry redundnant and despite being SVGs they are
> still designed to be rendered at specific pixel sizes.
> 
> 
> Diffs
> -
> 
>   src/kicontheme.cpp d29f82add93b97f8307a370cf3409fede38df865 
> 
> Diff: https://git.reviewboard.kde.org/r/125104/diff/
> 
> 
> Testing
> ---
> 
> Right click on a toolbar in a KF5 app, only lists relevant sizes.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Review Request 125104: When using scalable icons use still only use sizes defined by index metadata

2015-09-08 Thread David Edmundson 

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

Review request for KDE Frameworks, andreas kainz and Christoph Feck.


Repository: kiconthemes


Description
---

Icon metadata contains an entry of what sizes should be used for toolbars.

If a folder for an icon size contains scalable icons, the current code will 
list every possible pixel size which could possibly be used. (The toolbar then 
has code to reduce this back down to 10 "random" entries!)

Breeze icon designers say this is undesirable as it makes the
ToolbarSizes config entry redundnant and despite being SVGs they are
still designed to be rendered at specific pixel sizes.


Diffs
-

  src/kicontheme.cpp d29f82add93b97f8307a370cf3409fede38df865 

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


Testing
---

Right click on a toolbar in a KF5 app, only lists relevant sizes.


Thanks,

David Edmundson

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

Re: QIcon::fromTheme(xxx, someFallback)

2015-09-08 Thread David Faure 
On Monday 07 September 2015 15:53:31 Olivier Goffart wrote:
> 
> But the problem is that QIcon::isNull is likely to be called anyway.
> And this will again do all the look ups in the file system.
 
I don't think so. That's the whole reasoning behind this change.

I added debug output in QIcon and ran konqueror-kf5 (details below).

Result: QIcon::fromTheme is called 84 times, for 66 different icon names.
Among those, 56 do NOT lead to an isNull call.

I think for icons for QActions in menus aren't loaded (or even checked with
isNull) until opening the menu. So this really helps speeding up application 
startup.

On the other hand, isNull() can obviously be called multiple times for
a given icon, so of course we shouldn't make it slower, it should have the
answer at hand immediately.

 Tracing details 

Qt patch http://www.davidfaure.fr/2015/qicon.cpp.diff

$ konqueror 2>&1 | tee /k/konq5-icon.txt

sample output:
konqueror(28364)/default QIcon::fromTheme: QIcon::fromTheme "konqueror" 
0x117dc80
konqueror(28364)/default QIcon::fromTheme: QIcon::fromTheme 
"edit-clear-locationbar-rtl" 0x1372830
konqueror(28364)/default QIcon::fromTheme: QIcon::fromTheme 
"document-print-frame" 0x136af50
konqueror(28364)/default QIcon::isNull: QIcon::isNull "" 0x0
konqueror(28364)/default QIcon::isNull: QIcon::isNull "konqueror" 0x117dc80
(some lines being repeated more than once)

$ grep fromTheme /k/konq5-icon.txt | sort | uniq | wc -l
66

$ grep fromTheme /k/konq5-icon.txt | sed -e 's/.*0x//' | sort | uniq | while 
read a; do grep $a /k/konq5-icon.txt | grep -q isNull || echo $a ; done | wc -l
56

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

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

Re: Review Request 125083: Move X11 related find_package under X11_FOUND

2015-09-08 Thread Martin Gräßlin 


> On Sept. 7, 2015, 9:17 a.m., Martin Gräßlin wrote:
> > hey OSX-devs: we need to find a better solution for this things. I didn't 
> > notice the review before it was pushed, but I would not have given a shipit 
> > for it.
> > 
> > The solution is sementically wrong. We are now binding finding XCB to 
> > whehter XLib is found. In the long termn XLib support will become a 
> > deprecated feature, maybe even completely removed in KWindowSystem. Most is 
> > already ported to XCB. What then? We go back to finding XCB and it will be 
> > found again? Then there is nothing to group with.
> > 
> > Please think about a long term strategy how you want to handle the X11 
> > dependencies. We have had many such reviews lately and it's always a local 
> > "workaround"/"fixup" to some OSX build-oddities. Please have a look at the 
> > bigger picture and think about a general solution on how to disable X11 
> > without having to (stupidly) patch all frameworks.
> 
> Samuel Gaist wrote:
> Hi,
> 
> Sorry for that mistake.
> 
> What about providing KF5 X11/XCB specifc cmake search modules ? This will 
> also require patching of the frameworks but will allow to disable it globally 
> when needed ?
> 
> Martin Gräßlin wrote:
> > allow to disable it globally when needed ?
> 
> But that's already built into CMake. Just pass the right flag at command 
> line and it will build without X11/XLib support. Our CI system does that for 
> every build. Given that I don't understand why OSX devs want again and again 
> (you're not the first and probably not the last) add specific solutions to 
> their system because somehow X11 ends in the build.
> 
> Samuel Gaist wrote:
> To avoid repeating that in the future (and even clean the current state), 
> can you share the correct flags to use before starting a build ? I may have 
> miss them while searching information for kdesrc-build. 
> 
> X11 can easily end up in the build because of some unrelated packages 
> pulling it as a dependency when using e.g. macports.

>From our CI system:
cmake -DCMAKE_DISABLE_FIND_PACKAGE_X11=TRUE

and so on. It's a standard cmake feature. A general solution would btw be to 
add that into ECM so that it automatically gets applied for all framework 
builds.


- Martin


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


On Sept. 7, 2015, 9:25 a.m., Samuel Gaist wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125083/
> ---
> 
> (Updated Sept. 7, 2015, 9:25 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> This avoids trying to detect X11 packages that might be installed on OS X
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 3460224eb895b2295b6e7ee66dd8258da5ec2b91 
> 
> Diff: https://git.reviewboard.kde.org/r/125083/diff/
> 
> 
> Testing
> ---
> 
> Build on OS X 10.8
> 
> 
> Thanks,
> 
> Samuel Gaist
> 
>

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

Re: Review Request 124525: Add KMessageWidget to designer plugin

2015-09-08 Thread David Edmundson 

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

(Updated Sept. 8, 2015, 7:13 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Alex Merry.


Changes
---

Submitted with commit 7da71f38419b7f9a08498bf7e5d26ae8c8c6df8c by David 
Edmundson to branch master.


Repository: kdesignerplugin


Description
---

Add KMessageWidget to designer plugin


Diffs
-

  src/kde.widgets 8f78ee6506aa6eb5b94c6cd1ed49f616e3d1513a 

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


Testing
---

Opened designer-qt5. Works as expected; properties appear all fine.


Thanks,

David Edmundson

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

Re: Review Request 125083: Move X11 related find_package under X11_FOUND

2015-09-08 Thread Samuel Gaist 


> On Sept. 7, 2015, 7:17 a.m., Martin Gräßlin wrote:
> > hey OSX-devs: we need to find a better solution for this things. I didn't 
> > notice the review before it was pushed, but I would not have given a shipit 
> > for it.
> > 
> > The solution is sementically wrong. We are now binding finding XCB to 
> > whehter XLib is found. In the long termn XLib support will become a 
> > deprecated feature, maybe even completely removed in KWindowSystem. Most is 
> > already ported to XCB. What then? We go back to finding XCB and it will be 
> > found again? Then there is nothing to group with.
> > 
> > Please think about a long term strategy how you want to handle the X11 
> > dependencies. We have had many such reviews lately and it's always a local 
> > "workaround"/"fixup" to some OSX build-oddities. Please have a look at the 
> > bigger picture and think about a general solution on how to disable X11 
> > without having to (stupidly) patch all frameworks.
> 
> Samuel Gaist wrote:
> Hi,
> 
> Sorry for that mistake.
> 
> What about providing KF5 X11/XCB specifc cmake search modules ? This will 
> also require patching of the frameworks but will allow to disable it globally 
> when needed ?
> 
> Martin Gräßlin wrote:
> > allow to disable it globally when needed ?
> 
> But that's already built into CMake. Just pass the right flag at command 
> line and it will build without X11/XLib support. Our CI system does that for 
> every build. Given that I don't understand why OSX devs want again and again 
> (you're not the first and probably not the last) add specific solutions to 
> their system because somehow X11 ends in the build.

To avoid repeating that in the future (and even clean the current state), can 
you share the correct flags to use before starting a build ? I may have miss 
them while searching information for kdesrc-build. 

X11 can easily end up in the build because of some unrelated packages pulling 
it as a dependency when using e.g. macports.


- Samuel


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


On Sept. 7, 2015, 7:25 a.m., Samuel Gaist wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125083/
> ---
> 
> (Updated Sept. 7, 2015, 7:25 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> This avoids trying to detect X11 packages that might be installed on OS X
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 3460224eb895b2295b6e7ee66dd8258da5ec2b91 
> 
> Diff: https://git.reviewboard.kde.org/r/125083/diff/
> 
> 
> Testing
> ---
> 
> Build on OS X 10.8
> 
> 
> Thanks,
> 
> Samuel Gaist
> 
>

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