| Time |
Nick |
Message |
| 00:29 |
|
Baytuch joined #minetest-dev |
| 00:32 |
|
Baytuch joined #minetest-dev |
| 00:35 |
|
Yad joined #minetest-dev |
| 00:39 |
|
Baytuch joined #minetest-dev |
| 00:42 |
|
Baytuch joined #minetest-dev |
| 00:59 |
|
Soni joined #minetest-dev |
| 01:01 |
|
Baytuch joined #minetest-dev |
| 01:25 |
|
Baytuch joined #minetest-dev |
| 01:57 |
|
Yad_ joined #minetest-dev |
| 02:21 |
|
Baytuch joined #minetest-dev |
| 02:55 |
|
Baytuch joined #minetest-dev |
| 03:00 |
|
Baytuch joined #minetest-dev |
| 03:20 |
|
YuGiOhJCJ joined #minetest-dev |
| 03:39 |
|
Baytuch joined #minetest-dev |
| 03:51 |
|
luk3yx joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:08 |
|
Baytuch joined #minetest-dev |
| 05:08 |
|
BuckarooBanzai joined #minetest-dev |
| 05:08 |
|
basxto joined #minetest-dev |
| 05:28 |
|
Baytuch joined #minetest-dev |
| 05:53 |
|
Baytuch joined #minetest-dev |
| 06:10 |
|
calcul0n joined #minetest-dev |
| 06:46 |
|
Baytuch_2 joined #minetest-dev |
| 07:25 |
|
Baytuch joined #minetest-dev |
| 07:55 |
|
Baytuch joined #minetest-dev |
| 08:40 |
|
erle joined #minetest-dev |
| 09:32 |
|
HuguesRoss joined #minetest-dev |
| 09:52 |
|
MTDiscord joined #minetest-dev |
| 10:33 |
|
Warr1024 joined #minetest-dev |
| 11:18 |
|
Baytuch joined #minetest-dev |
| 11:39 |
|
Baytuch joined #minetest-dev |
| 11:45 |
|
appguru joined #minetest-dev |
| 11:50 |
|
Baytuch joined #minetest-dev |
| 11:59 |
|
cranezhou joined #minetest-dev |
| 12:00 |
erle |
what is the command i need to build lib/irrlichtmt/lib/Linux/libIrrlichtMt.a? |
| 12:01 |
erle |
i need it for static linking and i can't figure it out |
| 12:01 |
erle |
cmake produces a dynamic library when i do “cmake . && make” |
| 12:13 |
|
Baytuch joined #minetest-dev |
| 12:19 |
|
proller joined #minetest-dev |
| 12:24 |
erle |
for the record, the cmake option is -DBUILD_SHARED_LIBS=OFF and “make lib/Linux/libIrrlichtMt.a” fails for some reason |
| 13:10 |
Zughy[m] |
I blocked erle months ago and I can't read his messages, so I don't know if it's the same for him, but just in case: your contributions are 90% complaining and I'm so tired of having my mail spammed with you being.. you, scavenging old issues almost as if you had fun being in the way. Can we have a proper vote for banning this guy? I tried the nice approach months ago but apparently it's not working. He's just slowing down development |
| 13:10 |
Zughy[m] |
whilst wearing out the staff |
| 13:15 |
|
rubenwardy joined #minetest-dev |
| 13:18 |
MTDiscord |
<luatic> Zughy[m]: I don't see what you'd ban erle for? Slowing down development? I think it's important to have someone nagging about bad practices, undefined behavior etc. And erle has definitely provided meaningful contributions. |
| 13:20 |
Zughy[m] |
doing 1 good thing and 10 bad things doesn't make you a good contributor |
| 13:25 |
kilbith |
I agree with Zughy, this guy vampirizes the vital energy of a FOSS project |
| 13:28 |
Vagabond[m] |
I don't have any weight in this vote, but from my limited experience: erle seems passionate about compilation, and are pursuing an improvement. Though their approach is at times somewhat abrasive or aggressive, I believe they are acting in good faith for an improvement of the project. |
| 13:29 |
MTDiscord |
<luatic> ^ |
| 13:29 |
MTDiscord |
<luatic> (not only about compilation tho) |
| 13:30 |
Vagabond[m] |
I personally have disagreed with how some things were said or approached, but I can't say enough that I disagree with the contents of what was discussed. Also, I've been around here for about a week, so consider this a very naive and early opinion. |
| 13:30 |
Vagabond[m] |
*I can't say I know enough that I disagree... |
| 13:30 |
|
erle joined #minetest-dev |
| 13:31 |
kilbith |
well he seems to god-awfully annoy quite a lot of people |
| 13:32 |
kilbith |
look at how awful #minetest-dev looks like with him now |
| 13:33 |
kilbith |
I'm just scrolling over their spammy and boring messages rn |
| 13:52 |
MTDiscord |
<MarkTheSmeagol> As another person who has only been watching this channel for about a week, I don't find those messages spammy or boring, instead they seem to me to be useful descriptions of the process they used to get to the current proof of concept, along with questions about issues that came up. Ok, some of these questions were repeated, but given the time difference between the askings, I don't think they should be counted as spam. |
| 13:53 |
|
Baytuch joined #minetest-dev |
| 14:01 |
schwarzwald[m] |
It looks like some people think erle should stay because the points he's bringing up are valid, and some people think he should be banned because he's annoying. I think we should ask erle to be polite to the other developers, because really communication is the issue here. |
| 14:10 |
|
Baytuch joined #minetest-dev |
| 14:26 |
Zughy[m] |
schwarzwald: that's what happened months ago, apparently without any luck. I'm not saying he's not passionate, I'm saying he misses the capacity to moderate himself, often bringing the staff to the edge. I personally don't want to work in a toxic environment |
| 14:28 |
Zughy[m] |
and, to me, the time for warnings was months ago, in private, because I didn't want to cause any drama. The behaviour has continued, hence me bringing the topic in the public chat. I'm personally very tired of erle, no matter his good intentions |
| 14:30 |
schwarzwald[m] |
Well, that's hard to argue against. |
| 14:37 |
sfan5 |
the signal to noise ratio is certainly off, ignoring the issues I don't consider worth spending time on works for the most part as long as the endless discussions don't also spill into #minetest-dev |
| 14:55 |
MTDiscord |
<luatic> Suggestion: Make a #minetest-erle channel |
| 14:56 |
erle |
luatic a discussion needs two people. but just dumping information i should do in issues and PRs anyway. |
| 14:57 |
erle |
sfan5, just out of curiousity does this extend to #minetest as well? i noticed that you closed #11749 at about the time when muurkha and me were discussing build system stuff in #minetest, but i am not sure if this is just coincidence or was a reaction. |
| 14:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/11749 -- CMake does not capture all dependencies, causing erroneous incremental builds & build failures |
| 14:58 |
sfan5 |
can you reformulate your question? |
| 14:59 |
erle |
did you close that issue because you saw the discussion in #minetest about build system failure modes and were thinking something like “i want this entire train of thought to just go away”? |
| 15:00 |
rubenwardy |
I'm sick of this discussion |
| 15:00 |
erle |
which is why i post updates to the PR and issues |
| 15:01 |
sfan5 |
erle: no |
| 15:02 |
erle |
oh okay. then discussing stuff you don't like in #minetest is okay? again, a discussion needs more than one person, otherwise i could just make a blog post as celeron55 suggested (and i now think that i probably should) |
| 15:03 |
erle |
i totally agree that cutting down on progress reports and “look here is an example why you are wrong” is better in issues/PRs |
| 15:04 |
erle |
especially for topics where people are fed up to the point of wanting to shut down discussions that other people have on the topic |
| 15:04 |
|
Yad joined #minetest-dev |
| 15:04 |
rubenwardy |
My problem with this is that Minetest is a game engine and a game platform, not a build system. Implementing our own build system is totally out of scope, no matter the limitations of existing build systems |
| 15:05 |
rubenwardy |
If we're using CMake wrong, then that should be fixed. If CMake has a limitation, then it evidently isn't a huge issue given its prevalence |
| 15:05 |
erle |
rubenwardy i understand that. point is, many build systems already exist. what i am doing (badly) right now is more like the cmake feature detection scripts. |
| 15:06 |
erle |
well, i have repeatedly claimed that yes, the cmake part should be fixed. but no one ever does. |
| 15:07 |
sfan5 |
who says someone else has to do it? |
| 15:09 |
erle |
usually, what i hear from the devs is “if you want a fix for this, please do it yourself”. and experts on topics are given a lot of leeway in how they do it, if they can manage it work according to the constraints. what i don't get: why would build system issues be any different? the build system is not part of minetest, but its configuration is. and it is demonstrably wrong. |
| 15:10 |
erle |
without going into this issue, is the only thing that separates it from, e.g. the stuff hecks did that it is considered unimportant by people whose compile times are an order of magnitude less than mine and who “never” run into miscompiles? |
| 15:11 |
|
Baytuch joined #minetest-dev |
| 15:11 |
erle |
because if “someone who never encounters a bug and will not be affected by fixing it finds it unimportant to fix it” is more important than putting in the actual work, then i should indeed shut up. there is no point in developing anything, just as there is no point in reviewing PRs when my approval or disapproval does not count. |
| 15:13 |
lebruhgamer[m] |
am just anon lurker but thank you erle for reality-check the core devs, some of them are kinda out of touch and would just dismiss stuff that they don't want to deal with even if it's actually important to end users |
| 15:13 |
erle |
anyways, i don't want to be annoying on purpose, so if others could abstract this from this issue the way sfan5 did (“i don't want to read what i find unimportant bc it's annoying”) i promise to take it into account. |
| 15:14 |
schwarzwald[m] |
I'm not currently planning to PR it, but I am completely redesigning the CMake build from the ground up. |
| 15:14 |
erle |
schwarzwald[m] that's good. can you solve the issues i brought up that way? also, why not a PR? |
| 15:14 |
sfan5 |
not sure I get what you are comparing this to, but if you can't find anyone who thinks your issue is important then what are you gonna do? |
| 15:14 |
schwarzwald[m] |
I have all the sources listed and I'm refactoring + adding libraries. |
| 15:15 |
schwarzwald[m] |
I'm going all out erle, and I'm not supporting anything earlier than CMake 3.16 for example. |
| 15:15 |
schwarzwald[m] |
Devs want to support 3.5. |
| 15:15 |
schwarzwald[m] |
I could potentially PR some specific parts of it, though. |
| 15:15 |
rubenwardy |
What's the oldest distro we support again? Debian buster? |
| 15:15 |
erle |
sfan5 the thing is, a bunch of non-coredevs think the dependency thing is important, as they keep running into it. do their experiences not count, similar to “your GPU is too old so we don't care”? |
| 15:16 |
rubenwardy |
I think more people would find using a standard build system like cmake more important |
| 15:17 |
schwarzwald[m] |
I just ran into a missing header somehow. I don't know why this came up now. |
| 15:17 |
|
Yad joined #minetest-dev |
| 15:17 |
schwarzwald[m] |
(this issue has to exist in current master as well) |
| 15:18 |
rubenwardy |
if this is such an issue, what do other projects do to resolve it? |
| 15:18 |
erle |
they typically use a build system that does not do the toposort approach. or they lock down all dependencies very strictly, which is infeasible for minetest. and very brittle, as HuguesRoss explained. |
| 15:18 |
schwarzwald[m] |
The header isn't missing. It looks like someone just forgot and `std::` |
| 15:19 |
rubenwardy |
cmake is the most popular build system for C++ |
| 15:19 |
sfan5 |
rubenwardy: my go to is the second-last ubuntu lts, second-last debian release and centos (though that no longer exists now) |
| 15:19 |
schwarzwald[m] |
s/and/an/ |
| 15:19 |
sfan5 |
erle: does the Linux kernel not have this issue? they use make |
| 15:19 |
erle |
rubenwardy you can keep using cmake. and redo has been around since 2010 and has half a dozen implementations (because it can be implemented in a few hundred lines) and was designed by djb, so it's not exactly obscure. |
| 15:20 |
sfan5 |
also re "do their experiences not count", I did explicitly say devs. If devs do not think specific user opinions are worth taking into account then they aren't |
| 15:20 |
erle |
the scripts i have written so far are smaller than the CI stuff sfan5 wrote and given that they actually build correctly and rebuild correctly and i am not deleting anything cmake-related, i don't see the point of trying to avoid the maintenance overhead of a few hundred lines of shell at most. |
| 15:21 |
sfan5 |
oh jeez this isn't going anywhere |
| 15:21 |
rubenwardy |
so ubuntu 20.04 and debian buster... which means min Cmake 3.13 schwarzwald[m] |
| 15:21 |
schwarzwald[m] |
Irrlicht is missing the include; it's just a couple lines to fix. Should I PR it, or does sfan5 want to apply a patch, or what would the devs prefer? |
| 15:21 |
rubenwardy |
PR is fine |
| 15:22 |
sfan5 |
make sure to paste the error you got too |
| 15:22 |
schwarzwald[m] |
rubenwardy: I could work with that probably TBF. The reason I was thinking 3.16 is that it's the minimum version that supports precompiled headers. |
| 15:22 |
rubenwardy |
Ubuntu 20.04 has 3.16, it's just Debian that's the problem. As usual |
| 15:22 |
schwarzwald[m] |
sfan5: Is that helpful? It's a custom build script so nobody else can reproduce it without modifying the build files. |
| 15:23 |
erle |
sfan5 the linux kernel can indeed have several of these problems, but not to the extent of a C++ application because a) kernel devs have beefy machines so they can rebuild fast and often b) embedded and kernel devs are so damn careful usually specifying dependencies that they just don't have this problem. in fact, i have *never* witnessed embedded devs not nailing down their dependencies. |
| 15:23 |
schwarzwald[m] |
It's pretty easy to install newer CMake versions from Kitware. Granted, some may consider that a bit messy. |
| 15:24 |
sfan5 |
"just download and extract this tar.gz" works for end users but doesn't cut it for distro maintainers |
| 15:24 |
erle |
btw, minetest is a special case, i have never seen a project of this size being so underspecified |
| 15:25 |
sfan5 |
schwarzwald[m]: eh, a theoretical issue that doesn't even happen with our build system? |
| 15:25 |
|
Baytuch joined #minetest-dev |
| 15:26 |
sfan5 |
make a PR anyway though, it's probably okay to include the fix |
| 15:26 |
erle |
why would precompiled headers need cmake support? they are headers like any other |
| 15:26 |
schwarzwald[m] |
Ah, you got me there sfan. My inexperience showing! |
| 15:26 |
schwarzwald[m] |
If I do decide to PR I will set the minimum to 3.13 then. I'm looking at way less compile steps already, so I may not even want precompiled headers. |
| 15:27 |
schwarzwald[m] |
CMake will automatically precompile the headers that you ask it to. It's part of keeping things automated and not manual. |
| 15:28 |
erle |
schwarzwald[m] that sounds useful. speedup? |
| 15:29 |
schwarzwald[m] |
I'm a long ways from that. Right now I'm refactoring the various lists of source files into object targets. I only have about 200 compile steps right now in comparison to 300 previously, but I haven't loaded in all the dependencies so that number could grow. |
| 15:29 |
erle |
schwarzwald[m] regarding refactoring the cmake thing, do you have any plans for the dependencies that cmake does not currently track, but totally could? these are the most important |
| 15:30 |
schwarzwald[m] |
I'm not experienced in this field, and I don't know what those dependencies are. With nobody teaching me how to do it my only option is to do the best I can. |
| 15:32 |
schwarzwald[m] |
I do not know specifically how I achieved this, but by separating dependencies I somehow broke a heap-ton of C function calls in Irrlicht. |
| 15:32 |
erle |
fastest way i know how is to build with redo and then use redo-dot with a shell pattern for some target filename to get graphviz output, then figure out for each solid line if cmake considers it (it is impossible for cmake consider the dashed lines because of the way it works). |
| 15:33 |
schwarzwald[m] |
memset not defined, strlen not defined, what's next? |
| 15:33 |
schwarzwald[m] |
If I were going to do that I might as well use redo... |
| 15:33 |
erle |
i can send you the graphviz output if it helps. but i can't send you the complete graph because it takes forever to even collect the data. and you won't be happy with megabytes of graphviz anyway. |
| 15:34 |
schwarzwald[m] |
Hmm, that could help. |
| 15:34 |
schwarzwald[m] |
I don't think I'm ready for it though. I want to refactor the build so it's easier to actually work with. |
| 15:34 |
schwarzwald[m] |
I need to deal with this land mine I just hit somehow. |
| 15:34 |
erle |
schwarzwald[m] the irony is that the laziest way of fixing cmake involves using a build system that builds top-down and traces the results (e.g. redo, shake, etc.) and then using that to refactor the cmake rules. |
| 15:35 |
schwarzwald[m] |
I am quite sure this is caused by Minetest overspecifying dependencies BTW. |
| 15:35 |
erle |
it both overspecifies and underspecifies them |
| 15:35 |
sfan5 |
can we move all build system discussions out of here for the next 7 days |
| 15:35 |
schwarzwald[m] |
Yes. |
| 15:35 |
erle |
ironically, i was thinking something similar lol |
| 15:35 |
erle |
lets go to #minetest then |
| 15:37 |
|
Taoki joined #minetest-dev |
| 16:14 |
schwarzwald[m] |
Guys, why did you extend the std namespace? You managed to break <cstring> somehow. |
| 16:15 |
schwarzwald[m] |
How am I supposed to go about fixing this? How is anyone here supposed to go about fixing this? |
| 16:16 |
* schwarzwald[m] |
posted a file: (314KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/CregZTrsVahOuJwuEUWxofvq/log.txt > |
| 16:17 |
schwarzwald[m] |
Full compile log. Search for `error` and the evidence of <cstring> going berserk will fill your eyes. |
| 16:40 |
sfan5 |
unless this error is reproducible with an unmodified git HEAD I also count this under "build system discussions" that should not be here |
| 16:43 |
sfan5 |
nevermind the fact that extending std is supported and expected, see std::hash |
| 16:50 |
HuguesRoss |
I have no knowledge of this particular code, but one small thing I'd like to add--while it's not necessary, I find that it's often more constructive to ask 'who' and 'when' before asking 'why'. Knowing who--if anyone--on a team can actually answer your question will probably get you further than throwing your query to the four winds, and knowing |
| 16:50 |
HuguesRoss |
whether a change is recent, old, or ancient can sometimes answer the question on its own |
| 16:50 |
Goobax[m]1 |
@AFCM |
| 16:51 |
erle |
HuguesRoss, e.g. just use git blame? |
| 16:51 |
HuguesRoss |
haha, often that will do the trick yes |
| 16:52 |
Goobax[m]1 |
you're talking to whom |
| 17:16 |
schwarzwald[m] |
Thanks, sorry for mentioning it here. |
| 17:36 |
|
Baytuch_2 joined #minetest-dev |
| 17:45 |
|
CoolJar10 joined #minetest-dev |
| 17:57 |
sfan5 |
as a reminder to everyone, here are the current release blockers: #12557 #12573 #12581 #12048 |
| 17:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/12557 -- Mods can no longer override textures/media based on load order (devtest error) |
| 17:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/12573 -- Android main menu doesn't render |
| 17:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/12581 -- Inventory slots in Repixture look different in 5.6.0-dev |
| 17:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/12048 -- Autoforward no longer allows sideways movement |
| 18:26 |
|
Baytuch joined #minetest-dev |
| 18:29 |
|
x2048 joined #minetest-dev |
| 18:43 |
|
Baytuch joined #minetest-dev |
| 18:52 |
sfan5 |
rubenwardy: btw ripgrep directly supports reading zip files |
| 19:09 |
MTDiscord |
<x2048> Is anyone actively working on the blockers? |
| 19:16 |
|
Baytuch joined #minetest-dev |
| 19:17 |
|
olliy joined #minetest-dev |
| 20:10 |
|
Baytuch joined #minetest-dev |
| 20:12 |
|
Baytuch joined #minetest-dev |
| 20:20 |
|
Baytuch joined #minetest-dev |
| 20:27 |
|
proller joined #minetest-dev |
| 21:24 |
|
Baytuch_2 joined #minetest-dev |
| 21:48 |
|
vampirefrog joined #minetest-dev |
| 21:52 |
|
vampirefrog joined #minetest-dev |
| 21:52 |
|
kaeza joined #minetest-dev |
| 22:24 |
|
Yad joined #minetest-dev |
| 22:27 |
|
Yad joined #minetest-dev |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 22:34 |
|
erle joined #minetest-dev |
