| 5 Sep 2024 |
outfoxxed | you probably want to give it a custom logging category so its easy to search for in logs | 08:24:21 |
outfoxxed | that function will only be called for disk stores and lookups | 08:24:52 |
K900 | In reply to@outfoxxed:outfoxxed.me no, i mean the store path into libraryVersionHash Like, the application store path? | 08:26:41 |
K900 | That feels very cursed tbh | 08:26:49 |
outfoxxed | yes | 08:26:49 |
K900 | Though I guess if we do that we can drop the Qt cmake hack | 08:26:59 |
outfoxxed | its less cursed than anything else we discussed | 08:27:00 |
K900 | Which is also pretty cursed | 08:27:04 |
outfoxxed | i think we can drop the cmake hack regardless | 08:27:12 |
outfoxxed | because tag solves the same problem | 08:27:18 |
K900 | Well yeah but you now have a patch to allow us to pass a custom tag | 08:27:35 |
outfoxxed | I'm proposing hashing the tag and application path together | 08:27:35 |
K900 | And we could drop that | 08:27:38 |
outfoxxed | yes | 08:27:42 |
K900 | We don't need to though | 08:27:44 |
K900 | We can just hash the store path | 08:27:48 |
outfoxxed | what I mean is i think we can drop that anyway | 08:27:54 |
K900 | How do we set the tag then? | 08:28:03 |
K900 | Or can we just write that file | 08:28:06 |
outfoxxed | you can just write the file | 08:28:12 |
K900 | Oh | 08:28:14 |
outfoxxed | check the cmake file the patch is on, the logic is there | 08:28:25 |
outfoxxed | in the tarballs there should just be a .tag file in the root | 08:28:34 |
K900 | My brain just ignores cmake unless forced to | 08:28:37 |
K900 | But yeah that works | 08:28:42 |
outfoxxed | i don't think we should even need to set it though | 08:29:00 |
K900 | But also I'm thinking just hashing the store path might be weird for like locally built things | 08:29:02 |
K900 | We should because we could have a different build of the same Qt version | 08:29:24 |
K900 | With a different struct layout | 08:29:30 |
K900 | That's not guaranteed to be consistent across ABIs etc | 08:29:43 |