| 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:23 |
|
proller__ joined #minetest-dev |
| 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:12 |
|
Cornelia joined #minetest-dev |
| 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 joined #minetest-dev |
| 02:27 |
ANAND |
Hah, turned off my WiFi, and ta-da! :D |
| 02:55 |
|
paramat joined #minetest-dev |
| 03:24 |
|
ssieb joined #minetest-dev |
| 03:25 |
|
ANAND_ joined #minetest-dev |
| 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. :) |
| 06:07 |
|
ichoquo0Aigh9ie joined #minetest-dev |
| 08:36 |
|
troller joined #minetest-dev |
| 08:38 |
|
troller joined #minetest-dev |
| 09:21 |
|
Jordach joined #minetest-dev |
| 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 |
| 10:58 |
|
T4im joined #minetest-dev |
| 11:14 |
|
Taoki joined #minetest-dev |
| 11:40 |
|
ANAND joined #minetest-dev |
| 12:18 |
|
Fixer joined #minetest-dev |
| 12:24 |
|
Fixer_ joined #minetest-dev |
| 12:34 |
|
Wuzzy joined #minetest-dev |
| 12:39 |
|
Beton joined #minetest-dev |
| 13:05 |
|
calcul0n joined #minetest-dev |
| 13:39 |
|
longerstaff13 joined #minetest-dev |
| 13:40 |
|
indiana joined #minetest-dev |
| 14:08 |
|
Jordach joined #minetest-dev |
| 14:41 |
|
ANAND joined #minetest-dev |
| 14:42 |
|
ANAND joined #minetest-dev |
| 15:11 |
|
yusf[m] joined #minetest-dev |
| 16:45 |
|
octacian joined #minetest-dev |
| 16:46 |
|
YuGiOhJCJ joined #minetest-dev |
| 17:30 |
|
ssieb joined #minetest-dev |
| 18:22 |
|
troller joined #minetest-dev |
| 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:12 |
|
Gael-de-Sailly joined #minetest-dev |
| 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. |
| 20:05 |
|
troller joined #minetest-dev |
| 20:21 |
|
troller joined #minetest-dev |
| 20:27 |
|
Mensious joined #minetest-dev |
| 20:37 |
|
crazyR joined #minetest-dev |
| 21:08 |
|
paramat joined #minetest-dev |
| 21:41 |
|
Fixer joined #minetest-dev |
| 21:47 |
|
Fixer_ joined #minetest-dev |
| 21:48 |
|
Ruslan1 joined #minetest-dev |
| 21:56 |
|
longerstaff13 joined #minetest-dev |
| 21:56 |
|
longerstaff13 joined #minetest-dev |
| 22:56 |
|
Taoki joined #minetest-dev |
| 23:44 |
|
rom1504 joined #minetest-dev |
