Time Nick Message 00:14 erle Jordach sorry i can't test this. please provide build instructions, i can test it some other time. 00:14 erle and yes i have newest irrlichtmt now 00:16 MTDiscord the usual shit git clone irrlichtmt into lib/irrlichtmt 00:17 MTDiscord have you like not read the build instructions in minetest/minetest 00:19 erle ig i must have accidentally built something incrementally. 00:20 erle last i checked it was entirely possible to follow the build instructions and not get a binary. i'll figure it out. good night. 08:37 sfan5 it's weird how I never have issues despite often doing incremental builds after switching between revisions 10:54 erle i do not find it weird at all. partial rebuilds most likely go wrong when some dependency that is relevant in both revisions is incorrectly (or not at all) tracked and has meaningfully changed status so it affects the build AND a “full” rebuild for some reason still considers that file (i suspect wildcards). but as i said before, not all partial rebuilds abort, some just give you corrupted binaries. 10:54 erle considers that file important 10:56 erle so most of the time, the “files are not tracked” errors are just masked by “make is going to rebuild it anyway” 10:59 erle i have had it happen several ways. the one from last night was: 1. compile something with outdated irrlichtmt 2. do a “full rebuild” using correct irrlichtmt 11:02 erle in general: i am pretty sure that going to 5.4.1 & building, then going to 5.5 & rebuilding, then going to 5.4.1 & rebuilding is not possible on any of my machines. and i suspect you do not make such big jumps. 11:05 erle in fact, i vaguely remember that you yourself once explained why the cmake & make combo can not handle some “going backwards in time” incremental rebuilds, but i don't know the reason anymore. 11:07 erle i am still massively irritated that so few people are convinced by my skript that sets each files time to the last commit in which it was modified. it reliably exposes build errors by removing the “let's rebuild everything” part. and such a situation can happen in normal development. 11:12 sfan5 I don't switch between 5.4 and 5.5, no 11:13 sfan5 I did switch across the commit that introduced the mt_opengl.h dependency though, multiple times, and nothing went wrong 11:16 erle because *that* was my mistake for having outdated irrlichtmt. or someone elses mistake for not using git submodules. the impossible state afterwards is what bugs me. 11:22 erle sfan5 have you ever used git bisect on minetest? if so, i would be *very* interested in what your setup for that is (unless it is “make a new cmake build directory and build everything new all of the time”). 11:24 sfan5 not recently but my setup would be to type 'make' and downgrade irrlichtmt if a related error pops up 11:26 erle just to verify it, i just tried the “build 5.4, then build 5.5” thing and it does, indeed, not work. 11:26 erle complaining about TEST_MOD_PATH not being declared 11:26 erle well, i built 5.4.1, then 5.5.0, but same 11:28 erle interestingly, the compiler also complains about multiple definitions of stuff like VERSION_STRING. this seems to be the fault of cmake. easy to reproduce in any way. 11:38 sfan5 erle: I cannot reproduce this 11:39 sfan5 took a fresh ubuntu container and here's the unedited list of commands ran https://0x0.st/oc7a.txt 11:40 erle what does “clear” do? 11:40 erle just reset the terminal? 11:40 sfan5 I will not answer this question 11:41 erle well, some people have strange aliases. 11:41 erle assuming “clear” does not delete any files, i am quite confused by this. 11:41 sfan5 did you miss the part where I said I took a "fresh ubuntu container"? 11:42 erle likely 11:43 erle so yeah, i believe that you don't run into the same issues. i have no idea though why that is the case. might be a debian vs ubuntu thing (cmake version?) might be that the amount of cores or cflags play a role. i have no idea. 11:44 sfan5 my dev machine runs arch linux so ubuntu 20.04 is already quite different from it 11:47 erle well here is how it fails for me (i only replaced the path to my homedir with $HOME here): https://mister-muffin.de/p/XL19.txt 11:47 erle also i may not have 12 cores 11:48 erle but without -j12 it just takes a bit longer until it fails 11:48 rubenwardy Are you consistently building in the same directory? 11:48 rubenwardy I had an issue where cmake_config.h was generated in two places, so an outdated version was used 11:48 rubenwardy Which came with a similar error 11:49 rubenwardy This was because I built in the root dir, then in a build dir 11:49 erle oh! 11:49 erle that would totally explain a lot 11:49 erle i think a lot of people *used* to build in the root directory 11:50 erle then took the advice to build in a subdirectory 11:50 erle rubenwardy, which file or files would i need to get rid of in the root dir? 11:50 rubenwardy SRC/cmake config.h 11:50 rubenwardy Not the template version which is tracked 11:50 rubenwardy I forget the exact file extensions 11:51 erle i'll try 11:51 erle i mean it's still a stupid dependency tracking problem, but at least this offers a solution to getting stuck 11:52 rubenwardy This has nothing to do with dependencies, just where the file is placed 11:53 erle well, every included header file can mess up your build. 11:55 erle rubenwardy thanks for that. it gets rid of the multiple redefinitions warning. however, the build still fails complaining about TEST_MOD_PATH. 14:32 erle when i noticed that minetest was doing way too many SHA1 comparisons when connecting, i wondered what the impact would be. turns out, while it's a lot of *calls* (and a bit of heat ig), computers are fast: connecting to a server taking 23s / 40s / 70s with a full cache stays the same time with or without the useless sha1 comparisons, assuming i have built my binary correctly. 14:33 erle nevertheless, connection time with a full cache seems to be CPU-bound for some reason 22:53 erle rubenwardy, i call every existing file that influences build behaviour a dependency, even if it is not tracked. i guess you probaby do not,