| 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 |
<Jordach> the usual shit git clone irrlichtmt into lib/irrlichtmt |
| 00:17 |
MTDiscord |
<Jordach> 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. |
| 01:29 |
|
olliy joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:36 |
|
calcul0n joined #minetest-dev |
| 08:32 |
|
MTDiscord joined #minetest-dev |
| 08:37 |
sfan5 |
it's weird how I never have issues despite often doing incremental builds after switching between revisions |
| 10:28 |
|
HuguesRoss joined #minetest-dev |
| 10:30 |
|
HuguesRoss3 joined #minetest-dev |
| 10:47 |
|
Fixer joined #minetest-dev |
| 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:21 |
|
fluxionary joined #minetest-dev |
| 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:54 |
|
Alias joined #minetest-dev |
| 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. |
| 13:24 |
|
Taoki joined #minetest-dev |
| 13:54 |
|
proller joined #minetest-dev |
| 14:13 |
|
proller joined #minetest-dev |
| 14:17 |
|
erle joined #minetest-dev |
| 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 |
|
proller joined #minetest-dev |
| 14:33 |
erle |
nevertheless, connection time with a full cache seems to be CPU-bound for some reason |
| 15:26 |
|
sometalgoo joined #minetest-dev |
| 20:33 |
|
proller joined #minetest-dev |
| 21:26 |
|
proller joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 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, |
| 23:11 |
|
AliasAlreadyTake joined #minetest-dev |
