Re: Fwd: KF5 CMake usage question

[Shaheed Haque]

Exactly.

On 23 May 2017 at 20:40, Albert Astals Cid  wrote:
> El dimarts, 23 de maig de 2017, a les 2:04:54 CEST, Aleix Pol va escriure:
>> On Mon, May 22, 2017 at 7:54 PM, Shaheed Haque  wrote:
>> > On 21 May 2017 at 22:27, Aleix Pol  wrote:
>> >> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque 
> wrote:
>> >>> Actually, there is one thing about "target CMake"-based KF5 that I
>> >>> don't quite understand: is there a way to get to the C++ compile flags
>> >>> needed from CMake? That is, the modern equivalent of Foo_COMPILE_FLAGS
>> >>> but for target Foo? Even if the general answer is "no", I'm interested
>> >>> in at least the CMake variables/properties/commands needed to get to
>> >>> "-fPIC" and "-std=gnu++14".
>> >>>
>> >>> I'm aware of the target properties
>> >>> COMPILE_FLAGS/OPTIONS/DEFINITIONS/OPTIONS as well as
>> >>> POSITION_INDEPENDENT_CODE and CXX_STANDARD but none of these seem to
>> >>> be set on targets I have tried.
>> >>>
>> >>> Perhaps these are only set if somehow the compiler name etc. is
>> >>> specified?
>> >>>
>> >>> Thanks, Shaheed
>> >>>
>> >>> On 18 May 2017 at 18:04, Shaheed Haque  wrote:
>>  Hi,
>> 
>>  On 18 May 2017 at 12:51, Andreas Hartmetz  wrote:
>> > On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
>> >> Hi,
>> >>
>> >> On 13 May 2017 at 22:04, Sven Brauch  wrote:
>> >> > Hi,
>> >> >
>> >> > On 05/13/2017 06:06 PM, Shaheed Haque wrote:
>> >> >> The printed output shows that the variable KF5KIO_INCLUDE_DIRS is
>> >> >> not
>> >> >> set. In poking around, I see references to a (new-to-me)
>> >> >> target-based
>> >> >
>> >> >> system, and using that like this:
>> >> > The question is, why do you need to do that?
>> >
>> > The idea with the target based system aka "Modern CMake" is that you
>> > say
>> > you want to compile against a library, and that is all you have to do.
>> > A
>> > library requires you to add an include path for its own headers,
>> > include
>> > paths for headers of one of its dependencies, and link against a bunch
>> > of libraries? All covered by target properties.
>> > If for some reason (e.g. handover to an external tool) you need those
>> > properties, you can still query them. Under enforced names
>> > nonetheless,
>> > unlike FOO_INCLUDE_DIR or was it FOO_INCLUDE_DIRS?
>> 
>>  Ack. The problem from the point of view of an automated tool which
>>  starts
>>  with a component called Foo arises ONLY because the target(s) of Foo
>>  are
>>  called FooFoo and FooBar. CMake does not - AFAICS - allow one to query
>>  Foo
>>  and somehow find FooFoo and FooBar inorder to look up
>>  FooFoo_INCLUDE_DIRS
>>  etc.
>> 
>> >> I'm continuing to experiment with trying to build Python bindings for
>> >> KF5. As part of that, the SIP tooling creates C++ wrapper code which
>> >> must be compiled for each framework, and for that I need to know the
>> >> header file directories. So far, I have simply been hardcoding the
>> >> needed paths on my own system, but I now want to move to using
>> >> standard CMake-based logic instead.
>> >>
>> >> (In some sense, this might be seen as similar to the stuff that was
>> >> added to ECM, but I'm trying for a significantly more automated
>> >> approach).
>> >>
>> >> Also, I am trying to feel my way towards a Pythonic build system for
>> >> the KF5 bindings (as, roughly speaking, PyQt seems to be doing): in
>> >> other words I'm interested in using CMake as a stepping stone, not
>> >> the
>> >> actual build system.
>> >
>> > I would recommend against that unless you really need to have heavy
>> > logic in the build system. A build system's main job is to "solve" a
>> > dependency tree - that is the difference between a build system and a
>> > script that runs the compiler. The dependency tree enables cheap
>> > incremental builds and correct parallel builds. Maybe not that
>> > important
>> > for bindings, admittedly.
>> > Your advantage from using Python must be larger than the overhead from
>> > doing your own dependency resolution plus the overhead from the CMake-
>> > Python interfacing plus the build-related facilities that CMake has
>> > and
>> > Python doesn't. Or were you considering scons?
>> > PyQt may have chosen Python because qmake sucks, and it needs Python
>> > anyway, so it avoids any extra dependencies. I know from experience
>> > that
>> > you really want to avoid extra dependencies in commercial products.
>> 
>>  /me nods vigourosly.
>> 
>>  I'm not (yet) familair with all the intricacies of the Python build
>>  system
>>  (or CMake for that 

Re: Fwd: KF5 CMake usage question

[Shaheed Haque]

> I don't understand what you're trying to do.

Me neither :-). Let me take a step back to try to provide some
context. It is my assessment that part of the problem with the
maintenance of bindings has been the lack of automation both in
support of the initial development of the bindings, and then ongoing
maintenance. My overall intention is to try to provide the missing
automation. For our present purposes, we can think of that as having
one part to do with the language support (think C++ templates,
exceptions, ...) being mapped to Python, and a second part to do with
how the code is packaged and delivered.

This second part has some complications for which I don't yet have a
clear solution:

- Steve did some cool stuff in ECM but there are aspects of that which
are not as automated as I think can be achieved and which ties the
overall solution firmly to KDE.

- I observe that PyQt has undergone a good deal of enhancement around
thePython end of the packaging; and the latest incarnation based on
something called a "wheel" seems to be widely appreciated. I want to
try to get to the same point.

- In between C++ and Python is SIP. SIP prsently has its own binding
build tooling to solve part of this problem. But it seems planned for
this to die in the near future.

So, the best transition path between the CMake-based build for KF5 and
the Python end of the "wheel" build and deployment process is not at
all clear to me. Part of the problem is that I don't have much
experience of either and none of the comparable solutions out there
(ECM, PyQt) have quite the same aspirations as I stated above.

So, back to the present point. The Cmake documentation is reasnably
detailed, but light on the overall way things work: specifically, I
have not quite understood how build setting/requirements are
propagated from (say) Qt::Core to KF5::whatever and thenceto the
bindings.

For example, I had hoped that by doing a find package of KF5::Foo, I'd
be able to query from Cmake the needed settingsto compile the
bindings, but that always seems incomplete (e.g. the gnustd++14) I can
make an educated guess as to one possibility: maybe CMake propagates
these things at the point it evaluates the dependencies during a
build, and not before, but the CMake docs I have seen don't actually
seem to explain how the thing works.

So, I'm somewhat in the dark trying to stitch the pieces together.

> You are not supposed to change the definitions Qt5::Core suggests to
> the compiler.

I'm trying to understand how to query the CMake system for what the
settings are supposed to be so that I can - possibly - use some other
build system to achieve it.

> Aleix

Re: Fwd: KF5 CMake usage question

[Albert Astals Cid]

El dimarts, 23 de maig de 2017, a les 2:04:54 CEST, Aleix Pol va escriure:
> On Mon, May 22, 2017 at 7:54 PM, Shaheed Haque  wrote:
> > On 21 May 2017 at 22:27, Aleix Pol  wrote:
> >> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque  
wrote:
> >>> Actually, there is one thing about "target CMake"-based KF5 that I
> >>> don't quite understand: is there a way to get to the C++ compile flags
> >>> needed from CMake? That is, the modern equivalent of Foo_COMPILE_FLAGS
> >>> but for target Foo? Even if the general answer is "no", I'm interested
> >>> in at least the CMake variables/properties/commands needed to get to
> >>> "-fPIC" and "-std=gnu++14".
> >>> 
> >>> I'm aware of the target properties
> >>> COMPILE_FLAGS/OPTIONS/DEFINITIONS/OPTIONS as well as
> >>> POSITION_INDEPENDENT_CODE and CXX_STANDARD but none of these seem to
> >>> be set on targets I have tried.
> >>> 
> >>> Perhaps these are only set if somehow the compiler name etc. is
> >>> specified?
> >>> 
> >>> Thanks, Shaheed
> >>> 
> >>> On 18 May 2017 at 18:04, Shaheed Haque  wrote:
>  Hi,
>  
>  On 18 May 2017 at 12:51, Andreas Hartmetz  wrote:
> > On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
> >> Hi,
> >> 
> >> On 13 May 2017 at 22:04, Sven Brauch  wrote:
> >> > Hi,
> >> > 
> >> > On 05/13/2017 06:06 PM, Shaheed Haque wrote:
> >> >> The printed output shows that the variable KF5KIO_INCLUDE_DIRS is
> >> >> not
> >> >> set. In poking around, I see references to a (new-to-me)
> >> >> target-based
> >> > 
> >> >> system, and using that like this:
> >> > The question is, why do you need to do that?
> > 
> > The idea with the target based system aka "Modern CMake" is that you
> > say
> > you want to compile against a library, and that is all you have to do.
> > A
> > library requires you to add an include path for its own headers,
> > include
> > paths for headers of one of its dependencies, and link against a bunch
> > of libraries? All covered by target properties.
> > If for some reason (e.g. handover to an external tool) you need those
> > properties, you can still query them. Under enforced names
> > nonetheless,
> > unlike FOO_INCLUDE_DIR or was it FOO_INCLUDE_DIRS?
>  
>  Ack. The problem from the point of view of an automated tool which
>  starts
>  with a component called Foo arises ONLY because the target(s) of Foo
>  are
>  called FooFoo and FooBar. CMake does not - AFAICS - allow one to query
>  Foo
>  and somehow find FooFoo and FooBar inorder to look up
>  FooFoo_INCLUDE_DIRS
>  etc.
>  
> >> I'm continuing to experiment with trying to build Python bindings for
> >> KF5. As part of that, the SIP tooling creates C++ wrapper code which
> >> must be compiled for each framework, and for that I need to know the
> >> header file directories. So far, I have simply been hardcoding the
> >> needed paths on my own system, but I now want to move to using
> >> standard CMake-based logic instead.
> >> 
> >> (In some sense, this might be seen as similar to the stuff that was
> >> added to ECM, but I'm trying for a significantly more automated
> >> approach).
> >> 
> >> Also, I am trying to feel my way towards a Pythonic build system for
> >> the KF5 bindings (as, roughly speaking, PyQt seems to be doing): in
> >> other words I'm interested in using CMake as a stepping stone, not
> >> the
> >> actual build system.
> > 
> > I would recommend against that unless you really need to have heavy
> > logic in the build system. A build system's main job is to "solve" a
> > dependency tree - that is the difference between a build system and a
> > script that runs the compiler. The dependency tree enables cheap
> > incremental builds and correct parallel builds. Maybe not that
> > important
> > for bindings, admittedly.
> > Your advantage from using Python must be larger than the overhead from
> > doing your own dependency resolution plus the overhead from the CMake-
> > Python interfacing plus the build-related facilities that CMake has
> > and
> > Python doesn't. Or were you considering scons?
> > PyQt may have chosen Python because qmake sucks, and it needs Python
> > anyway, so it avoids any extra dependencies. I know from experience
> > that
> > you really want to avoid extra dependencies in commercial products.
>  
>  /me nods vigourosly.
>  
>  I'm not (yet) familair with all the intricacies of the Python build
>  system
>  (or CMake for that matter!), but I do see that PyQt has to work quite
>  hard
>  to keep its build system working as a Python user might expect.
>  Further, the system I am 

Re: Application usage statistics and targeted user surveys

[Aleix Pol]

On Sun, Apr 23, 2017 at 12:52 PM, Volker Krause  wrote:
> Hi,
>
> we have talked about the above topics a couple of times in the past, from what
> I remember usually agreeing it would be nice to have some more statistical
> information about our users, so we know what our applications are used for,
> and to measure impact of changes. Similarly, it would be nice to be able to
> actually ask our users questions without statistical bias by using out-of-band
> channels like blogs or social media. This can be obviously addressed by adding
> this into application code, but that raises some valid privacy concerns.
>
> Wanting this for GammaRay I attempted to implement a generic framework for
> this, with the goal to make this fully transparent, and give the user full
> control over what data is shared, and how often they want to participate in
> surveys, ie. make this solid enough on the privacy side that even I would
> enable it myself. You'll find the code in Git (kde:kuserfeedback).
>
> Feature-wise it so far contains:
> - a set of built-in data sources (app version, Qt version, platform,
> application usage time, screen setup, etc) that applications can choose to
> enable
> - generic data sources for tracking the time ratio a Q_PROPERTY has a specific
> value, allowing to track e.g. which application view is used how much
> - the ability to add custom/application-specific data sources
> - reference widgets for customizing what data you want to share, and showing
> exactly what that means, in human readable translated text and if you insists
> also all the way down to the raw JSON sent to the server.
> - survey targeting using simple C++/JS-like expressions that can access all
> the data sources (ie. you can target e.g. only users with high DPI multi-
> screen setups)
> - configurable encouragement of users to contribute (ie. after X starts and/or
> Y hours of usage, repeated after Z months, suggest the user to participate if
> they aren't already doing so).
> - a management and analytic tool that allows you to manage products and survey
> campaigns, and view recorded data using configurable aggregations
> - the entire thing works without unique user ids. Fingerprinting can still be
> an issue on too small user sets and/or when using too much detail in the data.
> - by default all of this is opt-in of course, although technically the API
> doesn't prevent applications to change this
> - it can deal with multiple products, each product can have different data
> sources and survey campaigns
>
> Technically, this consists of the following parts:
> - a library that goes into the target application, backward compatible all the
> way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending only on
> QtGui
> - a library with the reference widgets, also with extended backward
> compatibility
> - the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not the
> most fun technology, but that stuff is available almost anywhere, and easy to
> deploy and maintain
> - the management tool, recent Qt5/recent C++, using QtCharts for the data
> analysis
> - a command line tool for data import/export, useful for eg. automated backups
>
> All of this is LGPLv2+ licensed.
>
> Feedback obviously very welcome, in particular around privacy concerns, or
> reasons that would make you enable/disable such a feature.
>
> Regards,
> Volker

Hi volker,
I've been looking into how it works, I wanted to test the tests/orwell
application but I keep getting this error:
./bin/orwell: symbol lookup error: ./bin/orwell: undefined symbol:
_ZN12UserFeedback18CompilerInfoSourceC1Ev

I'm seeing a similar error when running autotests:
* Start testing of DataSourceTest *
Config: Using QtTest library 5.9.0, Qt 5.9.0
(x86_64-little_endian-lp64 shared (dynamic) release build; by GCC
6.3.1 20170306)
PASS   : DataSourceTest::initTestCase()
PASS   : DataSourceTest::testPlatformInfoSource()
PASS   : DataSourceTest::testScreenInfoSource()
PASS   : DataSourceTest::testPropertyRatioSource()
PASS   : DataSourceTest::testMultiPropertyRatioSource()
PASS   : DataSourceTest::testApplicationVersionSource()
PASS   : DataSourceTest::testQtVersionSource()
PASS   : DataSourceTest::testStartCountSource()
PASS   : DataSourceTest::testUsageTimeSource()
PASS   : DataSourceTest::testCpuInfoSource()
PASS   : DataSourceTest::testLocaleInfoSource()
./bin/datasourcetest: symbol lookup error: ./bin/datasourcetest:
undefined symbol: _ZN12UserFeedback16OpenGLInfoSourceC1Ev

I would have looked into fixing it, but I'm not sure I understand why
there's all the RPATH logic in place, so I'd prefer to hear from you
first.

A good next step would also be to get it running on build.kde.org, so
we can identify these issues.

Aleix

Re: kdereview: qqc2-desktop-style

[Marco Martin]

On Sun, May 21, 2017 at 7:16 PM, Albert Astals Cid  wrote:
> if("${CMAKE_SOURCE_DIR}" STREQUAL "${CMAKE_BINARY_DIR}")
>message(FATAL_ERROR "climbinggrades bla bla bla.")
> endif()
>
> This is not climbinggrades ;)



thanks, fixed

--
Marco Martin