| PureTryOut[m] | Got it, I was missing a single character π | 08:48 |
|---|---|---|
| PureTryOut[m] | Now every application/library depending on libglacierapp compiles fine like before | 08:50 |
| aa13q | great! | 09:17 |
| * PureTryOut[m] is now working on porting qtquickcontrols-nemo to CMake | 09:18 | |
| PureTryOut[m] | Actually, it seems that for QML plugins CMake is not yet supported, https://github.com/qt/qtquickcontrols2 has some WIP CMake stuff but all undocumented. I guess I'll skip that package for now and do some applications instead | 11:19 |
| *** norayr is now known as inky | 12:10 | |
| PureTryOut[m] | https://github.com/nemomobile-ux/glacier-calc/pull/1 | 13:40 |
| PureTryOut[m] | CMake support for glacier-calc βοΈ | 13:41 |
| PureTryOut[m] | <AndrewBranson[m4 "I saw they'd dumped their new qb"> qbs is indeed dumped, qmake will be dumpend once Qt6 hits (which is this year iirc). A CMake project can work fine with a QMake project, I just don't see a point of having 2 build systems within 1 project | 13:41 |
| SergeyChupligin4 | <PureTryOut[m] "CMake support for glacier-calc β"> But needed spec file changes because nemo build files | 13:41 |
| SergeyChupligin4 | * But needed spec file changes because nemo build fail | 13:41 |
| PureTryOut[m] | <SergeyChupligin4 "https://www.youtube.com/watch?v="> That is really smooth, nice! | 13:41 |
| SergeyChupligin4 | * But needed spec file changes because nemo build false | 13:41 |
| PureTryOut[m] | Again, I don't know RPM, so I need some help with spec file changes | 13:41 |
| PureTryOut[m] | And I can't test it either | 13:42 |
| PureTryOut[m] | (the spec file that is) | 13:42 |
| SergeyChupligin4 | <PureTryOut[m] "Again, I don't know RPM, so I n"> https://build.merproject.org/package/view_file/home:neochapay:mer:core/libzypp/_service:tar_git:libzypp.spec?expand=1 like example | 13:45 |
| PureTryOut[m] | Thanks, exactly what I need | 13:45 |
| AndrewBranson[m4 | <PureTryOut[m] "qbs is indeed dumped, qmake will"> like I said, it would just remove the need to migrate every project using the old qmake to cmake. cmake will just be the default build system in qt6 - qmake isn't being removed. it seems premature to force it. | 13:47 |
| PureTryOut[m] | You don't have to migrate every project to qmake if you just build something with CMake | 13:48 |
| PureTryOut[m] | Like I mentioned in the MR, I managed to build a QMake project depending on the now CMake project perfectly fine | 13:49 |
| PureTryOut[m] | You can just do every project one-by-one | 13:49 |
| AndrewBranson[m4 | you say in that mr that qmake is being removed in qt6. that's not correct, isit? | 13:50 |
| PureTryOut[m] | Let me check to make sure | 13:50 |
| AndrewBranson[m4 | yeah that's a good idea. the article I saw suggested that cmake wouldn't be integrated enough to replace qmake until qt6 even | 13:51 |
| PureTryOut[m] | (I heard this in a presentation from the Qt company on the last KDE Akademy, but I'm not sure if there is a written source) | 13:51 |
| AndrewBranson[m4 | if that's the case then it would be better to keep both until qt6 is released and stable | 13:51 |
| PureTryOut[m] | Then again I still don't get why you would want to support 2 systems | 13:52 |
| PureTryOut[m] | Again, a CMake project can work together with QMake projects perfectly fine | 13:52 |
| AndrewBranson[m4 | maybe I'm misunderstanding. say you wanted to port an existing qt mobile app from another distro. that's likely to be .pro file based. would that need to be migrated to cmake as part of that porting efffort? | 13:53 |
| AndrewBranson[m4 | because if that's the case then I think you're better including both build systems to make it easier for people to port things | 13:53 |
| PureTryOut[m] | <AndrewBranson[m4 "maybe I'm misunderstanding. say "> No | 13:53 |
| PureTryOut[m] | As long as you still install the usual pkg-config stuff, any non-cmake project can depend on a cmake project perfectly fine | 13:53 |
| PureTryOut[m] | In the libglacierapp example I made CMake generate this pkg-config file, and a qmake project doesn't have to be modified to use it | 13:54 |
| PureTryOut[m] | I've ported glacier-calc to CMake now as well, but e.g. glacier-music is still .pro file based and still picks up libglacierapp and compiles against it perfectly fine | 13:55 |
| AndrewBranson[m4 | i don't mean a dependency. i mean if someone wants to take a qtcreator project source tree for an app and build it for nemo | 13:56 |
| PureTryOut[m] | Then I don't understand your question π€ | 13:56 |
| AndrewBranson[m4 | how do you build glacier-music? | 13:57 |
| PureTryOut[m] | Just the usual, `qmake && make` | 13:57 |
| AndrewBranson[m4 | but i thought you didn't have qmake? | 13:58 |
| PureTryOut[m] | I never said I don't have qmake? | 13:58 |
| AndrewBranson[m4 | you're dropping qmake for cmake? | 13:58 |
| AndrewBranson[m4 | because you don't want to support 2 build systems? | 13:58 |
| PureTryOut[m] | I'm not sure I understand. In case of libglacierapp, yes I'm dropping qmake for cmake. We could keep cmake, but then you have to support 2 build systems which I indeed don't want. Mainly because it's completely unnecessary | 13:58 |
| PureTryOut[m] | * I'm not sure I understand. In case of libglacierapp, yes I'm dropping qmake for cmake. We could keep qmake, but then you have to support 2 build systems which I indeed don't want. Mainly because it's completely unnecessary | 13:58 |
| AndrewBranson[m4 | if you drop qmake, then how will you build glacier-music? | 13:59 |
| PureTryOut[m] | I just explained that lol. QMake picks up other dependencies by using the pkg-config files from those dependencies. With CMake, I still generate and install that pkgconfig file | 13:59 |
| PureTryOut[m] | So glacier-music still picks up and compiles against libglacierapp like nothing happened, as in it's eyes, nothing did change to libglacierapp | 14:00 |
| AndrewBranson[m4 | it's not very clear :) | 14:01 |
| AndrewBranson[m4 | i think you're saying you're switching packages over to cmake from qmake, but not to remove qmake entirely, which is implied when you talk about supporting two build systems. | 14:01 |
| PureTryOut[m] | No I am removing qmake entirely, just not pkg-config, which qmake uses | 14:01 |
| AndrewBranson[m4 | you're removing the use of qmake, or the ability to run qmake for any building? | 14:01 |
| PureTryOut[m] | The relevant bit is this: https://github.com/nemomobile-ux/libglacierapp/pull/4/files#diff-95e351a3805a1dafa85bf20b81d086e6R21 | 14:01 |
| PureTryOut[m] | That installs `/usr/lib/pkg-config/glacierapp.pc`. QMake in e.g. glacier-music sees that and then knows how to link against it | 14:01 |
| PureTryOut[m] | <AndrewBranson[m4 "you're removing the use of qmake"> The use of QMake | 14:01 |
| AndrewBranson[m4 | because you keep talking about both removing qmake and using it | 14:02 |
| PureTryOut[m] | Using QMake in glacier-music, removing it from libglacierapp | 14:02 |
| AndrewBranson[m4 | ok, that's different then. you're still supporting it for building apps then. | 14:02 |
| PureTryOut[m] | (glacier-music being an example where I haven't removed it yet) | 14:02 |
| PureTryOut[m] | Well not explicitely. We're supporting any build system that uses pkg-config files, which QMake is one off | 14:03 |
| PureTryOut[m] | You can even build a project with Meson and have it link to libglacierapp fine | 14:03 |
| AndrewBranson[m4 | because saying 'Then again I still don't get why you would want to support 2 systems' implies that only one can be used | 14:03 |
| AndrewBranson[m4 | yes, i'd expect meson support to be very important too | 14:03 |
| PureTryOut[m] | <AndrewBranson[m4 "because saying 'Then again I sti"> Well supporting people using either qmake or cmake to build libglacierapp then | 14:03 |
| SergeyChupligin4 | move to cmake it's good | 14:03 |
| AndrewBranson[m4 | yes, that's clearer :D | 14:03 |
| SergeyChupligin4 | remove qmake not good | 14:04 |
| PureTryOut[m] | Sorry for any confusion | 14:04 |
| AndrewBranson[m4 | but don't stop people using qmake or meson in their projects, or you'll discourage devs for port their apps over | 14:04 |
| PureTryOut[m] | I'm not π | 14:04 |
| PureTryOut[m] | I'm just switching the method of building of libglacierapp | 14:04 |
| AndrewBranson[m4 | yes, that's good ;) | 14:05 |
| PureTryOut[m] | People can still use qmake or Meson to build their application depending on libglacierapp | 14:05 |
| PureTryOut[m] | or <any other build system that uses pkg-config internally> | 14:05 |
| AndrewBranson[m4 | i don't see why you'd have both cmake and qmake files in the same project either, if that's what you meant there :) | 14:05 |
| PureTryOut[m] | That is exactly what I meant yes π | 14:05 |
| PureTryOut[m] | Glad we understand each other now lol | 14:05 |
| AndrewBranson[m4 | but in the sailfish sdk, those build tools have to be explicitly packaged in the sdk to be able to use them | 14:06 |
| AndrewBranson[m4 | the sdk is a chroot that contains all teh build toold | 14:06 |
| AndrewBranson[m4 | so to support qmake and meson, sailfish has to build those | 14:07 |
| AndrewBranson[m4 | thus 'support' them | 14:07 |
| PureTryOut[m] | Do note that some sailfish stuff already uses CMake, for example mapplauncherd | 14:07 |
| PureTryOut[m] | <AndrewBranson[m4 "so to support qmake and meson, s"> Yeah ofc | 14:07 |
| * aa13q agrees but still dreaming about something like dropping meson/qmake/etc and focus on qbs only for everything in the super-long term π π π | 14:07 | |
| AndrewBranson[m4 | is that different in what you're doing | 14:08 |
| AndrewBranson[m4 | yeah sailfish supports cmake, qmake, autotools, meson | 14:08 |
| AndrewBranson[m4 | maybe more. but if it isn't there, you can't use it. | 14:08 |
| AndrewBranson[m4 | meson is pretty cool | 14:08 |
| PureTryOut[m] | Meson is pretty cool indeed, but not suitable for Qt projects atm afaik | 14:08 |
| AndrewBranson[m4 | maybe for qt7 π | 14:08 |
| PureTryOut[m] | We'll see haha | 14:08 |
| aa13q | or qt8 :DD | 14:08 |
| PureTryOut[m] | Sergey ΠΠ³ΠΎΡΠ΅Π²ΠΈΡ Chupligin: so since there was some confusion from Andrew Branson and I want to make it clear: | 14:09 |
| PureTryOut[m] | libglacierapp can still be used by qmake-based projects. I'm just removing the use of qmake while building libglacierapp itself | 14:09 |
| AndrewBranson[m4 | pkgconfig is definitely the best approach. very portable then. | 14:17 |
| AndrewBranson[m4 | pkgconfig dependencies in rpm builds are wonderful | 14:17 |
| PureTryOut[m] | Yeah pkgconfig is really useful for this. Then it doesn't matter what build system you're using for individual projects | 14:17 |
| aa13q | <AndrewBranson[m4 "pkgconfig dependencies in rpm bu"> Agree! It's called rpm dependency generator or something, very nice. We talked about it with @Kaffeine recently. He said that there are even some `rpm-build-qml` extensions, where you could not only write some `Requires: pkgconfig(ssl)`, but also `Requires: qml(org.kde.plasma.core)` He said it would be nice to share this logic with PkgConfig someday, then it probably | 14:37 |
| aa13q | would be possible to ask build systems to install dependencies no matter how exact system packages are called (hope I covered his thought correctly) | 14:37 |
| AndrewBranson[m4 | that sounds really cool | 14:40 |
| SergeyChupligin4 | failed to export dumb buffer: Permission denied on all aplications start | 14:40 |
| PureTryOut[m] | Oh hey Alexander! | 15:05 |
| PureTryOut[m] | https://github.com/nemomobile/qtdbusextended/pull/3 | 15:44 |
| PureTryOut[m] | Andrew Branson: would you know if there is interest in Sailfish to switch some packages over to use CMake as well? | 15:46 |
| mal | based on some qt blog qmake is still available but won't be developed anymore, was it really removed? | 15:47 |
| PureTryOut[m] | Yeah that is wrong wording on my part probably. I don't have a written source for it but I understood so from a Qt presentation on last KDE Akademy | 15:49 |
| mal | they move to cmake in all qt projects https://www.qt.io/blog/2019/08/07/technical-vision-qt-6 | 15:50 |
| PureTryOut[m] | > We will continue to support our users on QMake, but not develop it further or use it to build the Qt framework itself. | 15:51 |
| PureTryOut[m] | Good to know, thanks for the link! | 15:51 |
| PureTryOut[m] | Andrew Branson: but I'm willing to make the changes, for a few packages anyway, and I'm probably not going to do any other improvements to most of those packages π I just want to know if Sailfish/Jolla is willing to accept MR's that switch qmake to cmake for packages | 16:59 |
| PureTryOut[m] | Oh really? Interesting | 17:18 |
| PureTryOut[m] | That seems limiting tbh but sure I'll not put any effort into it then π | 17:18 |
| PureTryOut[m] | Yeah probably not | 17:22 |
| PureTryOut[m] | So, would it or would it not be accepted then? π | 17:33 |
| PureTryOut[m] | Currently I'm mainly thinking of doing qtmpris, which is probably a platform thing anyway | 17:34 |
| AndrewBranson[m4 | well it could be if it build on obs. but i think if you did it you'd have to justify why :D | 17:39 |
| PureTryOut[m] | Hmm well ok | 17:39 |
| PureTryOut[m] | Let's just stick to the Nemo stuff for now then | 17:39 |
| PureTryOut[m] | https://github.com/nemomobile-ux/glacier-music/pull/2 | 18:22 |
| PureTryOut[m] | <SergeyChupligin4 "Application run fail, sometimes "> Woohoo! | 18:22 |
| *** verin0x7 is now known as verin0x | 23:07 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!