Time Nick Message 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: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:18 MTDiscord 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 ^ 13:29 MTDiscord (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: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 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. 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: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 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 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 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 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: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 16:14 schwarzwald[m] Guys, why did you extend the std namespace? You managed to break 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 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: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:52 sfan5 rubenwardy: btw ripgrep directly supports reading zip files 19:09 MTDiscord Is anyone actively working on the blockers?