[KDE/Mac] Review Request 124894: [OS X] make it build
Kevin Ottens
ervin at kde.org
Thu Aug 27 16:37:15 UTC 2015
> On Aug. 27, 2015, 5:41 a.m., Kevin Ottens wrote:
> > src/domain/queryresultprovider.h, lines 35-40
> > <https://git.reviewboard.kde.org/r/124894/diff/2/?file=399196#file399196line35>
> >
> > And don't forget to put that part in the new header. ;-)
>
> René J.V. Bertin wrote:
> But that's *only* required in this header, and shouldn't be included in code that doesn't load the QSharedPointer definition. I found that out the hard way, so there are that kind of files which also use mem_fn. I could of course test for the token that gets set by the headerfile defining QSharedPointer, but is user code supposed to do that kind of thing?
>
> Kevin Ottens wrote:
> It would be only activated in the boost case. Also I guess there's a way to not make it dependent on QSharedPointer if that's parameterized as well. What we really want is for it to work with any smart pointer type which has a data() method to get to the raw pointer.
>
> René J.V. Bertin wrote:
> The easiest way to handle the QSharedPointer case is like this:
>
> ```
> # ifdef QSHAREDPOINTER_H
> namespace boost {
> template<class T> T* get_pointer(const QSharedPointer<T> &pointer)
> {
> return pointer.data();
> }
> }
> # endif
>
> # include <boost/mem_fn.hpp>
> ```
>
> but the real problem I have is with defining a mem_fn wrapper. mem_fn is a wrapper itself already, and according to the boost docs there are at least 7 overloads each with its own "unspecified" return type : http://www.boost.org/doc/libs/1_55_0/libs/bind/mem_fn.html#mem_fn . It seems likely that those types will vary from std implementation to implementation ...
>
> I'm now trying the following shot in the dark, seeing what it leads to:
>
> ```
> namespace Utils {
> template <class Ret, class T> void* mem_fn(Ret T::*f)
> {
> # ifdef ZANSHIN_USE_BOOST_MEM_FN
> return boost::mem_fn<Ret, T>(f);
> # else
> return std::mem_fn<Ret, T>(f);
> # endif
> }
> }
> ```
>
> René J.V. Bertin wrote:
> And with that compilation fails at some point of course, because of the `void*` ...
I would be surprised if there's no way to deal with QSharedPointer by making the pointer type a template parameter as well. I seem to remember doing that in the past but my brain is fried right now I can't recall.
But yes, it's kind of along those lines for the mem_fn wrapper. You might want to use std::function to make dealing with the the return type easier and use variadic templates to deal with the arguments of the function.
- Kevin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124894/#review84439
-----------------------------------------------------------
On Aug. 26, 2015, 9:12 p.m., René J.V. Bertin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124894/
> -----------------------------------------------------------
>
> (Updated Aug. 26, 2015, 9:12 p.m.)
>
>
> Review request for KDE Software on Mac OS X and Zanshin.
>
>
> Repository: zanshin
>
>
> Description
> -------
>
> This is a set of patches that allow zanshin version `0.2.1-1163-gbf5c321` to build on OS X against the git head (or almost head) of kdelibs 4.14 and kdepim* 4.14 .
> I presume for now that a number of changes are self-explanatory (for instance, `zanshinkdepimstatic` calls itself static, isn't installed and doesn't export any symbols explicitly so all points to it being intended to be a static instead of a shared lib).
> The patches that disable a number of tests, and I do not understand myself what exactly goes wrong without them other than that the linker gives errors like
>
> ```
> # Undefined symbols for architecture x86_64:
> # "decltype(*(std::__1::forward<QSharedPointer<Domain::QueryResult<QString> > >(fp0)).*fp(std::__1::forward<>(fp1))) std::__1::__invoke<QList<std::__1::function<void (QString, int)> > (Domain::QueryResult<QString>::*&)() const, QSharedPointer<Domain::QueryResult<QString> >, void>(QList<std::__1::function<void (QString, int)> > (Domain::QueryResult<QString>::*&&&)() const, QSharedPointer<Domain::QueryResult<QString> >&&)", referenced from:
> # std::__1::__function::__func<std::__1::__mem_fn<QList<std::__1::function<void (QString, int)> > (Domain::QueryResult<QString>::*)() const>, std::__1::allocator<std::__1::__mem_fn<QList<std::__1::function<void (QString, int)> > (Domain::QueryResult<QString>::*)() const> >, QList<std::__1::function<void (QString, int)> > (QSharedPointer<Domain::QueryResult<QString> >)>::operator()(QSharedPointer<Domain::QueryResult<QString> >&&) in queryresulttest.o
> # ld: symbol(s) not found for architecture x86_64
> # clang: error: linker command failed with exit code 1 (use -v to see invocation)
> ```
>
> Possibly a comparable to the reason why I had to define the `std::accumulate` functions.
>
>
> Diffs
> -----
>
> 3rdparty/kdepim/libkdepim/CMakeLists.txt cc8845a
> 3rdparty/kdepim/libkdepim/tests/CMakeLists.txt 775ac0e
> CMakeLists.txt 71b16a8
> src/akonadi/akonadiserializer.cpp 5116fa5
> src/domain/queryresultprovider.h 5d0b02d
> src/presentation/errorhandler.cpp 5610040
> tests/testlib/akonadistoragetestbase.cpp 8573374
> tests/units/akonadi/akonadidatasourcequeriestest.cpp c2e87dc
> tests/units/widgets/applicationcomponentstest.cpp f972673
>
> Diff: https://git.reviewboard.kde.org/r/124894/diff/
>
>
> Testing
> -------
>
> On OS X 10.9.5 with the system compiler (`Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)`)
>
> My initial reason to install this was to "check it out" and learn how to use it, so I have not done any further testing ...
>
>
> File Attachments
> ----------------
>
> datasourcequeriestest.cpp preprocessed by Apple Clang 6
> https://git.reviewboard.kde.org/media/uploaded/files/2015/08/24/b2f3e229-ca5a-4e55-b33b-6504b2cdb5c7__datasourcequeriestest-AppleClang6.i
> datasourcequeriestest.cpp preprocessed by clang 3.6.1
> https://git.reviewboard.kde.org/media/uploaded/files/2015/08/24/807e30a4-aa34-45b4-9e5c-92020ee8c7f5__datasourcequeriestestClang3.6.i
>
>
> Thanks,
>
> René J.V. Bertin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150827/cfdfa292/attachment.html>
More information about the kde-mac
mailing list