Time Nick Message 00:00 octacian But you guys already require GCC 4.9+ or Clang 3.4+, both of which have complete support for C++14 00:00 octacian I kinda understand not supporting C++17 considering how new it is (although variants and the builtin filesystem library make development much nicer), but I don't understand not using C++14 00:01 octacian C++14 is IMO what C++11 should've been, and is often accepted as being a compilation of the features that should have been in C++11 but for one reason or another didn't make it 00:01 rubenwardy nerzhul ^ 00:02 octacian https://gcc.gnu.org/projects/cxx-status.html and https://clang.llvm.org/cxx_status.html, BTW 00:19 nerzhul C++11 was the target, if debian 8 & centos 6 support C++14 and android, go ahead 00:34 paramat lol, maybe in a few years 00:37 octacian Why not now though? With the compiler versions required, C++14 is already supported. 00:39 octacian IDK for sure about the specific platforms mentioned, but if it works now it'd work if the one line in CMake conf was changed to use C++14. 00:39 octacian Or at least it should. 00:40 paramat no dev time 00:41 Jordach paramat: cloudyfogcolor is not technically what the horizon is, more akin to Rayleigh scattering 00:42 octacian uhhh. It would just require replacing line 13 of CMakeLists.txt with set(CMAKE_CXX_STANDARD 14) 00:42 octacian Oh wait. set(GCC_MINIMUM_VERSION "4.8") is in the conf but 4.9 is listed in the README. That could be problematic 00:43 octacian (4.9 is the minimum that would be required for C++14) 00:43 paramat not worth risking possible issues that might delay 5.0 release, and no need to either 00:44 paramat Jordach yes, but that's irrelevant to my request 00:45 Jordach paramat: you were the one to mention renaming of m_skycolor to begin with 00:46 Jordach https://github.com/minetest/minetest/pull/7853#discussion_r232506088 :) 00:46 Jordach bgcolor is *what* some mysterious background colour? 00:48 paramat yeah i know, i'm sorry 00:49 Jordach paramat: it's fine :) 00:49 Jordach i'd rather have them be far more descriptive than something that has annoyed me for the last two pulls i've done 00:50 Jordach the only outlier in the pull being the cruel get_bgcolor (kind of vestigial naming scheme) 00:52 Jordach (but bgcolor always determined fog) 01:00 octacian Debian 8 has GCC 4.9 and Clang 3.4 in its official repositories. centos 6 has Clang 3.4 in the repositories but you have to manually compile GCC 4.9. Android would also be fine AFAIK (see https://stackoverflow.com/questions/31403014/how-to-compile-c14-code-for-android). 01:01 octacian So unless there's a ton of people using centos, I don't see how this could cause any issues. 01:03 octacian If anything, it would provide future devs who come across the project with an updated and improved set of tools with which to work (including, but not limited to, binary literals, the deprecated attribute, variable templates, generic lambdas, and improved capturing with lambdas). 01:05 paramat well, not before 5.0 release, not worth risking 01:07 octacian hmm. Really doesn't seem like there'd be any risk. C++11 code compiles fine with the compiler set to C++14. I really don't see the point of holding something that could be so useful back just because it might cause a few issues. but alright 01:08 paramat that's how desperate we are. we can always do it for 0.5.1 01:10 paramat and C++11 is fine so no rush 01:11 octacian Sure, it's fine. But when somebody knew comes along, gets excited, wants to implement something, but then discovers that it'll be harder in C++11. 01:12 octacian Desperation really doesn't seem like a good reason either though :P Instead, I think stuff such as this could contribute to people being less interested in contributing. Minetest development is something a little too paranoid (no offence to anyone, I just couldn't come up with a better way of putting it). But then too, I'm not a developer and don't really contribute anymore either, so 01:12 octacian wait. that second sentence was worded badly. sorry lol 01:12 octacian ...and so was the third 01:13 paramat good grief, really, C++11 is not a problem, if it was nerz wouldn't have spent all that time updating us to C++11 for 5.0 01:13 octacian tl;dr, holding to old standards such as C++11 might discourage newcomers. This seems to be a pattern in MT development, even simple things can end up being kinda slow. But this is only my personal observation, and I'm not really in a position to be saying much 01:14 Jordach C11 is no way near an old standard 01:14 paramat it's a non-issue and we can do it later 01:14 octacian C++11 is great compared to C++03. But C++14 is even better. 01:14 Jordach if it's not supported by XP SP3, then it's in date 01:14 rubenwardy it's definitely not an old standard on the scales of things 01:15 octacian hmmm. You're right, it isn't. However, it's a mostly adequate but often lacking standard, irregardless of its age. 01:16 paramat if C++11 was old standard, again, nerz wouldn't have done all that work intentionally move us to it for 5.0 release 01:16 octacian could someone link me to the pr where this took place? 01:16 octacian the move to C++11, that is 01:16 octacian I had it a couple days ago but can't seem to find it now. 01:17 paramat it will not discourage newcomers becasue it's such a minor issue 01:17 rubenwardy https://github.com/minetest/minetest/pull/5814 01:18 paramat any completely non-essential thing that could cause a delay for 5.0 is out of the question 01:18 rubenwardy I use miss more things from C++11 than any other standard 01:18 rubenwardy -use 01:18 rubenwardy for (auto a : b) 01:18 rubenwardy std::thread 01:18 * paramat is parannoyed 01:19 octacian I still don't understand how it would cause delay. 2 characters would need to be changed in the CMake conf. That's all. 01:19 rubenwardy moving to C++11 broke Android 01:20 paramat we never know what problems it could cause, and can't be sure 01:21 octacian Why? SO states that to use C++14 just requires adding -std=c++14 to LOCAL_CPPFLAGS and Google's doc says that libc++ (included since lollipop) supports C++17. 01:21 octacian So I'd imagine that C++11 would be just as simple, if not more so 01:22 paramat it's not even worth thinking about until after release, and we've only just updated to C++11, it's just a tiny bit too early 01:22 octacian * would have been just as simple 01:22 rubenwardy octacian: https://github.com/minetest/minetest/pull/6796 01:23 paramat no matter what you think, it might cause issues, and there's zero need to do it now 01:25 rubenwardy it's better to do it now than in a minor release 01:26 rubenwardy there is some need for C++14: https://en.cppreference.com/w/cpp/memory/unique_ptr/make_unique 01:26 rubenwardy well, actually maybe not 01:26 paramat better yes but still a bad idea 01:27 octacian the android build issues seemed just to be because the conf got out of date. Looks like the issue would've eventually arisen anyways. But I may have missed something 01:28 octacian Not only that, but with that done, chances are no further fixes would be required to bump to C++14. 01:28 paramat android is a nightmare and it's critical we don't risk breaking that now that multicraft is ending 01:32 paramat yeah indeed, no need, because MT works fine in 11 :) 01:47 octacian It does. But C++14 would provide more tools and make the project more inviting to new devs. I can't see more than a few trivial things being broken. 01:47 octacian but I'll leave it at this 01:52 paramat no harm in delaying it for a few months. the chances of a new dev being scared off over the next few months by minor differences between 11 and 14 is near-zero. if someone is, they're very silly and we're probably better off without them =) 01:54 ANAND .... 01:56 ANAND Wanted to confirm before working on this, but is this `]` an extra? https://github.com/minetest/minetest/blob/6b102ce51f01a381ab6356931689d85528455a50/builtin/mainmenu/dlg_contentstore.lua#L453 01:57 ANAND I don't see an orphaned `[` anywhere else 02:13 ANAND Alright, removing that has no effect. 02:13 ANAND Super-trivial PR #7863 02:13 ShadowBot https://github.com/minetest/minetest/issues/7863 -- Don't display page-nav buttons when #store.packages == 0 by ClobberXD 02:14 ANAND Trying to get a screenshot, but dangit the packages are loading every single time... 02:27 ANAND Hah, turned off my WiFi, and ta-da! :D 04:38 octacian what source file actually iterates over the mods directories and loads them? 04:40 octacian Oh wait, I just found it. 04:40 octacian Amazing, isn't it? Whenever you ask a simple question, you almost always find the answer yourself immediately after 04:41 ANAND Is it this? https://github.com/minetest/minetest/tree/master/src/server 04:42 ANAND Nvm, it is. :P 04:46 octacian What I was looking for was src/content/mods.h/cpp 05:16 ANAND Yeah 05:17 ANAND The dir parser is in src/server/mods.h/cpp though 05:17 ANAND src/content/mods.h is for handling mods from ContentDB, octacian 05:18 octacian Ah, good to know. It was the dir parser I was looking for, thanks 05:22 ANAND :_ 05:22 ANAND oops. :) 10:09 celeron55 octacian looks to be correct; debian stable supports C++14 now 10:09 celeron55 what about centos and ubuntu LTS? 10:11 celeron55 ubuntu LTS checks out 10:14 celeron55 well centos doesn't even have new enough gcc to suppport C++11 yet so i guess that's already dismissed 10:19 celeron55 android seems to _require_ C++17 so that works out i guess 10:20 celeron55 i don't see any reason not to use C++14 10:24 celeron55 so if you're interested in that, make a PR and ask people to test on all of the platforms 10:26 rubenwardy ANAND: false, packages.cpp is for things from cdb 10:27 rubenwardy The mods is used by both 10:29 ANAND Not the dir parser, though, which is what I meant 18:46 octacian Wait, so in yesterday's about C++ versions it was mentioned that Debian 8 would need to support whatever compiler version required. Why Debian 8 and not 9? (9 is the latest stable) 18:47 octacian *yesterday's conversation 18:48 octacian and why was CentOS 6 mentioned rather than 7? (I believe 7 is also the latest stable there) 18:49 T4im can't you just bring that up *after* the release? it really seems not to be that urgent, and i think the devs made clear yesterday they have more important things to focus on 18:50 octacian Because a major release such as 5.0 is the time to do it. Plus, I'm the one looking at it rn. Not them :P Just wanted some clarification 18:50 octacian on top of that, there is this from just after I left yesterday http://irc.minetest.net/minetest-dev/2018-11-14#i_5439185 19:10 octacian nerzhul: Wait, it was you who mentioned Debian 8 and CentOS 6 yesterday. I'm curious, is there a reason why 8 and 6 rather than 9 and 7? 19:17 rubenwardy I don't think we should bother with CentOS, which doesn't support C++11 fully anyway 19:17 rubenwardy our criteria should be Ubuntu/Debian/Android/Windows/macOS 19:17 octacian yeah, CentOS doesn't particularly matter I guess. 19:17 sofar it does for folks who run servers 19:17 sofar centos is still fairly standard 19:17 octacian I'm moreso just generally curious why the previous stable version were referred to rather than the latest 19:19 octacian IDK for sure how it works, but from what others have said you already have to compile gcc manually just to fulfill the C++11 requirement 19:19 sofar ah, well that would be a reason to ignore it, then 19:20 octacian I'm not completely sure yet, but later today I'm going to set up a VM and mess around for a few minutes 19:40 nerzhul octacian: because they are maintained 19:41 octacian But Debian Stretch (9) is the latest stable, so won't it be maintained? or have I missed something? 19:42 nerzhul no, we keep compat with the older maintained part 19:42 nerzhul and Debian 8 & Centos 6 are maintained and we must have compat with them 19:44 octacian ah. So you keep compatibility with the oldest maintained release, correct? 19:46 nerzhul right 19:46 nerzhul based on centos/debian, other are not interesting 19:51 octacian alright, fair enough.