[00:55:39] Change on 12en.wikipedia.org a page Wikipedia:Huggle/Feedback was modified, changed by つがる link https://en.wikipedia.org/w/index.php?diff=1006094314 edit summary: /* Linux Mint 20 */ r [02:57:55] Change on 12en.wikipedia.org a page Wikipedia:Huggle/Users was modified, changed by Chlod link https://en.wikipedia.org/w/index.php?diff=1006109724 edit summary: Adding [[Special:Contributions/Chlod|Chlod]] ([[WP:HG|HG]]) (3.4.10) [18:05:42] If I wanted to build huggle using a packaged version of Yaml-CPP rather than the bundled version, would anyone have any guidance on how to do so? I'm planning on packaging Huggle for Fedora and using bundled third party deps is basically forbidden. [18:05:53] I'm also going to have to package libirc, but I'll handle that later. [21:49:24] phuzion: I don't think it's going to be too complicated as long as you use version that Huggle will compile with, you may need to adjust some include paths in worst case [21:50:26] cmake is already building yaml-cpp as a shared library, so it's never statically linked into huggle [21:50:53] only difference is that it's going to be some extra hassle, which is basically reason why it's not done this way already [21:51:16] petan: Yeah I'm slowly working my way through it. ./configure does need a patch so it doesn't complain about src/3rd/yaml-cpp not existing, but for the most part, I'm making some progress. Most of the issues I'm having right now seem to be with my incompetence at packaging for Red Hat systems, but I do feel like we may need some minor patches upstream at some point. [21:51:50] Basically, the only thing I have to do right now in the .spec is to comment out the part in configure where it checks for src/3rd/yaml-cpp and .zip, and then remove those directories. [21:51:56] I had high hopes for cpack, and later for snapcraft [21:52:12] but both ended up being rather failures [21:52:20] great in theory, terrible in practice [21:52:35] petan: also, do you have instructions on how to compile libirc separately by chance? I will need to package that separately. [21:52:55] you can easily just run CMake for that CMakeLists.txt that comes with libirc [21:54:08] I get this when running cmake in the libirc directory. https://gist.github.com/phuzion/f6daa4cd128e6b0a5f7e2128851a66e0 [21:54:25] But I can compile huggle no problem. [21:55:51] just go to src/3rd/libirc/libircclient/release and run [21:56:06] mkdir release; cd release; cmake .. -DCMAKE_PREFIX_PATH:PATH=~/Qt/5.15.2/clang_64/ -DQT5_BUILD=true [21:56:19] replace ~/Qt/ with location you have qt in [21:56:26] if it's installed system wide, probably no need to do that at all [21:57:24] There is no release directory in src/3rd/libirc/libircclient [21:59:41] yes that's why first command was "mkdir release" ;_ [21:59:42] ;) [21:59:48] oh haha [22:01:12] I also had to add set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") to the CMakeLists.txt though [22:03:39] it's actually a bit more complicated as libircclient is depending on libirc... you need to create a new CMakeLists.txt in folder above (eg. subfolder in which you can find both libirc and libircclient) and put these 3 lines in there: [22:03:53] petr.bena@MacBook:/tmp/phuzion/libirc/release$ cat ../CMakeLists.txt [22:03:54] set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") [22:03:55] add_subdirectory("libirc") [22:03:56] add_subdirectory("libircclient") [22:04:16] then you can run cmake and it will build [22:04:45] I can see libirc.dylib and libircclient as result, on linux you should see .so (shared object) [22:06:42] btw libirc is part of another project of mine, this very IRC client I am writing these answers on ;) [22:07:07] but I never needed to ship libirc separately, so I never made a dedicated cmake lists for it [22:07:35] maybe I should put some instructions at https://github.com/grumpy-irc/libirc [22:07:41] Ah. If it wouldn't be too much trouble, could you update the upstream repo with it? It would make packaging a lot easier on my part. [22:07:55] Because I will eventually need to package it in order to package Huggle for Fedora. [22:08:01] Yaml-cpp is already packaged. [22:08:21] And those are the only two bundled packages that I have found so far. [22:08:23] yes, I can do that, hopefuly it won't break anything [22:08:30] Awesome. I appreciate it. [22:13:39] https://github.com/grumpy-irc/libirc/commit/60571542f1a62b0717179ddcb77b37cd261205b8 [22:18:11] petan: https://gist.github.com/phuzion/617bc7d26d6e1bcecda4f36fe732fa27 [22:18:26] No project() and no cmake_minimum_required() [22:19:38] yeah, it is an extremely minimal cmake lists, I was surprised it actually works :) [22:19:53] Hah, fair. [22:20:04] Anyways, my laptop is dying, so I'm gonna head out. I'll be back later tonight. [22:20:17] For my own reference, petan, which timezone are you in? [22:20:29] I don't want to be pinging you at 4am your time or something. [22:20:56] GMT+1 [22:21:15] Noted. Thanks [22:21:20] Anyways, ttyl. [22:21:41] I added these 2 lines [22:21:48] now it doesn't complain [23:24:59] petan: oh nice, thanks for that! I was helping phuzion with packaging work a bit. It built for me on Fedora 33 without -std=c++11 (I think f33's g++ defaults to c++14). And I originally got the client to build by patching its CMakeLists.txt with a link_directories()/-L pointing at the libirc dir. But a toplevel file is better.