| Time |
Nick |
Message |
| 00:23 |
MTDiscord |
<MisterE> About the white/black textures: is that the bug with linux version where only one texture of a model is loaded and the other textures are white or black? |
| 00:25 |
erlehmann |
MisterE yes i think that is it. it's only happening on linux? |
| 00:25 |
erlehmann |
it is abysmal though |
| 00:25 |
erlehmann |
breaks a lot of models |
| 00:29 |
MTDiscord |
<MisterE> From my exp, on windows the models display well, but are broken on linux |
| 00:29 |
MTDiscord |
<MisterE> All of liil's mobs are broken on linux :( |
| 00:31 |
erlehmann |
yeah |
| 00:33 |
MTDiscord |
<MisterE> It would be great if we could have a fix for that soon. I'm starting a server with all of liil's mobs so it won't work for linux until a fix |
| 00:38 |
erlehmann |
MisterE it works fine in 5.4.1 |
| 00:39 |
erlehmann |
as far as i know |
| 00:39 |
erlehmann |
maybe not though |
| 00:39 |
erlehmann |
hmm |
| 00:39 |
erlehmann |
MisterE maybe you can put the github issue in the MOTD or something? |
| 00:53 |
|
AliasAlreadyTake joined #minetest-dev |
| 01:19 |
|
specing_ joined #minetest-dev |
| 01:48 |
kilbith |
hmm... why no documentation was left for modders after some debug.* functions were removed? |
| 02:24 |
kilbith |
I'd recommend that mod security is disabled by default for mods coming from Content store |
| 02:25 |
kilbith |
since they are audited |
| 02:26 |
MTDiscord |
<Jonathon> they arent |
| 02:38 |
MTDiscord |
<Hugues Ross> Yeah, they're not. They get a basic check for license violations, basic functionality, etc. but not a full code review or security audit |
| 02:39 |
MTDiscord |
<Hugues Ross> Nothing would get done it they did |
| 02:40 |
MTDiscord |
<Jonathon> it already takes a while for people to review them tbh |
| 02:40 |
MTDiscord |
<Hugues Ross> The only thing you can really be guaranteed was checked for a given mod is https://content.minetest.net/policy_and_guidance/ -- beyond that it depends on the reviewer, circumstances, time, etc |
| 02:40 |
MTDiscord |
<Jonathon> even then some things slip through the cracks |
| 02:42 |
MTDiscord |
<Hugues Ross> The malware rule, sadly, is not realistic to fully check. For my part I do a quick glance to see that the code appears to be doing what it claims, but there's not really much that can be done |
| 03:28 |
|
queria joined #minetest-dev |
| 03:33 |
|
queria joined #minetest-dev |
| 04:31 |
|
v-rob joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:05 |
|
bigfoot547 joined #minetest-dev |
| 06:11 |
|
programmerjake joined #minetest-dev |
| 06:12 |
|
tekakutli joined #minetest-dev |
| 06:14 |
|
loggingbot_ joined #minetest-dev |
| 06:14 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. https://dev.minetest.net/ |
| 06:15 |
|
freshreplicant[m joined #minetest-dev |
| 07:07 |
|
v-rob joined #minetest-dev |
| 09:03 |
|
Wuzzy joined #minetest-dev |
| 10:08 |
|
tekakutli joined #minetest-dev |
| 11:28 |
|
pi3 joined #minetest-dev |
| 11:45 |
|
calcul0n__ joined #minetest-dev |
| 11:57 |
|
Taoki joined #minetest-dev |
| 13:20 |
|
specing_ joined #minetest-dev |
| 13:51 |
|
pi3 joined #minetest-dev |
| 13:58 |
|
kilbith joined #minetest-dev |
| 14:27 |
|
calcul0n_ joined #minetest-dev |
| 14:37 |
|
Fleckenstein joined #minetest-dev |
| 15:04 |
MTDiscord |
<Jonathon> has there been any thought to when a 5.5 feature freeze might start? |
| 15:05 |
MTDiscord |
<srinivas> the feature freeze did not start yet? |
| 15:05 |
MTDiscord |
<srinivas> forgive my ignorance, I have been out of the scene so to speak |
| 15:07 |
rubenwardy |
roughly a week before the release |
| 15:22 |
|
v-rob joined #minetest-dev |
| 15:27 |
|
Fixer joined #minetest-dev |
| 15:39 |
|
tekakutli joined #minetest-dev |
| 15:41 |
MTDiscord |
<srinivas> and when is that supposed to be? |
| 15:42 |
|
tekakutli joined #minetest-dev |
| 15:44 |
|
tekakutli joined #minetest-dev |
| 15:45 |
sfan5 |
nobody knows |
| 15:46 |
sfan5 |
there's a number of outstanding problems |
| 15:51 |
MTDiscord |
<Jonathon> the 5.5 list said october, that didnt happen |
| 15:52 |
|
v-rob joined #minetest-dev |
| 15:53 |
|
Extex joined #minetest-dev |
| 15:56 |
erlehmann |
devtest is used to test engine features right? |
| 15:57 |
rubenwardy |
plot twist: October 2022 |
| 15:57 |
rubenwardy |
erlehmann: yes. Devtest is a game with tools to test the engine |
| 15:57 |
erlehmann |
the halloween update |
| 15:58 |
erlehmann |
rubenwardy i.e. lua code that exercizes currently-working engine code paths is welcome? |
| 15:58 |
erlehmann |
if that is not covered |
| 15:58 |
rubenwardy |
see the unittest mod |
| 15:58 |
rubenwardy |
which should be called integtest really |
| 15:58 |
rubenwardy |
it has some automated stuff |
| 15:59 |
erlehmann |
i was thinking bc a bunch of breaking changes are prob just bc the devs don't really play any games beside their own much |
| 15:59 |
erlehmann |
but if it was in devtest |
| 15:59 |
erlehmann |
some stuff would be obv |
| 16:00 |
erlehmann |
maybe i can motivate fleckenstein to make a mesh for me for a cube that has the texture bug |
| 16:00 |
erlehmann |
obv he knows how to do it |
| 16:00 |
erlehmann |
rubenwardy would a “texture test mesh” entity in devtest make sense? |
| 16:01 |
erlehmann |
i.e. spawn this entity to look if all of its textures are loaded |
| 16:02 |
erlehmann |
i mean it has text particles |
| 16:02 |
erlehmann |
test particles i mean |
| 16:03 |
rubenwardy |
yes, there are test items for various things |
| 16:04 |
erlehmann |
tbh the hardest thing about the models is the provenance |
| 16:04 |
erlehmann |
like ppl commit binary models |
| 16:04 |
erlehmann |
and forget how they exported them :/ |
| 16:11 |
MTDiscord |
<Jonathon> you can load obj into blender, b3d nope |
| 16:12 |
MTDiscord |
<Jonathon> granted thats more of a issue with how terrible of a format b3d is |
| 16:14 |
erlehmann |
well it's there now |
| 16:14 |
erlehmann |
sadly |
| 16:15 |
erlehmann |
did anyone compare the two boats? |
| 16:15 |
erlehmann |
i'd love to autodetect if the texture bug happens |
| 16:15 |
erlehmann |
but i have no idea about where to start even |
| 16:26 |
sfan5 |
can you link me the model file that's broken |
| 16:37 |
erlehmann |
sfan5 yes, pls wait |
| 16:38 |
erlehmann |
sfan5 https://git.minetest.land/MineClone2/MineClone2/raw/branch/master/mods/ENTITIES/mcl_boats/models/mcl_boats_boat.b3d |
| 16:39 |
erlehmann |
oof not a permalink |
| 16:39 |
erlehmann |
sfan5 for context, here is the commit that changed it https://git.minetest.land/MineClone2/MineClone2/commit/97424f7d0a5ed634177ac7e972a2453f3e32c4b1 |
| 16:40 |
erlehmann |
i think the committer wanted to prevent me from making my player character 3 times the size via visual_size attachment glitching |
| 16:41 |
sfan5 |
https://0x0.st/-5Jr.png is this the bug or just because I didn't set more than one texture |
| 16:41 |
erlehmann |
https://git.minetest.land/MineClone2/MineClone2/issues/1414#issuecomment-18487 |
| 16:41 |
erlehmann |
sfan5, enjoy https://git.minetest.land/attachments/cadb1379-d308-4787-9031-b21202a97e38 |
| 16:41 |
nrz |
amazing ? |
| 16:42 |
erlehmann |
sfan5, that looks indeed like the bug, let me check |
| 16:43 |
erlehmann |
sfan5 look here for the original boat definition https://git.minetest.land/MineClone2/MineClone2/src/branch/master/mods/ENTITIES/mcl_boats/init.lua#L111 |
| 16:44 |
erlehmann |
mesh = "mcl_boats_boat.b3d", |
| 16:44 |
erlehmann |
textures = {"mcl_boats_texture_oak_boat.png"}, |
| 16:44 |
erlehmann |
sfan5, so i think that is the bug indeed |
| 16:44 |
erlehmann |
sfan5, does it turn white without shaders? |
| 16:45 |
erlehmann |
bc if yes, that's it |
| 16:45 |
erlehmann |
also the issue should be retitled |
| 16:46 |
erlehmann |
bc that bug has been there for a while |
| 16:47 |
erlehmann |
and has nothing to do with shaders if it happened without them too |
| 16:48 |
sfan5 |
it's white without shaders yes |
| 16:48 |
sfan5 |
I didn't expect this because under ogles2 "disabling" shaders just means using the ones built into irrlicht (shaders are required) |
| 16:49 |
erlehmann |
might hint at some wrong blend mode maybe somewhere |
| 16:49 |
erlehmann |
who knows |
| 16:50 |
erlehmann |
sfan5, do you have *any* idea how to get to the bottom of it? |
| 16:50 |
sfan5 |
yes, an opengl debugger |
| 16:50 |
erlehmann |
wow neat show |
| 16:51 |
erlehmann |
i was more thinking of building minetest 5.4.1 and bisecting irrlicht |
| 16:51 |
erlehmann |
but ogl debugger is much smarter |
| 16:55 |
sfan5 |
https://0x0.st/-5J-.png this looks like it |
| 16:55 |
sfan5 |
now to figure out why no texture is being bound and whose fault it is |
| 16:55 |
|
tekakutli joined #minetest-dev |
| 17:23 |
sfan5 |
well I can only declare that one user error |
| 17:23 |
sfan5 |
the model has five mesh buffers each of which gets a texture, but only one is specified from Lua |
| 17:26 |
erlehmann |
sfan5 so what is the difference to this? https://git.minetest.land/Mineclonia/Mineclonia/raw/branch/master/mods/ENTITIES/mcl_boats/models/mcl_boats_boat.b3d |
| 17:27 |
erlehmann |
welp, i bet some well-intentioned bugfix made it so that a lot of invalid b3d exports like that exist |
| 17:27 |
erlehmann |
see wilhelmines people |
| 17:28 |
erlehmann |
sfan5, what debugger do you use btw? |
| 17:28 |
erlehmann |
sfan5, the second boat should have no rendering error in minetest |
| 17:35 |
|
fluxionary joined #minetest-dev |
| 17:57 |
sfan5 |
renderdoc |
| 17:57 |
sfan5 |
but apart from finding out that no texture is bound the rest was just digging in c++ |
| 18:00 |
sfan5 |
erlehmann: the mineclonia model only has 1 mesh buffer |
| 18:05 |
sfan5 |
now it might be that this accidentally worked in 5.4 |
| 18:05 |
sfan5 |
but it is not supposed to |
| 18:07 |
erlehmann |
doesn't matter if its “supposed to” i guess |
| 18:08 |
erlehmann |
i am not even sure when it worked (in 5.4.x or earlier) |
| 18:08 |
erlehmann |
have to figure it out |
| 18:08 |
erlehmann |
brb |
| 18:09 |
erlehmann |
sfan5 wilhelmines pople wa released march 2021 afaik, so it must be recent breakage ig |
| 18:10 |
|
Extex joined #minetest-dev |
| 18:12 |
erlehmann |
sfan5, the problem is missing source → impossible to fix it easily in mods |
| 18:12 |
sfan5 |
you don't need to touch the model just specify the same texture 7 times instead of once |
| 18:16 |
erlehmann |
sfan5, so how is the boat fixed? |
| 18:17 |
sfan5 |
what do you mean |
| 18:17 |
erlehmann |
do you give it like 5 textures? |
| 18:18 |
sfan5 |
you would yes |
| 18:18 |
sfan5 |
of course since you have the source you can just reexport it correctly |
| 18:18 |
erlehmann |
well, if *that* is the fix, i'd suggest that minetest automatically sets uninitialized textures to the last one used or whatever makes it work. |
| 18:18 |
erlehmann |
i actually do not have the source or the export process |
| 18:19 |
erlehmann |
i mean ig it used to do that somehow? |
| 18:19 |
sfan5 |
must've been irrlicht internally |
| 18:21 |
erlehmann |
probably? |
| 18:21 |
erlehmann |
“we'll fix it in postprocessing” lol |
| 18:32 |
|
v-rob joined #minetest-dev |
| 18:45 |
|
Fleckenstein joined #minetest-dev |
| 18:59 |
|
tekakutli joined #minetest-dev |
| 19:07 |
sfan5 |
#11766 |
| 19:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/11766 -- Add backwards-compatible behaviour if too few CAO textures specified by sfan5 |
| 19:15 |
erlehmann |
sfan5, very nice. so you conclude that it used to work with shaders, then it did not – and all those ppl used a buggy exporter ig? |
| 19:19 |
MTDiscord |
<josiah_wi> What's the policy for warning messages in the release configuration with the default flags? If they don't technically indicate an error, do we ignore them? |
| 19:22 |
erlehmann |
josiah_wi “If they don't technically indicate an error” wdym |
| 19:23 |
MTDiscord |
<josiah_wi> Such as the "overrides a member function but is not marked 'override'" warning. |
| 19:38 |
|
v-rob joined #minetest-dev |
| 20:03 |
|
v-rob joined #minetest-dev |
| 20:18 |
erlehmann |
sfan5, FYI: i just got the TEST_MOD_PATH thing an incremental build without any trickery regarding file timestamps |
| 20:18 |
erlehmann |
and then got it on a full rebuild |
| 20:18 |
erlehmann |
then got it again |
| 20:18 |
erlehmann |
i.e. i can't build that commit and i have not yet found out how to actually do it |
| 20:19 |
erlehmann |
currently building 188b00114 from x2048/alpha_blend_indexed |
| 20:22 |
erlehmann |
sfan5 my theory is that ppl who never run into these dependency bugs i made an issue for a) never use git bisect b) rarely switch between git branches (compared to how often i do) c) do not actually rely on incremental builds, but rebuild almost everything always |
| 20:23 |
erlehmann |
but again, i want to point out that *right now* it is possible to get to a state where the code does not compile at all and it is difficult to figure out why |
| 20:24 |
erlehmann |
just by switching between commits and doing incremental builds |
| 20:24 |
erlehmann |
(without any funny pots-checkout hook business) |
| 20:24 |
erlehmann |
yeah |
| 20:24 |
erlehmann |
i can't get out of it :( |
| 20:26 |
MTDiscord |
<luatic> I switch branches often too |
| 20:26 |
MTDiscord |
<luatic> It used to hurt on my older computer, as a full recompilation took half an hour |
| 20:27 |
MTDiscord |
<luatic> I can live with the 2-3 minutes it takes now |
| 20:27 |
MTDiscord |
<luatic> "i want to point out that right now it is possible to get to a state where the code does not compile at all and it is difficult to figure out why" - been in that state, can confirm - IrrlichtMT has effectively messed up bisect |
| 20:28 |
|
x2048 joined #minetest-dev |
| 20:31 |
erlehmann |
luatic it is not only irrlichtmt |
| 20:31 |
erlehmann |
or maybe it is |
| 20:31 |
erlehmann |
i can't say |
| 20:31 |
erlehmann |
but inside minetest proper there are dependencies that are not specified and when you rebuild, the only thing making it work is if you recently touched that file |
| 20:32 |
erlehmann |
but it does not actually make it work in all cases |
| 20:32 |
erlehmann |
and it seems it is possible for a partial build to mess up future builds in *some* way |
| 20:32 |
erlehmann |
yeah |
| 20:32 |
erlehmann |
<luatic> It used to hurt on my older computer, as a full recompilation took half an hour |
| 20:32 |
erlehmann |
<luatic> I can live with the 2-3 minutes it takes now |
| 20:33 |
erlehmann |
you must have some kind of supercomputer if that is the case?! |
| 20:33 |
erlehmann |
even on the work computer i have it does not become that fast |
| 20:33 |
erlehmann |
luatic what are your tricks |
| 20:33 |
erlehmann |
precompiled header files or sth? |
| 20:50 |
MTDiscord |
<luatic> I have no tricks, I only have a Ryzen 5 3500U |
| 20:56 |
MTDiscord |
<josiah_wi> erlehmann do you have an example of one of those unspecified deps? Could you make a list? |
| 20:57 |
erlehmann |
josiah_wi i have no example, i can only infer it from having years of experience with build systems. i can ofc try to get a repro case, let me see. |
| 20:58 |
|
Fleckenstein joined #minetest-dev |
| 21:00 |
erlehmann |
josiah_wi, try the following: go to commit 80d12dbe, then do a fuill build. go to commit 188b0011 (tip of x2048/alpha_blend_indexed), then do an incremental build. if it fails, you will be in a situation where doing a full rebuild will *also* most likely fail. |
| 21:00 |
erlehmann |
you can probably get similar results by going to 80d12dbe, doing a full build, then going to master. then doing an incremental build. not sure. |
| 21:01 |
erlehmann |
luatic you can build fast, can you try those examples? |
| 21:02 |
erlehmann |
josiah_wi you know cmake – so usually i can clean those things by removing CMakeCache.txt, but sometimes that fails. is there a way to tell cmake to build everything? like “make -B”? |
| 21:02 |
erlehmann |
if it is not obvious, i ran into this when wanting to compile x2048/alpha_blend_indexed |
| 21:04 |
erlehmann |
josiah_wi i will report back once i have cofirmed the 80d12dbe → 188b0011 issue. |
| 21:04 |
erlehmann |
confirmed |
| 21:06 |
x2048 |
erlehmann, do you use irrlichtmt inline or external? |
| 21:08 |
sfan5 |
erlehmann: there is nothing buggy about exporting a model with multiple materials, just user error |
| 21:16 |
|
erlehmann joined #minetest-dev |
| 21:17 |
MTDiscord |
<josiah_wi> erlehmann, I usually build out of source and delete the directory to rebuild. |
| 21:18 |
MTDiscord |
<josiah_wi> Better solution might be to run make clean. I rarely delete the Cache; I simply clear variables I need to reset. |
| 21:19 |
x2048 |
Hmm... just tied to build both 80d and master from scratch, cmake does not find GMP and does not use the built-in one. josiah_wi erlehmann |
| 21:19 |
erlehmann |
josiah_wi as far as i can see “make clean” is only ever necessary if make fails at correctly determining dependencies |
| 21:20 |
erlehmann |
(some build systems do not even have a concept of having a build target that deletes everything) |
| 21:20 |
erlehmann |
(because it is never needed) |
| 21:21 |
erlehmann |
x2048 i can not help you finding gmp sorry |
| 21:21 |
erlehmann |
thing is, i can build 80d12dbe, but somewhere between 80d12dbe and current master a dependency crept in that screws up rebuilds |
| 21:21 |
x2048 |
sfan5 Do you remember the problem with normals in MCL2 I showed the other day? |
| 21:22 |
sfan5 |
yes |
| 21:22 |
erlehmann |
(while it does work correctly on full rebuilds, that is probably bc there you don't need dep tracking) |
| 21:22 |
MTDiscord |
<josiah_wi> erlehmnn, zstd? |
| 21:22 |
erlehmann |
no, josiah_wi, it can't be zstd |
| 21:22 |
x2048 |
I found the reason why there was no effect of 'fixing' them. |
| 21:23 |
erlehmann |
josiah_wi i mean dependency as in “if a file gets changed, a target needs to be rebuilt” |
| 21:23 |
erlehmann |
josiah_wi i can build newer zstd stuff just fine, i think the bug got introduced around the commit that makes TEST_MOD_PATH a thing maybe (or maybe it only reveals it) |
| 21:25 |
x2048 |
sfan5 https://github.com/minetest/irrlicht/blob/81bae5b717a79fc2b05a09f760afc7b44da98487/include/ISkinnedMesh.h#L99 |
| 21:26 |
x2048 |
Every weight in every joint 'caches' position and normal of the corresponding vertex, making mesh manipulator effectively useless |
| 21:26 |
x2048 |
Refeshing that cache renders correct normals (and lighting etc.) |
| 21:28 |
MTDiscord |
<josiah_wi> erlehmann, it could be subtle as a dependency version requirement changing. CMake doesn't recalculate packages after it already found them. |
| 21:28 |
erlehmann |
josiah_wi that seems like a bug though |
| 21:29 |
erlehmann |
well without putting it into the CI i doubt we'll find those commits |
| 21:30 |
erlehmann |
the “easy” way i figured was: 1. fully build a commit 2. go to the next one, do a partial build. (ideally with my git post-checkout hook) |
| 21:30 |
erlehmann |
but you have to do this for each comit |
| 21:30 |
erlehmann |
commit |
| 21:30 |
MTDiscord |
<josiah_wi> Now that you've given me a repo strategy I believe I can nail this particular example bug, I'll just need some free time. |
| 21:30 |
erlehmann |
until you find the bad one |
| 21:30 |
erlehmann |
nice |
| 21:30 |
erlehmann |
i mean not even bisect helps here |
| 21:30 |
MTDiscord |
<josiah_wi> Where can I get the hook? |
| 21:31 |
erlehmann |
i posted it in the issue |
| 21:31 |
erlehmann |
wait |
| 21:31 |
erlehmann |
i get it |
| 21:32 |
erlehmann |
josiah_wi you could reproduce the example bug though? |
| 21:32 |
MTDiscord |
<josiah_wi> I will get back to you on that when I have time to try it. |
| 21:32 |
erlehmann |
josiah_wi it is here: https://github.com/minetest/minetest/issues/11749 |
| 21:32 |
sfan5 |
x2048: that seems flawed, do you see an easy fix? |
| 21:33 |
sfan5 |
ideally by only touching irrlicht code |
| 21:33 |
erlehmann |
josiah_wi also see this comment https://github.com/minetest/minetest/issues/11749#issuecomment-957853290 |
| 21:34 |
x2048 |
I think I've made part of the fix, will file a PR to show shortly. |
| 21:34 |
erlehmann |
josiah_wi in the issue, sfan5 also asks “Suppose this approach finds a newly introduced issue in a commit, how would it be fixed?” – maybe you can answer that, bc i do not know too much about cmake |
| 21:34 |
x2048 |
Is it OK to commit CRLF into Irrlicht? |
| 21:34 |
sfan5 |
yes |
| 21:35 |
sfan5 |
should match the file you are editing |
| 21:35 |
x2048 |
git diff complains :-/ |
| 21:35 |
erlehmann |
real villains use LFCR |
| 21:39 |
|
Extex joined #minetest-dev |
| 21:40 |
x2048 |
sfan5 here's part 1 https://github.com/minetest/irrlicht/pull/77 |
| 21:40 |
x2048 |
I think I can wire it up to mesh manipulator to update the caches automagically. |
| 21:44 |
sfan5 |
that would be nice |
| 21:46 |
x2048 |
Pushed another commit. I did not add the code to recalculateTangents because we do not use them AFAIK |
| 21:49 |
x2048 |
So this works now, but only if I force checkMeshNormals() to return false. I can try to detect 'insane' normals, but that's costly. Shall I do it? |
| 21:50 |
|
pi3 joined #minetest-dev |
| 21:53 |
MTDiscord |
<josiah_wi> erlhmann, do I need to change any default CMake options? |
| 22:18 |
|
v-rob joined #minetest-dev |
| 22:36 |
MTDiscord |
<josiah_wi> erlehmann, the hook is running but seems to have no effect. CMake is rebuilding almost everything on x2048/alpha_blend_indexed |
| 22:40 |
x2048 |
Added "relatively fast" detection of broken normals, MCL2 looks much better now: https://user-images.githubusercontent.com/4933697/140828158-3b275306-af88-4612-a5bc-3a53a8403a2e.png |
| 22:52 |
MTDiscord |
<josiah_wi> erlehmann, I can not reproduce. CMake reconfigures itself and everything rebuilds. |
| 23:01 |
erlehmann |
josiah_wi hmm, weird. anything else other than CMakeCache.txt that could be messed up? |
| 23:13 |
MTDiscord |
<josiah_wi> erlehmann, the post checkout script is not working. It runs but has absolutely no effect. |
| 23:13 |
MTDiscord |
<josiah_wi> Simply switching branches and back forces a complete rebuild. |
| 23:14 |
erlehmann |
josiah_wi oh damn |
| 23:16 |
MTDiscord |
<josiah_wi> I had to retype the script because wifi is too slow to copy off GitHub. Now reading it backwards to double check. |
| 23:19 |
MTDiscord |
<josiah_wi> Found the typo. Thank you, Zed A Shaw. |
| 23:22 |
MTDiscord |
<josiah_wi> It'll take me maybe 20 minutes or more to recompile. |
| 23:39 |
MTDiscord |
<josiah_wi> erlehmann, it rebuilt version.cpp and linked. No error. Cannot reproduce. |
| 23:39 |
MTDiscord |
<josiah_wi> Maybe I have another typo somehow. I expected more to rebuild. |
| 23:40 |
erlehmann |
josiah_wi i can pastebin you the script |
| 23:41 |
erlehmann |
josiah_wi https://mister-muffin.de/p/Cp_w |
| 23:41 |
erlehmann |
remember to chmod a+x it |
| 23:44 |
MTDiscord |
<josiah_wi> Done, no change. Still rebuilds version.cpp with no error. |
| 23:44 |
MTDiscord |
<josiah_wi> Do I need to reconfigure? |
| 23:46 |
MTDiscord |
<josiah_wi> I can stay on the same irrlicht commit, right? |
| 23:55 |
erlehmann |
i have no idea why it does not do the thing on your machine that it does on mine :( |
| 23:56 |
erlehmann |
i may have done sth else *before* switching those commits |
| 23:56 |
erlehmann |
the problem is that it's so hard to track down |
| 23:57 |
erlehmann |
josiah_wi i'll have to figure out a small test case that will be runnable from not having a working directory at all |
| 23:57 |
erlehmann |
i.e. a small shell script that triggers it |
| 23:57 |
erlehmann |
until then, josiah_wi, try to leave the hook active, sooner or later you will checkout sth, do a rebuild, see the error |
| 23:58 |
erlehmann |
maybe you can debug then |
| 23:58 |
MTDiscord |
<josiah_wi> Why is it rebuilding nothing, though? |
| 23:58 |
erlehmann |
if you don't hit the error, it will speed up your builds ^^ |
| 23:58 |
MTDiscord |
<josiah_wi> That... won't work. |
| 23:58 |
erlehmann |
wdym nothing |
| 23:58 |
MTDiscord |
<josiah_wi> I need the stuff to actually compile. |
| 23:58 |
MTDiscord |
<josiah_wi> It recompiles version.cpp and literally nothing else. |
| 23:59 |
erlehmann |
when you switch between the commits? |
| 23:59 |
MTDiscord |
<josiah_wi> Yes. |
| 23:59 |
MTDiscord |
<josiah_wi> I'll look at the diff after dinner. |
| 23:59 |
erlehmann |
yeah oh |
