[09:23:58] Hi, I tried to configure a development environment on my Windows computer but I failed :( [09:24:25] when I try to open project in QT Creator I have a cmake error which can not find "Qt5WebEngine" [09:27:46] I'm very new to Qt so I don't know how to fix it... [14:11:26] Change on 12en.wikipedia.org a page Wikipedia:Huggle/Users was modified, changed by Bailo26 link https://en.wikipedia.org/w/index.php?diff=1007507067 edit summary: Adding [[Special:Contributions/Bailo26|Bailo26]] ([[WP:HG|HG]]) (3.4.10) [18:27:56] petan: around? I had a few questions for you. [18:28:08] yes [18:28:25] Shawn__: hello [18:29:55] you need to open the build configuration, there in cmake settings it should be possible to specify a path, or it's possible to do that via CMake GUI, or command line, to be honest I didn't use qtcreator on Windows for years to build it, I use only MSVC [18:30:39] check out this PS script https://github.com/huggle/huggle3-qt-lx/blob/master/windows/release.ps1 that's what I use to generate setup.exe [18:31:05] you launch it like this: ..\windows\release.ps1 -cmake_generator "Visual Studio 14 2015 Win64" -vcinstall_path "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\" -msbuild_path "C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" -vcredist vcredist_x64.exe -python $false -qt5_path "D:\libs\Qt\5.10.1\msvc2015_64\" -openssl_path "C:\OpenSSL-Win64_v1.0.2r" [18:31:05] Ok, so I'm kinda idly working on building a Fedora package for Huggle (so Fedora users can just install it from their package manager instead of needing to build it themselves), and I'm running into a few problems, and I'm wondering if you can help with them. [18:31:11] of course the paths need to be adjusted [18:31:46] Shawn__: compiling huggle on Windows is hard-core, you might want to just download that linux .iso from https://github.com/huggle/huggle3-qt-lx/wiki/Portable-development-environment [18:32:32] phuzion: hmm maybe I can, what problems exactly? [18:32:55] The first issue is that files are being installed to /usr/local/lib instead of /usr/lib. This will fail Fedora Packaging guidelines. [18:33:22] Another is that all .so files are being installed to the lib folder, even if compiled on a 64-bit machine. Those SOs should be installed to lib64 [18:33:26] hello petan, I just succeed building it 64bits using veyor.ps1 that I tweaked a bit [18:33:39] aha ok :) [18:33:44] that's what we use for nightly builds [18:33:46] !night [18:33:46] http://petr.insw.cz/huggle/nightly/huggle3.zip [18:35:13] phuzion: hmm I am not sure how to fix that, AFAIK all distro recommend to install custom-built / non-packaged software to /usr/local so that's what happens now when you just make install [18:35:31] I was trying to use Qt Creator in order to run Huggle in debug step by step [18:35:36] there should probably be some switch or override in CMake so that when you perform an actual "proper packaging" it goes to different paths [18:35:44] Yeah that's what I was thinking too, petan. [18:35:45] I wonder how other software does it [18:36:02] Shawn__: visual studio can also debug step by step [18:36:49] I don't even know if latest webengine binaries are shipped for mingw, I think not, I believe at some point Qt just stopped being fully supported with mingw on windows, also the performance was much worse compared to VC++ [18:37:32] ok, I'm currently trying to run it in Visual Studio [18:38:09] if you already managed to use that veyor script to build it, then there should be a preconfigured folder called "build" in which it builds [18:38:21] inside is a project file you can easily open in visual studio, everything will be configured [18:44:58] when I try to run it tries to launch "ALL_BUILD" [18:45:28] you can right click project and setup as startup [18:55:22] ok nice [18:55:56] it runs huggle.exe but it seems that each subproject is compiled in a different directory so huggle.exe complains that it miss huggle_ui.dll [19:03:26] hmm I think that is somehow sorted out with that ps script [19:03:41] but I don't really remember it's been a while I was working on it, last Windows release is from last year [19:03:54] which reminds me I promised another release :P [19:04:15] petan: https://cmake.org/cmake/help/v3.14/module/GNUInstallDirs.html this might be useful for fixing the lib vs lib64 issue. [19:06:22] ok so the best way to do is using the VM and work on Linux and then build on windows, isn't it ? [19:24:27] petan For information, the syntax for block-expiry-options is not correct in DefaultConfig.yaml (https://www.mediawiki.org/wiki/Manual:Huggle/Deploying/DefaultConfig.yaml) [19:25:04] interesting, you are welcome to fix that :) [19:25:58] Heh [19:26:03] it should be possible to work on Windows as well, just setup is a little bit harder, you need to probably update search paths in project config so it finds all these .dll [19:26:53] As it is loaded as a string in projectconfiguration.cpp I need to put double quotes instead of [ ] [19:27:07] I'm not sure if it's a bug or if the config sample is wrong [19:27:50] there are some issues on block user window. This is why I'm trying to investigate huggle source code [19:28:05] the config is parsed using yaml-cpp library [19:28:38] I did two weeks of C++ lessons on 2006 so it is very difficult for me to understand all those CMakeLists [19:29:36] cmake is just universal makefile generator, it makes it easier to build Huggle across all the platforms [19:29:52] on its own it's not really in any way part of C++ as language [19:31:31] petan Yes but some lists are read with YAML2QStringList and this one is read simply with YAML2String [19:31:51] I'm not sure if there is a reason [19:40:21] Yeah ! Success, I started Huggle in debug in QtCreator in the VM [19:40:45] petan: ok I'm pretty sure I've figured out the lib vs lib64 issue, let me make some changes and I'll submit a PR shortly. [19:41:04] Shawn__: Nice! It's always exciting when you get everything compiled and launched [19:43:33] Cool I fixed a first bug ! (blocktime-anon parameter is not taken into account) [19:44:17] Do you know what happens when user has reached the maximum warning level ? [19:45:23] !! [19:45:23] There are multiple keys, refine your input: !huggle3, !todolist, [19:45:26] no, shut [19:45:37] !todolist [19:45:37] http://etherpad.wikimedia.org/Huggle-dev-pad [19:45:39] huh [19:46:34] Shawn__: If you've found a bug, please report it on Phabricator. [19:46:37] !phabricator [19:46:37] http://phabricator.wikimedia.org/ [19:46:48] !help [19:46:48] If you need help, write an email to huggle@lists.wikimedia.org or ask a voiced user. Maybe petan, mmovchin, Elsensee or IWorld are online? [19:47:00] whoops, sorry, didn't mean to ping y'all [19:47:35] Thanks phuzion, I wanted to try to fix it by myself to see if I'm able to make changes into Huggle [19:48:41] Shawn__: Even if you fix the bug yourself, it's useful to document it on Phabricator, that way if someone else runs into the same bug, or if someone's trying to figure out what you were doing when you committed the code, there's record of what happened and why. [19:59:51] phuzion ok I'm currently on phabricator, trying to understand how it works... [20:00:15] wow there are a lot of tickets [20:03:18] Shawn__: This will help you narrow it down. https://phabricator.wikimedia.org/project/profile/520/ [20:32:42] petan: PR submitted on huggle and libirc to fix the lib vs lib64 issue. [20:33:36] phuzion: I'll run a test build on Windows in a moment [20:33:57] RichSmith: Awesome, thanks. Shouldn't break anything, but I'd rather be safe than sorry, y'know? Don't wanna be the guy that broke Huggle for Windows users. [20:34:04] Yep yep [20:35:46] I mean, the AppVeyor build should tell us whether it breaks anything, but if you wanna run a build yourself, who am I to stop you? [20:41:29] Nope, you are quite right... [20:41:34] Saves me a hassle [20:45:51] phuzion: Looks to work correctly [20:46:56] RichSmith: Awesome. I didn't think anything would break, but better safe than sorry, y'know? [20:47:32] Anyways, I'm heading out of the office, I'll be back online a little later. Feel free to ping me if anything is broken with that build (macOS users maybe?) [20:47:45] The Mac build on Travis was fine [21:03:16] I'm always available if more thorough macOS testing is needed (although it sounds like it isn't :)).