Time Nick Message 00:22 MTDiscord sfan5 reverting that cmake pr might be required 00:23 MTDiscord yes lets remove linking against macOS system libraries required for windowing and input that certainly can't go wrong 00:28 MTDiscord also, removing of -DIRRLICHT_INCLUDE_DIR and -DIRRLICHT_LIBRARY is quite possibly the most incompetant move possible 00:28 MTDiscord cmake prefix is not intelligent 01:10 MTDiscord secondly, the documentation for compiling still mentions IRRLICHT_LIBRARY 01:12 hecks Jordach 01:12 hecks you're maintaining the macos port right? 01:13 MTDiscord yes 01:13 hecks can you tell me real quick how the opengl situation looks on that 01:14 hecks for example do you need to use an opengl extension loader or is just using a 2.1 header fine 01:15 MTDiscord 2.1 is default, however opengl context profiles allow using upto 4.3 01:15 hecks but no procaddress monkeying required right? 01:15 MTDiscord nope 01:15 MTDiscord (even mesa ignores khronos group advice about versioning for compat reasons) 01:16 hecks i'm trying to figure out whether i should salvage any GL wrangling code from irr, import a lib, use something like glad or just do it myself 01:16 hecks gl 2.1 seems to support everything es2 does 01:17 hecks that would make pointer monkeying necessary only on windows, linux, bsd 01:17 hecks if gl2 had a real core profile my job would be a little easier 01:18 MTDiscord yeah, you can use core profiles from 3.3 to 4.1 on mac's from the last decade 01:18 hecks i was wondering that too 01:18 hecks would anyone care if i just opened a 3.3 core context on mac 01:18 MTDiscord no 01:18 MTDiscord that opens up better glsl options 01:18 hecks alright =] 01:19 hecks well 01:19 hecks i still have to restrict myself to what android and GL2 cards can do but 01:19 hecks if it's a core profile, that still aligns 01:19 hecks gles2 is also a lot like a core profile, there are no unnecessary functions in it 01:19 MTDiscord the oldest version of macOS that supports 3.3 is Lion, and I target Mavericks as C++11 wasn't added until Mavericks 01:20 hecks so it literally won't compile on versions without the glcorearb header? 01:20 MTDiscord (every mac from 2007 can run that - openGL 3.3 may not be possible on certain ancient systems) 01:20 hecks cool 01:21 hecks so now all i'd have to do is figure out how to efficiently squeeze out just the subset of functions i need on the remaining platforms 01:21 hecks well 01:21 hecks technically that literally requires wrangling what's in the core header 01:21 MTDiscord the GPU driver won't support it 01:22 MTDiscord see: https://developer.apple.com/opengl/OpenGL-Capabilities-Tables.pdf 01:22 hecks i have that open already 01:22 MTDiscord basically the chips are just too old to support 3.3 01:22 hecks the real question is 01:22 hecks are there any mac users who can't afford an upgrade... 01:22 MTDiscord but pretty much all of the macs from 2009+ will likely run 3.3 without issues 01:23 MTDiscord there's some crazy people running PPC still 01:23 hecks actually better question 01:23 hecks no never mind 01:24 hecks no wait it actually is useful 01:24 hecks can i still open an older context 01:24 hecks 2.1 in particular 01:24 MTDiscord 2.1 is the lowest and yes 01:24 MTDiscord 2.1 is the default context 01:24 hecks that'll do really 01:24 MTDiscord for any OpenGL that doesn't use a core profile 01:24 MTDiscord core profiles are required for 3.3 and higher 01:25 hecks then the plan is to open what's possible starting with 2.1 and use the core header on all platforms except android 01:25 MTDiscord yeah tha tworks 01:25 hecks this should be fine on anything except toasters that literally can't handle the amount of geometry MT pushes around 01:25 MTDiscord oh, Radeon HD 2400 was released in 2008 01:26 hecks first gl3 card? 01:26 MTDiscord basically Macs that are practically 14 years old can run 3.3 managably 01:26 hecks actually 01:26 hecks mesa can also run gl3 01:27 MTDiscord software rendered but yes 01:27 hecks but uhhh okay i won't try to make gl3 mandatory.... it won't fly 01:27 hecks although 01:27 MTDiscord macOS' software renderer can do 3.3 as well 01:27 hecks i think i'll do some conditional VAO usage eventually because that's such a great chatter reducer 01:28 MTDiscord whatever introduces the least amount of debt 01:28 hecks we're defaulting on the debt 01:28 hecks we're bankrupt, man 01:28 hecks dead broke, pocket lint 01:28 MTDiscord adjusting for inflation even 01:29 hecks wrangling gl will take one more reason to live away from irrlicht 01:30 hecks what will be left... gui, that's being dissolved slowly too 01:30 hecks and those funny asset importers 01:30 hecks and the crude animator and skinner 01:30 MTDiscord i mean the assimp library exists 01:30 hecks no 01:30 hecks it's too fat 01:30 hecks we can just keep the importers we have and absorb 01:31 hecks i would not add any new 3D formats except gltf 07:50 sfan5 sfan5: we need a percentage DPI scale setting on top of it 07:50 sfan5 #10729 adds one but isn't ready yet 07:50 ShadowBot https://github.com/minetest/minetest/issues/10729 -- Allow Enabling The Touch UI In A Desktop Build by TheBrokenRail 08:21 sfan5 @Jordach specifying the cocoa+iokit dependency is IrrlichtMt's job now and it already does (well, tries to) 08:22 sfan5 does it show up in one of the IrrlichtMtTargets* files? 13:27 hecks re 10729 you know, i also wouldn't mind desktop users with mice being able to unlock their cursor with middle click and being able to interact everywhere on screen 13:27 hecks just for consistency and completeness, and to allow the new GUI system to have interactable floating elements 13:28 hecks which would truly make forms no different from hud 13:39 specing hecks: yes! I'd love this! 13:40 specing One very good use of this would be to open two formspecs side-by-side, such as two chests. So you can move items directly, without passing through your inv 13:40 hecks two forms side by side aren't a problem really 13:40 hecks you just have to make a form that pretends it's two forms ;] 13:41 hecks i was thinking of clickable hud elements which wouldn't be modal, they wouldn't disable your controls 13:42 specing spring has this, but in reverse 13:43 specing your cursor is unlocked by default, but clicking middle mouse locks it and moves your viewport 13:43 specing and when it's unlocked, you can interact with lua gui widgets on screen 13:44 hecks i was thinking of system shock and daggerfall 13:44 hecks anyway, the thing is that mobiles are already capable of this and it isn't actually obvious 13:45 hecks i had no idea this was a thing until an android user actually told me 13:46 hecks so at the very least adding the capability to left and right click things that aren't under the cursor would make it consistent, gui aside 13:46 hecks i mean, that aren't under the crosshari 13:46 hecks crosshair 13:46 hecks but on screen 13:46 hecks and perhaps to also manage the hotbar like android users are able to 15:54 sfan5 hecks: if you think the png PR is ready you can merge it yourself btw 15:54 hecks so it's just one approval for coredev PRs? 15:55 sfan5 the submitter also counts 15:57 sfan5 so yes 16:14 MTDiscord The README still lists the IRRLICHT_LIBRARY etc. variables under the options header. 16:15 MTDiscord I should've checked for all occurances of those variables in the README, but I didn't. 16:24 hecks now why does cmake yell at me that it can't find irrmt if i'm literally pointing it to that... 16:25 MTDiscord well, there were some changes to that 16:26 MTDiscord $25 to whoever reverts that PR 16:27 hecks the directory variable names have not changed 16:27 MTDiscord IRRLICHT_* doesn't work anymore, it more or less needs to be in lib/irrlichtmt 16:27 hecks why does it not recognize the irrmt master as irrmt 16:27 MTDiscord Because it needs to be installed as a systemwide package 16:27 MTDiscord you need to copy irrmt to lib/irrlichtmt 16:27 hecks :DDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 16:27 hecks unix weenies 16:27 hecks fix this 16:28 MTDiscord You’re a core dev revert it 16:28 MTDiscord it doesn't need to be installed as a systemwide package, what are you talking about 16:28 MTDiscord make install always implies systemwide install on UNIX 16:28 MTDiscord just make a symlink if you can't put irrlichtmt into lib/irrlichtmt directly 16:28 hecks i am not making symlinks across partitions 16:29 hecks that's harmful 16:29 hecks let me build it on my data drive or heads will roll 16:29 MTDiscord Basically it expects you to use cmakes package finding subsystem 16:29 MTDiscord Which is absolute garbage 16:29 hecks :DDDD 16:29 hecks peak unix 16:29 MTDiscord On exotic systems that use MSVC or macOS Xcode 16:29 hecks when are we switching to hardcoded paths 16:30 MTDiscord It’s what I was using before the PR 16:30 MTDiscord Why remove the one thing that doesn’t break on exotic config a 16:30 MTDiscord It also has likely broken Homebrew on mac alongside macports 16:30 celeron55 what are you complaining about, cmake works fine 16:31 hecks i'm on cygwin building mingw, anyway i'm not installing irrmt on C: because that's a throwaway partition 16:31 hecks celeron55: what doesn't appear to work is -DIRRLICHT_LIBRARY= etc 16:31 hecks which means i cannot point the build script to the folder that i edit and build irrlicht in 16:32 MTDiscord If DIRRLICHT_LIBRARY was specified then ignore CMakes find package 16:32 MTDiscord It’s that simple 16:32 hecks that's how it used to work 16:32 MTDiscord Except now it requires irrlicht to be make installed post compilation 16:32 MTDiscord Which by default installs to where a package manager would install a premade version 16:33 hecks oh well i guess i'm reverting to head~3 until you fine folks fix this 16:33 hecks locally 16:35 MTDiscord Also I thought one of the project goals was to keep it simple 16:38 sfan5 hecks: do you keep an installed copy of irrlichtmt around or just the checkout? 16:39 celeron55 okay yes this is nonsense, there should be a way to use irrlichtmt from an outside directory without installing it 16:39 sfan5 there is 16:39 hecks i build in place in the checkout 16:39 hecks my mt build script also runs the irr build script 16:40 hecks cygwin's weenie directories are on a trash partition and i'm not keeping anything in those 16:41 sfan5 if you don't mind a make install step for irrlicht you can do that and point mt to it via -DCMAKE_PREFIX_PATH 16:42 sfan5 if you do mind you can sort of do that anyway but symlink stuff so you won't ever need to run make install again (what I do) 16:42 hecks 1. what will that do 16:42 hecks 2. i am not symlinking across partitions 16:43 MTDiscord what's the issue with symlinking across partitions? 16:43 hecks it's filthy 16:43 sfan5 I think windows can't do it, but you won't need to 16:43 celeron55 well the question is, is it acceptable that you have to install irrlicht to a temporary prefix in order to use it 16:43 hecks i can junction on windows but it's still filthy 16:43 sfan5 to 1: it will do what c55 just said and then work 16:43 celeron55 i've done that with many things so i'm kind of indifferent 16:43 MTDiscord I've done symlinks on windows across partitions, it's worked with no issues 16:44 MTDiscord So wait, building has gotten more complicated now? 16:44 hecks i don't care what "works", i'm not polluting my system to make weenie build systems work 16:44 sfan5 you do not need to install system-wide. 16:44 hecks it worked the way i wanted three commits ago, what changed? 16:44 nrz i'd say the problem is the c++ packagiing, let's move to rust crates 16:44 MTDiscord not really, it's just broke some people's workflows 16:44 hecks what's wrong with giving cmake a path variable 16:44 celeron55 https://github.com/minetest/minetest/pull/11287 16:44 celeron55 this changed 16:45 celeron55 140 lines were removed, 62 added 16:45 celeron55 i.e. it's simpler now 16:45 sfan5 like CMAKE_PREFIX_PATH you mean? I guess not 16:45 hecks not that kind of path 16:45 hecks this is not simpler 16:45 sfan5 not for this workflow no 16:45 sfan5 I miss the convenient option of being able to do this too 16:45 celeron55 basically what was changed is the custom irrlichtmt find script was removed (which supported the variables) and now it uses the cmake standard way of finding irrlichtmt 16:46 hecks and by accident it also removed the ability to just manually set it up 16:46 nrz magic things ❤️ 16:47 hecks if you want to piss off a windows user, make him install and use things that don't stay contained in their little jail folder 16:47 sfan5 you do not need to install system-wide. 16:47 sfan5 maybe I shouldn't put it in bold 16:47 MTDiscord I wanted to improve things, not cause controversy and be a pain to everyone. I'm frustrated nobody spoke up while I was working on this PR, because now it seems things are descending into chaos and I'm at the center of it. 16:47 sfan5 anyway I will be writing down a "how it was before" and "how it is now" to hopefully fix the confusion 16:47 celeron55 meh, it's not that bad 16:48 celeron55 just add the custom find script back 16:48 celeron55 or somehow otherwise add the variables 16:48 sfan5 the issue is not the variables 16:48 celeron55 IRRLICHT_LIBRARY and whatever the include one was 16:48 sfan5 the issue is that a library found via cmake does more than "here is the .so and here is the includes" 16:49 MTDiscord From the perspective of someone who doesn't know Cmake well, what I've gathered is that IrrlichtMT has to be installed now, but it can be installed to a custom directory? 16:49 MTDiscord MSVC purportedly does not have a make install step; that seems like a big issue. 16:49 celeron55 let's just wait for sfan5's write-up first 16:49 celeron55 then continue 16:50 MTDiscord Fair 16:50 MTDiscord Benrob, there's a difference between packaging and installing in CMake terminology. 16:57 hecks serves me right not monitoring build system PRs, but i assumed people know what they're doing 17:01 MTDiscord I will probably be around so I can look over the write-up once, but I think sfan understands what the PR did quite well. 17:02 hecks i'm afraid this does not make anything simpler, it just shifts the complexity to the user's machine 17:04 sfan5 https://github.com/minetest/minetest/pull/11287#issuecomment-888472649 here's the thing 17:04 sfan5 before anyone says the obvious: yes, a common developer workflow is made complicated 17:04 hecks but 17:04 hecks /somewhere/ is now the irrlicht checkout 17:05 hecks i mean, that's what it was for me 17:05 rubenwardy if it uses the CMAKE way, won't there be IRRLICHT_ROOT or IRRLICHT_DIR to point to the module cmake? 17:05 sfan5 /somewhere is the IrrMt checkout, correct 17:06 sfan5 you don't need to move it anywhere 17:06 hecks "Technically not doable but you have two options." 17:06 sfan5 oh you were commenting on a previous section, nvm 17:06 hecks here are your options: make install or make install 17:06 hecks what will make install do? 17:07 sfan5 certainly won't install it system-wide 17:07 MTDiscord well where's the DESTDIR? 17:07 hecks what will it do 17:07 hecks which files and symlinks will it create and based on which variables 17:07 hecks this _i subfolder? 17:08 hecks which will... let me guess, contain a /lib/ /bin/ /include/ just like the folder above it, containing the same things? 17:08 sfan5 these http://sprunge.us/gpuH3H 17:08 sfan5 hence option 2 which makes the files you usually have fit that by means of symlinking 17:09 hecks but the thing is 17:09 hecks CMAKE_PREFIX_PATH is just a root folder of sorts where cmake will now look for shit, correct? 17:09 sfan5 yea 17:09 hecks and if you decide to require that some other lib is installed in this way, i will now require a 17:10 hecks .../minetest/dev/git/cmake_root/... to maintain this little weenie root in 17:10 hecks thanks, i hate it 17:10 sfan5 you can specify multiple paths 17:10 hecks but on principle that's what this is 17:11 sfan5 I guess 17:11 hecks unix users really hate the idea of things staying contained in their own folders 17:11 hecks so the most you can do is create a folder pretending it's a shared root for each library =] 17:12 celeron55 is it not possible to support "cmake -DIRRLICHT_INCLUDE_DIR=/somewhere/include -DIRRLICHT_LIBARY=/somewhere/lib/Linux/libIrrlichtMt.a ." now? 17:12 MTDiscord Not at alp 17:12 MTDiscord All 17:13 celeron55 because i mean, there's the list of workflows, just make them all work nicely 17:13 sfan5 certainly, just add the 140 lines back 17:13 sfan5 and we will have gained nothing 17:13 sfan5 and #11402 can be reopened (albeit minor) 17:13 hecks nothing except sanity 17:13 ShadowBot https://github.com/minetest/minetest/issues/11402 -- Linker errors with IrrlichtMt automatically built alongside, using MSVC 17:14 hecks i mean fine, i keep this crap contained anyway 17:14 celeron55 of course the thing is, cmake automates some things that are otherwise very hard or annoying to do 17:14 celeron55 if you let it do so 17:14 sfan5 if we searched for any of the libraries via pkgconfig such things would have been required a long time ago 17:14 hecks and that would also be weenieism 17:15 sfan5 let me guess you don't static link? 17:15 hecks i guess i don't? 17:15 hecks what's that got to do with library paths though... 17:16 sfan5 commendable but that's one thing this approach simplifies 17:16 sfan5 because irrmt's cmake file can now say to please link X11 17:16 sfan5 anyway, I doubt cmake allows you to import a non-installed project's library but perhaps Minetest's CMake stuff can be made to make the workaround less painful? 17:20 sfan5 @josiah_wi do you happen to know / have better ideas? 17:22 hecks well i guess i'm off to make a fake filesystem root for cmake and move the fabled 140 lines to my build scripts instead 17:22 hecks i just find it funny that unix users do this to themselves and then invent things like docker to get out of the tarpit they made 17:33 MTDiscord It’s almost as if they ship things that only work on their machine 17:37 sfan5 on that note I forgot to say that the writeup is only relevant for building the client 17:37 sfan5 the server still builds with just -DIRRLICHT_INCLUDE_DIR as long as it points to the right path 17:37 hecks everything would work if only everyone used the same computer ;] 17:42 hecks ok but 17:42 hecks does this at least have some positive side effect in the form of like 17:42 hecks letting me unpack each of those mingw libs into the same fake root 17:51 MTDiscord sfan5 I'm not sure I use specifically what you're asking. The reason for the install step is that CMake looks for configuration files in specific locations. The structure of the install tree is actually irrelevant (?). I made it the standard tree for installs, but it could put everything in 1 directory. You could also allow specifying a specific path to the Config file instead of an install prefix. 17:52 MTDiscord Do I have this right that we now have to install irrlicht system wide to compile Minetest? 17:52 MTDiscord use -> understand*. Stupid autocorrect. 17:52 MTDiscord we don't have to 17:52 hecks either install it system wide or fool cmake into thinking you did 17:52 MTDiscord if you put it in lib/irrlichtmt 17:53 MTDiscord Thats system wide buddy 17:53 hecks but.... that's basically installing systemwide :DDDD 17:53 MTDiscord what 17:53 MTDiscord So the answer is yes 17:53 hecks linux users... 17:53 MTDiscord Hey, don't blame us all 17:53 MTDiscord Hang on, we should be able to hax Irrlicht into working with no install. 17:53 MTDiscord I'm talking about putting the cloned irrlicht repo into lib/irrlichtmt in the cloned minetest repo 17:53 MTDiscord The build tree can be the install tree. 17:53 MTDiscord I'm a Linux user and I think this change is stupid 17:53 MTDiscord how is this system wide? 17:54 hecks is lib/irrlichtmt in the cloned minetest repo gitignored and does that actually work? 17:54 MTDiscord The moment you put shit into your path environment is the moment it’s considered installed 17:54 MTDiscord And I have to use a very exotic build script because I have to link against an ancient OSX SDK and the current release 17:54 MTDiscord Doesn't need to be in PATH to work. 17:55 MTDiscord Is this officially documented 17:55 MTDiscord What was this change intended to fix? 17:55 MTDiscord lib/irrlichtmt is in fact gitignored 17:55 hecks i guess lib/irrlichtmt is gitignored though probably it should just be lib/ 17:55 MTDiscord Nice directory 17:56 MTDiscord The change was intended to make the build process more automatic for people who were having trouble with the variables. 17:56 MTDiscord I bet that isn’t even documented 17:56 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/870001724977467442/unknown.png 17:56 hecks the thing is that modifying the CI script and replacing the path variables was a lot simpler than actually bothering to learn how cmake works 17:56 hecks =] 17:56 MTDiscord the lib/irrlichtmt thing has existed for a month now 17:56 MTDiscord Are we talking about minetest/lib/irrlichtmt or /lib/irrlichtmt 17:57 MTDiscord minetest/lib/irrlichtmt 17:57 MTDiscord That makes more sense 17:57 MTDiscord https://github.com/minetest/minetest/commit/fa4dee0e62dcf2bbfb68b17cf97e438eab58be93 17:57 MTDiscord this was a month ago 17:57 MTDiscord and it is in fact documented 17:57 MTDiscord I still think we should be able to use the old variables, but mt/lib seems acceptable if it works 17:58 MTDiscord That’s a tiny bit more acceptable but knowing CPackInstall it’ll copy that garbage in 17:59 hecks it's a little arbitrary, and i think i still have to symlink or copy things around 17:59 hecks but it beats making a fake root... for now 17:59 hecks oh we actually have shit in /lib/ 18:00 MTDiscord I could be wrong but I think lib/irrlicht was exempted from install. 18:00 MTDiscord Meaning? 18:01 MTDiscord Meaning CPackInstall will not "copy that garbage in" 18:01 sfan5 lib/irrlichtmt is gitignored yes 18:02 MTDiscord How does CPack RUN_IN_PLACE=FALSE work with lib/irrlichtmt as a dynamic library? 18:03 MTDiscord Does it break the package? 18:03 MTDiscord Mac static links by default 18:03 sfan5 with lib/irrlichtmt it's never dynamically linked 18:03 MTDiscord Ie instead of dyld files strewn about the app it’s all built into the resultant Minetest binary 18:03 MTDiscord Phew. 18:04 MTDiscord It’s not like I’m doing a ton of research into an iOS build using the existing macOS frameworks 18:05 sfan5 moving your checkout to lib/irrlichtmt is actually a good idea for development purposes 18:05 sfan5 the only rare downside I can see is that this doesn't work if you want to use one irrmt from multiple Minetest checkouts 18:06 MTDiscord People clone Minetest multiple times? I always use branches and I have about 5 build directories. 18:08 MTDiscord multiple clones can be helpful to avoid having to juggle a ton of stashes, if you're working on a lot of stuff at the same time and haven't reached a good commit point yet. 18:09 MTDiscord Interesting. I'll remember that tip. 18:10 hecks screw good commit points, just squash later 18:12 hecks Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.11") 18:12 MTDiscord Or do what I do and screw good commit points and don't squash. I use a convention of putting "checkpoint" at the head of a commit to indicate that it's a WIP that I'm making just to ensure I don't lose my work. 18:12 sfan5 heh 18:13 hecks so what now, do all the path variables not work anymore? 18:13 sfan5 they certainly do 18:13 sfan5 the buildbot that runs on CI uses every one of them 18:15 MTDiscord I asked for thorough testing because I wanted my first PR to me a good one. internal screaming The ZLib thing doesn't sound like something that could be caused by this though, oddly. If you are on Linux and want to provide more information I can try to reproduce. 18:15 hecks guess whose scripts i'm using... 18:17 MTDiscord Is this a mingw build? 18:17 hecks yes 18:17 hecks it's a modified buildbot script 18:18 hecks the paths are actually correct and i get 18:18 hecks CMake Error at /usr/share/cmake-3.17.3/Modules/FindPackageHandleStandardArgs.cmake:164 (message): 18:18 MTDiscord It says version 1.2.11 of zlib was found; there shouldn't be a version requirement!? 18:18 hecks which leads me to believe that cmake has gone rogue and ignores the path 18:19 hecks does the buildbot actually work right now? 18:19 sfan5 https://github.com/minetest/minetest/runs/3174982877 18:20 MTDiscord The path works hecks. It's a version error. 18:20 hecks it's the version from the buildbot...... 18:20 MTDiscord Wait, is it using the wrong path? 18:20 sfan5 this would be bad but here's my guess: cmake has code to look for zlib, we just call that, it is broken in your version 18:21 hecks it's using the right path... 18:21 sfan5 but this wouldn't explain why it's broken now and not before 18:21 hecks i'll delete packages and libs folders 18:21 sfan5 throw away your CMakeCache.txt just in case 18:21 hecks i did 18:22 hecks maybe the buildbot works by accident 18:22 MTDiscord mingw grabs its own copies of DLLs for everything. I think it found hecks' system ZLib instead of the one it downloaded. 18:22 MTDiscord Hence the wrong version. 18:23 sfan5 but the version is not wrong 18:23 sfan5 and why would it do that when ZLIB_LIBRARY and ZLIB_INCLUDE_DIR are given 18:23 MTDiscord Maybe it's because it's not a DLL. 18:23 hecks cmake has gone rogue and demands we do everything its way from now on 18:23 MTDiscord The buildbot doesn't try to build with Irrlicht in lib/irrlichtmt. 18:24 MTDiscord Maybe that is causing it. 18:24 hecks how 18:25 hecks see, what a wonderful build system, we've now progressed to committing voodoo... 18:25 MTDiscord The buildbot pulls a prebuilt archive. 18:25 hecks but why would it break 18:25 sfan5 CMakeFiles contains two log files, maybe those help 18:26 hecks i'd like to restate my earlier question 18:26 MTDiscord Running the CMake scripts in irrlichtmt could break (?). 18:26 hecks if i put all the stupid libs in this fake root for cmake, would it find them 18:26 hecks i can just do that 18:26 MTDiscord If my hypothesis is correct then yes. 18:27 hecks dcmake_prefix_path right? 18:27 sfan5 yea 18:27 MTDiscord But that's a hacky workaround, not a solution, and we haven't even determined the precise cause. 18:28 MTDiscord I want to repro but my computer is in use my someone else yet. 18:28 hecks i thought that's the "correct" way? 18:29 MTDiscord Putting all the DLLs there? No. 18:29 MTDiscord The DLLs should be found where buildbot extracts them. 18:30 sfan5 I don't think cmake searches for DLLs 18:30 hecks i meant includes and libs 18:30 sfan5 just so we're on the same page: you link to a .dll.a but at runtime you require the .dll 18:30 hecks yes i know how linking works 18:30 hecks but josiah is right, this is voodoo 18:30 hecks there's no reason it shouldn't work the way i have it now 18:31 MTDiscord My current understanding is that buildbot tells CMake where ZLib is, CMake tries to look for it anyway, boom. 18:31 hecks see: "cmake has gone rogue" 18:32 sfan5 did you check the cmake log files inside CMakeFiles 18:33 MTDiscord Ah, so yes using a "fake root" should fix this. Irrlicht has its own mingw scripts afaik. 18:33 hecks yes, and there's nothing about zlib in these =]]] 18:33 MTDiscord Irrlicht probably needs to be built first with mingw and then linked. :| 18:34 sfan5 wat 18:34 hecks uhhhhhhhhh 18:34 MTDiscord Invoking the Irrlicht CMakeLists.txt during a mingw build probably is the cause of the error. 18:34 hecks ??? 18:35 hecks i have a better question 18:35 hecks would cmake traverse down to lib/irrlichtmt and try to build that while i'm trying to build mt 18:35 MTDiscord Yes. 18:35 hecks well then placing irrlicht there is pretty stupid! 18:36 sfan5 is it? 18:36 hecks depends 18:36 hecks maybe i can just merge the build scripts 18:36 hecks but i don't really want to 18:36 hecks i want the ability to build irr independently... 18:37 hecks besides the zlib versions are identical and it gets a zlib path anyway so what is its problem... 18:37 MTDiscord That's what the "fake root" would do. 18:37 sfan5 so you're testing with irr inside lib/irrlichtmt right now? 18:37 sfan5 because I've never tested the buildbot with that 18:37 MTDiscord I'm hypothesizing that one zlib is a .dll.a and one is a .so 18:38 hecks why would either of them be a .so 18:38 hecks i'm doing mingw inside cygwin 18:38 MTDiscord Yeah sfan, I'm saying I think that's the issue. It should work though, if it doesn't it's a bug. 18:38 MTDiscord Oh. Maybe there is no .so zlib anywhere then. 18:39 hecks let me just figure out how to unpack the libs into the same folder instead, link the stupid irrlicht output there and leave it at that 18:39 hecks i hate unix 18:41 sfan5 I have no idea at this point 18:46 MTDiscord Probably too late now but the way to debug this is to run the configuration step in trace mode and see what step caused the error. 18:46 hecks i don't care 18:46 hecks i just want to build this 18:49 celeron55 < hecks> i just find it funny that unix users do this to themselves and then invent things like docker to get out of the tarpit they made 18:49 celeron55 i don't understand this either 18:49 celeron55 unix uses a physical file system as if it was a logical database or something 18:49 celeron55 it makes no sense 18:50 hecks it's because it's a 1970s system for shared computers accessed over a text terminal 18:50 celeron55 well yeah, it works for a router 18:50 celeron55 but for a router anything would work 18:50 hecks it works for a shared computer accessed through a terminal =] 18:51 hecks i have no complaints about my headless openbsd server, it does its job well 18:51 hecks but this is no way to use a workstation... 18:51 sfan5 I don't know which ideal state you are envisioning here 18:52 hecks the ideal state is that a program makes no assumptions and comes with everything it needs =] 18:52 hecks and stays contained in its folder unless otherwise specified 18:52 sfan5 being able to tell cmake to look in /whatever/hello/I/buried/my/files sounds like it'd break the "like a logical database" thing 18:52 sfan5 but apparently that's not enough 18:53 sfan5 I understand how this makes the dev usecase annoying, I use one of the described workarounds myself 18:53 sfan5 but the principles on which cmake's find a package thing is built on are sound to me 18:54 hecks well i'm forced to fool cmake into using a different path, but it still must be a unix style hierarchy and cmake (and every unix thing) is written with the assumption that these folders are just shared by everything 18:54 sfan5 and I don't have a better idea how you could preserve the "files can be whereever with no structure" property 18:54 hecks and it's an absolute nightmare in my case because it's a cross compile 18:55 hecks i have to actively guard this build system from being aware of cygwin 18:55 celeron55 why do you use cygwin, by the way? 18:55 sfan5 you can't blame "running a cross-compile from a system that is actually native or not really" on unix 18:56 celeron55 personally i've found msys to work well on windows 18:56 hecks because it's faster than using a linux vm 18:56 hecks and smaller than msys 18:56 hecks i only use it for two things: building things and ssh 18:57 hecks it's contained to a trash partition and considered disposable 18:57 hecks i've built many things with cmake and mingw but i haven't had to monkey around with it like this until today 18:57 celeron55 is something preventing you from putting irrlichtmt into lib/irrlichtmt and letting cmake automatically build it as a dependency of minetest? 18:58 hecks yes, read the log 18:58 hecks it breaks somehow 18:58 hecks so now i'm trying to just use the fake cmake root, i don't know yet if that'll work 19:00 celeron55 i can only come to the same conclusion that it should work 19:00 celeron55 this is ridiculous 19:01 sfan5 it should and it probably would if I were to try 19:01 hecks if it ain't broke... 19:01 celeron55 either we have some things broken because not enough automation isn't used, or we have some things broken because too much automation is used 19:01 celeron55 well it was broke 19:02 sfan5 but I don't blame cmake for breaking if you are cross-compiling to a system that matches the native system while cmake can't actually use the native libs 19:02 celeron55 https://github.com/minetest/minetest/issues/11402 19:02 celeron55 this is how it was broken 19:02 sfan5 the buildbot sets CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY though, so maybe even that should work 19:06 celeron55 we probably have only one alternative to some variation of this mess: requiring building irrlichtmt separately and setting the variables manually like before. For everyone, no easy pass for users 19:06 MTDiscord The structure of the install tree for a "fake root" can be arbitrary. 19:07 MTDiscord It's determined by the Irrlicht CMake and is completely configurable. 19:09 v-rob hecks: re making the HUD interactable and multiple forms open at once: I've actually been planning this for a long time (although not the middle click specifically). There will be different "containers" for each GUI (including HUD) that any mod opens so mods can interop without breaking each other. So, to make the HUD interactable, move all HUD containers from the HUD environment to the GUI environment. And, for multiple forms at the same time, just 19:09 v-rob open another container without closing the current one(s). 19:09 v-rob Of course, binding middle click couldn't very well be done from a mod yet. 19:09 hecks i mean to hard bind middle click to release the cursor 19:09 hecks and to lock it back again 19:10 hecks since it's currently unbound anyway 19:10 sfan5 or lock it back in when the user clicks into the world area? 19:10 hecks no, make it act like touchscreen interactions 19:10 sfan5 or do you want users to be able to use android-style touch-where-you-interact controls simultanously 19:10 sfan5 ah 19:10 hecks yeah 19:10 hecks because it's kinda weird that clients from one platform have this superpower that nobody knows about =] 19:12 v-rob Oh, I didn't realize you wanted full touchscreen interactions. Well, making the HUD interactable still will be possible :) 19:12 hecks there's no conflict between the two 19:12 hecks it's just that since there's a PR to make touch available on desktop, and touch has this interaction mode 19:12 hecks and mouse3 is unbound 19:13 hecks it makes sense to do this 19:13 v-rob Yeah, it does 19:15 hecks mmmmm cmake can't find irrlicht again 19:16 hecks oh of course 19:16 hecks cmake wants its magical files, it doesn't suffice to just give it a /lib/ and /include/ 19:17 hecks i broke my scripts for nothing 19:17 hecks neither way works for me 19:44 MTDiscord ln -s /Users/Jordach/testfolder2/irrlicht /Users/Jordach/testfolder2/minetest/lib/irrlichtmt 19:44 MTDiscord this works for me 19:44 MTDiscord good fucking show @josiah_wi 19:45 MTDiscord you just broke codesigning 19:45 celeron55 don't get so personal, it's just the cmake way of breaking stuff 19:45 MTDiscord it's not CMake 19:46 MTDiscord since minetest doesn't link to libpng anymore 19:46 MTDiscord while irrlicht does causes it to half static-link minetest and half dynamic like 19:46 MTDiscord link, which causes the mac kernel to shit the bed 19:46 MTDiscord (by extension probably BSD) 19:49 hecks -- Installing: ../libs/irrmt/usr/local/include/irrlichtmt/SSharedMeshBuffer.h 19:49 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/870030130846785586/Screenshot_2021-07-28_at_20.48.57.png 19:49 hecks aaaaaaaaaaah so this is what make install does :-DDDDD 19:49 MTDiscord left: old CMake, right: new cmake 19:49 hecks see, should have told me i also needed to simulate the existence of /usr/local in my fake root... 19:49 hecks clown world... 19:53 MTDiscord also he forgot to read the damn comment in src/CMakeLists.txt 19:53 hecks oh and of course it still doesn't find it 19:53 MTDiscord Minetest itself does not use them, but we link them so that statically linking Irrlicht works. 19:53 hecks ok so 19:53 hecks i make install to a dummy dir 19:53 hecks i set DCMAKE_PREFIX_PATH to this dummy dir 19:53 hecks it still can't find anything 19:54 hecks what now 19:59 MTDiscord that should theoretically patch macOS 19:59 MTDiscord will jump into msvc land and solve that too 19:59 sfan5 hecks: does the described "option 1" not work for you? 19:59 hecks it just did BUT 19:59 hecks -DCMAKE_PREFIX_PATH=$libdir/irrmt/usr/local \ 20:00 sfan5 your ideal setup will look different but I hope at least that works 20:00 hecks this is what you actually have to do 20:00 sfan5 did I accidentally leave out usr/local? 20:00 hecks yup 20:00 sfan5 oops 20:00 hecks anyway this is very brittle, i hope we never ever add any more dependencies in this way 20:01 sfan5 there is no need for them in principle, I removed them in my setup 20:01 hecks no more relying on cmake to find shit 20:01 hecks not everyone uses linux or wants to turn their system into linux 20:01 hecks this is fine to contain irrmt alone but no more 20:02 sfan5 well IrrlichtMt is going away so there won't be more 20:02 sfan5 just less 20:02 sfan5 eventually 20:03 hecks thanks for giving me one more reason to take this thing behind the shed and shoot it 20:07 MTDiscord It seems like good internet resources for learning about good dependency structuring are something computer science lacks, or I just haven't been able to find them. I've read many of the papers available online about good CMake design, and that was the foundation for the decisions I made in my PR. 20:07 MTDiscord and dissolve the body in acid, it's the only way to be sure 20:08 hecks if a build system needs whitepapers to explain how to use it, it's probably byzantine rubbish 20:08 MTDiscord If someone could give me some references from people who really understand this stuff (not just controversial opinion) then I'd greatly appreciate it. 20:08 hecks my controversial opinion is that attempting to understand this stuff is the mistake =] 20:09 MTDiscord There are 2 hard problems in computer science: 1. naming things, 2. concurrency, 2. concurrency, 2. concurrency, and 3. off-by-one errors. 20:09 MTDiscord if i can fix a horrifying cmake setup that only works on one machine and introduce support for vcpkg 20:09 MTDiscord this should be much less aggravating 20:09 hecks oh hey 20:10 hecks it fails to find irrlicht again... i hardly did anything 20:10 hecks this thing is cursed, people 20:11 MTDiscord ??? 20:11 MTDiscord >removes cmakecache to force regeneration of files 20:11 hecks done already 20:11 MTDiscord >builds shared libraries as dynamic 20:12 hecks i'm already feeling the enhanced productivity 20:12 hecks this thing creates jobs! 20:16 MTDiscord Hecks' point is good, that if a build system is difficult to explain it's probably too complicated. I think that extends to stuff in general. However, this isn't supposed to be harder to explain and I don't understand why it is. I had hoped this would be a learning experience for me, but instead it's turning into a "you need to learn" experience. 20:17 MTDiscord using stackoverflow as a hammer to fix nails is a very bad idea™️ 20:17 MTDiscord also - this line https://github.com/minetest/minetest/commit/cf136914cf421ee52f6806eda2fa97740d0ee552#diff-148715d6ea0c0ea0a346af3f6bd610d010d490eca35ac6a9b408748f7ca9e3f4L299 is extremely obvious 20:18 sfan5 yes it's very obvious 20:18 sfan5 because you know what the new cmake importing does 20:18 sfan5 it automatically handles this 20:19 MTDiscord no it's a cock up that makes the british government look functional 20:19 MTDiscord warning: changes being made to the file will invalidate the code signature in: 20:19 MTDiscord it's not static linking 20:19 MTDiscord I didn't use stack overflow except for debegging issues. I read papers about the right way to structure CMake builds. I have no other source. I read 3-4 papers and they all agreed. Nobody said there was a better way. Now everyone says I made a mistake but nobody wants to take the time to teach me, or they don't have a clue themselves, and I'm just tired and confused. 20:19 MTDiscord This is not how progress is made. 20:19 MTDiscord minetest-5.5.0-dev-osx/minetest.app/Contents/Frameworks/libpng16.16.dylib (amd64) 20:21 hecks if nobody in the room knows how to use cmake "properly" then why are we doing it... 20:21 MTDiscord what we had was human understandable and god forbid 20:22 MTDiscord a reasonably straightforwards user experience 20:22 hecks instead of monkey patching that MSVC build issue 20:22 hecks anyway uhhh 20:22 hecks my shit suddenly stopped working with /usr/local too =] i don't know what happened 20:23 MTDiscord we've reverted worse stuff for less 20:25 MTDiscord Based on the discussion I think explaining to Jordach why the static linking thing is irrelevant is unnecessary and pointless because it's internal CMake magic. All I can say is, if it's broken, file an issue. It's supposed to work. 20:25 MTDiscord i'm now hacking and chopping away at the cmake 20:25 MTDiscord because before even with your irrlicht changes it was fine 20:26 MTDiscord Ironically most of the magic happens on the Irrlicht side. 20:26 MTDiscord it's the crap job done to CMakeLists 20:26 MTDiscord and i build with clang 20:27 sfan5 this is pointless without further detail 20:27 sfan5 such as your irrmt build flags 20:27 MTDiscord i stuffed irrmt into /libs/irrlichtmt 20:27 MTDiscord for some reason, libpng is dynamic linkingh 20:28 sfan5 didn't you used to need some flag to tell it to not do that? 20:28 sfan5 if so, add it again this time to the MT cmake command 20:28 MTDiscord the correct result is that all libraries staticly link 20:29 MTDiscord and have zero dylib files inside the app 20:30 hecks wow finally 20:30 MTDiscord I remember some libpng thing in Jordach's script, and yes, it should just be passed to irrlicht instead, which I'm uncertain about with the lib/irrlichtmt structure. 20:31 sfan5 it should still read global flags, anything else would be bad 20:31 MTDiscord that was because minetest needs to depend on it from generating a linked library to a linked lib 20:31 MTDiscord this prevents that entire scenario 20:32 sfan5 does it? 20:32 MTDiscord building MT with brew caused dylibs to lose their code signatures 20:32 MTDiscord i've had to build every MT dependancy manually 20:36 MTDiscord > cmake . -DRUN_IN_PLACE=FALSE -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" -DBUILD_SHARED_LIBS=FALSE 20:36 MTDiscord There may be an exception to the "it should be simple to use" concept, and that's when you're trying to wrangle the CMakeLists to make Mac work. I should've documented the system very thoroughly, and I'm increasingly convinced I need to go do that rn, but understanding CMake helps with developing it. 20:36 MTDiscord still generates a libpng dyld 20:36 sfan5 minetest does not build libpng so it does not "generate" the .dylib 20:36 MTDiscord Aren't you building libpng yourself? 20:36 sfan5 rather it's probably picking it 20:36 MTDiscord it's already compiled locally 20:36 sfan5 so you should point it to the libpng.a 20:37 MTDiscord ^ 20:37 MTDiscord i've also stripped the offending ARM NEON nonsense from it 20:38 MTDiscord Considering that the project's goal is to absorb Irrlicht I'm not sure how much time is worth putting into documenting the CMakeLists in detail. 20:39 MTDiscord full clean rebuild time 20:40 MTDiscord You're going to need to set the paths to your static dependencies (e.g. libpng.a) in any event. 20:40 MTDiscord this was with src/CMakeLists.txt changes to ensure png is properly linked 20:40 MTDiscord this test is without 20:41 MTDiscord You added it without even testing the original? 20:41 MTDiscord known working state first 20:41 MTDiscord then play with it 20:42 MTDiscord same result 20:42 MTDiscord I actually highly recommend compiling irrlicht in a seperate directory. 20:43 MTDiscord > Minetest.app/Contents/MacOS/minetest: Mach-O universal binary with 2 architectures: x86_64:Mach-O 64-bit executable x86_64 20:43 MTDiscord Did you try the script I modified for you? 20:43 MTDiscord i don't make unknown changes to scripts without testing in a sandbox env first 20:43 MTDiscord i'm not going to YOLO existing builds into the void 20:43 MTDiscord The recommendation isn't for general usecase btw, just for this. 20:44 MTDiscord my build argument looks more like 20:44 MTDiscord cmake . -DBUILD_SHARED_LIBS=FALSE -DPNG_LIBRARY=/usr/local/libpng/1_6_37/lib/libpng16.a -DRUN_IN_PLACE=FALSE -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" 20:44 MTDiscord Well shoot, I tried to get your script updated and here you are calling me stupid and fumbling with CMake without even testing ite 20:45 MTDiscord i distrust other's changes for sanity 20:45 MTDiscord the last time that happened rm and -rf were very good friends with * 20:45 MTDiscord I hardly changed much. You could easily check what it does. 20:47 MTDiscord The reason I recommend compiling Irrlicht in a seperate directory for this is because you can then deal with them seperately instead of both trying to configure at once. 20:47 MTDiscord i can now safely test that it does build 20:48 MTDiscord it does not mean however it's safe to use 20:48 MTDiscord as MSVC needs checking 20:49 MTDiscord I have a fear that I was ignorant and removed the PNG thing, but I will check that now. 20:50 MTDiscord potentially 20:50 MTDiscord My fear was unfounded; it's there where it should be. 20:51 MTDiscord i never made a single PR to minetest without triple checking things work as expected 20:51 MTDiscord set_sky went through a ton of personal scrutiny 20:52 MTDiscord I checked more than 4 times, on my system. You're the Mac guy; I don't have the tools to test on a Mac and you do. 20:52 MTDiscord OpenCore exists 20:52 MTDiscord you can easily test with a VM under VESA drivers 20:53 MTDiscord but because i'm effectively the Mac maintainer 20:53 MTDiscord also 20:53 MTDiscord running your modified irrlicht command didn't generate them right 20:54 MTDiscord it didn't fix irrlicht being wrong 20:54 MTDiscord Wrong how? 20:54 sfan5 Minetest does not run under opencore 20:54 sfan5 it fails to create a GL context 20:54 sfan5 just compiling is fine 20:54 MTDiscord Let's not forget I reached out to Jordach before PRing this to get his input. 20:54 MTDiscord it shat the .a out in /lib/OSX/libIrrlichtMt.a 20:55 MTDiscord Ok so? 20:55 MTDiscord two months ago in PR hell 20:55 MTDiscord It shouldn't have put it in /lib. I'll recheck the script. 20:56 MTDiscord i'm not pasting the command as it's nearly six years long 20:56 MTDiscord https://gist.github.com/Jordach/860ea57263c28c0755ef32cf222e6b28 20:57 MTDiscord Ok, so it built. 20:57 MTDiscord What's the problem? 20:57 MTDiscord builds fine, doesn't spew the things in the right places 20:57 MTDiscord otherwise cmake won't find it 20:57 MTDiscord which is exactly the problem hecks is havinfg 20:58 MTDiscord Did you run the make install? 20:58 hecks well i'm kinda done with that but i still find this disgusting :o 20:58 MTDiscord you think i want to shit up my path 20:58 MTDiscord no 20:58 MTDiscord It just puts it in a bin/ folder. 20:58 MTDiscord irrlicht/bin 20:59 MTDiscord and i have to run that on every irrlicht change 20:59 MTDiscord I fail to see the downside. 20:59 hecks but if this thing placed files anywhere outside of my mt dev folder i'd be furious 20:59 hecks so if this happens to Jordach then it's a pretty bad thing 20:59 MTDiscord why does it even need to bother with any other directory outside of lib 21:00 MTDiscord It doesn't. 21:00 MTDiscord APFS doesn't support symlinks 21:00 MTDiscord make install can keep everything in your dev directory. 21:00 MTDiscord No need to symlink. 21:00 MTDiscord Read the script. 21:00 hecks wow wtf 21:00 hecks it's failing again 21:01 hecks oh of course 21:01 hecks now i have to rebase every branch 21:01 hecks every PR in existence is suddenly [rebase needed] 21:02 hecks after you "upgrade" your scripts you cannot build any branches made before 21:02 MTDiscord and this is exactly why i don't want to run his scripts without sandboxed testing 21:03 MTDiscord i've been bit before by bad bash scripts 21:03 MTDiscord I just modified yours slightly though. 21:03 sfan5 could pass the old and the new variables at the same time 21:03 MTDiscord you missed certain things entirely lmao 21:03 MTDiscord x64 contains a different build argument to arm64 21:04 MTDiscord I can see myself missing that. 21:04 MTDiscord That's why I showed you the script early on for review e 21:04 MTDiscord and this is why i basically have a notepad open at all times for note taking of interesting behaviors 21:04 MTDiscord sometimes it'll be there when you're scratching your head 21:04 MTDiscord I'm trying to work with you and you've done absolutely nothing to work with you. 21:04 MTDiscord to work with me* 21:05 sfan5 I don't think whatever you guys are doing is going anywhere 21:05 MTDiscord Yeah obviously. :| 21:06 MTDiscord It's just Jordach explaining to me why he's mad at me or something like that. 21:06 MTDiscord i'm not seeing where cmake_install_prefix is even used in irrlicht's cmakelists 21:07 MTDiscord It's built in to CMake. I honestly shouldn't have hijacked it for this but I did. 21:07 MTDiscord why does the user need to know arcane cmake arguments 21:07 v-rob Would you like me to try this out to get another person's input? For reference, I use Windows + VS and the CMake GUI 21:07 MTDiscord He doesn't because it's documented in the README. 21:08 MTDiscord It's up to you v-rob. 21:09 MTDiscord > standard install path. 21:09 MTDiscord that reads as if it's installing systemwide 21:09 MTDiscord and any power user or sysadmin will be largely suspicious 21:09 MTDiscord explain that /bin will largely contain it within it's own folder 21:10 MTDiscord Thank you. That's useful input. 21:10 MTDiscord i wrote this https://github.com/Aurailus/Zepha/blob/master/docs/Building.md#windows after unscrewing the completely wack cmake 21:12 MTDiscord and yes, cmake doesn't agree with find_package at times either 21:12 MTDiscord v-rob I've heard the CMake GUI has issues with this build process. If I'm writing a solid section in the README knowing more about that might help. 21:12 sfan5 haven't had any issues with msvc 21:14 Pexin I have never heard of "make install" meaning anything except systemwide 21:14 hecks well here it has a magical variable to make it not systemwide... but you can't blame anyone for being suspicious 21:14 hecks or disgusted 21:16 MTDiscord I understand. It could install in a bin/ folder by default but the command would still be suspicious... 21:18 v-rob Well, first off, I have IrrlichtMt cloned to a folder, "irrlicht" and I build to another folder, "irrlicht-build" (which is the same way I build Minetest, which is what the Minetest readme says to do for Windows + VS). In the CMake GUI, I still have the options "IRRLICHT_INCLUDE_DIR" and "IRRLICHT_LIBRARY", but they don't work anymore (as expected). There's also one called "IrrlichtMt_DIR" which is not initialized and doesn't seem to do anything. So, 21:18 v-rob how do I proceed from here? 21:19 sfan5 the only sane option here is to move irrlicht to minetest/lib/irrlichtmt and let the rest happen automatically 21:19 hecks it's not sane because it literally doesn't work for some 21:19 hecks (me) 21:19 v-rob Oh, I'm supposed to put Irrlicht directly into the Minetest folder? 21:20 sfan5 it's not a requirement but it's an easy way of getting this to work 21:20 hecks minetest/lib/irrlichtmt (hardcoded gitignored path) 21:20 hecks prepare for cmake to get really confused though 21:21 v-rob (BTW hecks, IrrlichtMt compiles really fast now :D) 21:21 hecks yes it does... 21:22 hecks it'll be even faster, i need to get back to work 21:23 MTDiscord I technically footshot myself because I installed Irrlicht to root to test it, but my updated install is in ~/.local, so if I forget no point CMake to ~/.local it'll work but be the wrong Irrlicht commit. 21:25 v-rob Ouch, I'd better close some programs. I just got a "compiler out of heap space" error :O 21:25 sfan5 @josiah_wi when/where/how are the Target .cmake files generated? 21:26 MTDiscord It looks like make install generates it because I can't find it in the build tree, but I didn't run "find" so I'm uncertain yet. 21:28 MTDiscord In the CMake lists the install part of it creates an export for the targets that tells which targets to export. The generation of the file is automatic. 21:31 sfan5 hm 21:32 sfan5 that cmake doesn't allow importing a library from a project checkout is unfortunate 21:32 sfan5 when it could easily internally shuffle that stuff around or whatever and do the right thingtm 21:32 sfan5 oh right my compose key doesn't work 21:33 MTDiscord It is unfortunate; that'd be extremely useful. I'm trying to think of a way to hax it in to doing that anyway. 21:34 v-rob MSVC really needs to stop lying that strcpy is deprecated and encouraging me to use its proprietary strcpy_s... 21:34 v-rob Anyhow, the new CMake build system seems to work fine for me. 21:34 v-rob MT built fine and runs fine 21:35 hecks so only osx and mingw got shafted 21:35 v-rob Although, does CMake put IrrlichtMt.dll in bin? I used to have to copy that manually 21:36 MTDiscord Bummer. sfan, it is supported. 21:37 MTDiscord We can export a Targets file with no install. 21:37 MTDiscord Point Minetest to that file and bam. All works without an install. 21:38 sfan5 v-rob: irrlichtmt is statically linked in this case 21:38 v-rob Oh, gotcha 21:38 sfan5 @josiah_wi I don't exact get it yet but please prepare a PR 21:39 MTDiscord https://cmake.org/cmake/help/git-stage/guide/importing-exporting/index.html#exporting-targets-from-the-build-tree 21:39 v-rob Well, for me at least, everything works fine then. It's certainly an improvement for my workflow 21:39 MTDiscord Tutorial in docs. It's a recent version that has the tutorial but it should work in 3.5 (will check though) 21:41 sfan5 lib/irrlichtmt is an earlier change, in theory it could have been fixed to work with MSVC (it always worked on Linux) before and without this change that is causing all the controversy 21:50 sfan5 lib/irrlichtmt is an earlier change, in theory it could have been fixed to work with MSVC (it always worked on Linux) before and without this change that is causing all the controversy 21:50 sfan5 (repost so it doesn't get missed) 21:58 sfan5 mfw clicked add single comment instead of starting a review 21:58 MTDiscord @josiah_wi wat the fak; building with the pseudo install doesn't generate the bad dylib 21:59 MTDiscord even with the PNG library not included 22:01 MTDiscord and what is that segfault 22:02 MTDiscord uh why is loading .x models causing segfaults 22:02 MTDiscord hecks ^ 22:02 MTDiscord Unknown data object in material list in x file: Material zsh: segmentation fault ./Minetest.app/Contents/MacOS/minetest 22:03 MTDiscord devtest boots fine, but other games that use .x don't 22:05 MTDiscord i know this affects your game too hecks 22:05 sfan5 perhaps it doesn't hence it's not been noticed 22:05 MTDiscord his game uses .x like mine 22:06 sfan5 not all files are identical 22:06 MTDiscord mine was made with the ancient 2.7 .x exporter 22:06 MTDiscord his is likely with his variant 22:06 MTDiscord sfan5, running a test build to completion before PRing to make sure it works. Looks good so far. Do you want me to PR a change to Minetest to use an IRRLICHT_DIR variable instead of the magic PREFIX_PATH thingymijig? 22:06 sfan5 no prefix path is okay for installed stuff (the buildbot needs it after all) 22:07 sfan5 but an extra IRRLICHT_SOURCE_DIR is what I'm thinking of 22:07 MTDiscord Sure thing. 22:07 MTDiscord i think the suspect might be in set_attach 22:08 MTDiscord the hint is that it loads non attached models fine 22:08 sfan5 just grepped for some stuff and 22:08 sfan5 src/inventory.cpp: // Obsoleted on 2011-10-14 22:08 sfan5 heh 22:09 hecks sup 22:09 MTDiscord old blender 2.7 .x files seem to segfault 22:09 hecks .x should not cause segfaults.... i just built and ran everything 22:09 hecks maybe it's the old exporter's fault 22:09 MTDiscord https://gist.github.com/Jordach/774a71aa90f7bf381d2b9b03d38519f4 22:09 hecks which section does it fault on? 22:09 MTDiscord i did get a stack trace 22:09 hecks i slightly edited the importer 22:09 MTDiscord irr::scene::CXMeshFileLoader 22:10 hecks yeah obviously 22:10 MTDiscord namely complaining about materials 22:10 MTDiscord lemme upload a gif to show you, as it loads unanimated meshes fine 22:10 MTDiscord (or unattached) 22:10 hecks what would a gif tell me though 22:11 hecks what i deleted from that importer was parsing the actual materials 22:11 hecks since we do not use those 22:11 MTDiscord how else do tyou apply textures 22:12 hecks i 22:12 hecks we still parse material slots 22:12 hecks just not the actual material content 22:12 MTDiscord ah 22:12 hecks and don't load the textures 22:12 MTDiscord i never included textures as i used cycles materials to export under 22:13 MTDiscord because BI / Internal maps to that 22:13 hecks well minetest does not utilize any of that anyway 22:13 hecks you still have to specify the tiles in the cao def 22:13 hecks so all that matters are the slots 22:13 MTDiscord but yes, it explodes: Unknown data object in material list in x file: Material 22:14 hecks hmmm 22:14 MTDiscord just because we bikeshedded a new exporter doesn't mean we shouldn't test with older formatszx 22:14 MTDiscord exports even 22:14 hecks it's not that, the "new" exporter would also do this 22:15 hecks i only ported it 22:15 hecks thing is that i deleted the "texture loader" feature that this depended on 22:15 MTDiscord at least we have a verified sigsegv 22:16 hecks the warning can be suppressed but what's actually causing it to crash? 22:16 MTDiscord it runs to the end of materials then just segfaults 22:16 MTDiscord i could six materials which would match one of the first person attachments 22:17 MTDiscord well count 22:18 MTDiscord that said with all the changes since 5.4 this might as well be called 6.0 22:22 hecks we don't have to do that if we don't break any supported api too hard 22:22 hecks and TGA files did not count as supported =] 22:22 MTDiscord with all the build changes and internal changes leading up to outright replacements? 22:24 hecks i don't know, ask the people who give a damn about semver 22:24 hecks i didn't, i think the 5.0 version inflation was a joke 22:25 MTDiscord irr#49 22:25 ShadowBot https://github.com/minetest/irrlicht/issues/49 -- Export targets to build tree by JosiahWI 22:26 MTDiscord BTW this is usable as soon as it's merged by setting CMAKE_PREFIX_PATH to your Irrlicht source directory. 22:26 MTDiscord No make install anymore. 22:26 MTDiscord also consider writing that into the readme.md 22:26 hecks are the artifacts gitignored properly? 22:27 MTDiscord as this is rather outdated https://github.com/minetest/irrlicht#build 22:27 MTDiscord Artifacts? 22:27 hecks whatever cmake produces 22:27 sfan5 yes? 22:28 sfan5 in general I mean, can't comment on the just linked PR 22:28 MTDiscord ...no the Targets file isn't. Thanks. 22:29 hecks install_manifest.txt also wasn't but i guess it won't be needed now 22:29 MTDiscord Oh, but it goes in build/ which isn't .gitignored. ? 22:29 MTDiscord Advice? 22:29 MTDiscord Oh because I'm using a build directory and some don't. 22:29 MTDiscord Nevermind. 22:34 MTDiscord I fixed the .gitignore. I'm not sure what I should say in the README. 22:34 MTDiscord about the fact it prints things into /build/ for use with minetest's cmake command 22:37 hecks So now you're supposed to point the cmake prefix dir to the checkout? 22:38 MTDiscord reading the commit, It is insecure and inconvenient to necessitate installing IrrlichtMt to access the target export 22:38 MTDiscord Done. Please review. 22:38 MTDiscord basically from what i see all it does is skip the make install step 22:38 MTDiscord Correct. 22:39 MTDiscord I thought that's exactly what you wanted. 22:39 MTDiscord it still places everything within the folder providing /bin/ 22:39 hecks now how will it cope with the fact that the /include/ and /lib/ structure is not the same as the installed one? 22:39 MTDiscord No Jordach, it uses the build tree now. 22:39 hecks /include/irrlichtmt became just /include/, while /lib/ became /lib/[system]/ 22:40 MTDiscord Hecks, those paths are completely flexible. 22:40 hecks we shall see... 22:40 MTDiscord I did just test it. 22:40 MTDiscord hecks: prefix was set to =/bin 22:40 MTDiscord https://gist.github.com/Jordach/753e6dde979f2ca7c1f3ffa56e2f2fba 22:40 MTDiscord entire log 22:41 MTDiscord The Targets file knows where the library and headers are located. It grabs them straight from the build tree. 22:42 MTDiscord It's a testament to how good the Irrlicht build is that I didn't have to modify a single path. I actually thought I might have to. 22:42 hecks okay, the targets file is generated correctly 22:42 hecks wait, uh oh 22:43 hecks it's looking for IrrlichtMtConfig.cmake in the wrong dir now 22:44 MTDiscord Did you set CMAKE_PREFIX_PATH to your irrlicht checkout? Even if you did it might fail and I understand why. 22:44 hecks of course, now what 22:44 hecks it's looking for the file in one dir above 22:45 MTDiscord Probably have to PR to Minetest to fix that. I use an out of source build which works but many Minetest devs do not. 22:46 hecks uhhhh wait.... 22:46 MTDiscord I should update the docs. 22:48 MTDiscord Updated. 22:49 hecks i cleaned everything and tried again and now it's 22:49 MTDiscord Oh. Whups. 22:49 MTDiscord Time to revert. 22:49 hecks there's a duplicate IrrlichtMtConfig in the root folder which can't find IrrlichtMtTargets 22:50 hecks in the checkout 22:50 hecks when i deleted that it worked 22:52 MTDiscord Ok. I think this is good for final review then. 22:53 MTDiscord I should've done this in the first place, or rather researched whether it was possible. I'm relieved I did learn something from this experience. 22:54 MTDiscord i want minetest to be wholly much better when it comes to user experience 22:54 MTDiscord that cannot be possible without holding contributors to standards 22:54 MTDiscord which includes documentation for users who may be first time 22:55 sfan5 I reviewed a PR 22:55 sfan5 time to go to bed 22:55 MTDiscord Well, thank you for holding me to the standard, but this could've been done hours ago if we'd discussed solutions instead of arguing about the problem. 22:55 hecks well it works now, it's just slightly fishy (abusing a generic path prefix) 22:55 MTDiscord the lack of documentation was the problem 22:55 MTDiscord it didn't explain what it was attempting 22:55 hecks if this was an irrlicht specific variable again it would be good 22:56 MTDiscord and given anyone with an experience with a computer, installation means administrative rights 22:56 hecks but we will never ever use this mechanism again, i'll make sure of it, so that might be moot 22:56 MTDiscord Yes hecks, I'll be PRing that but I don't have time this afternoon as it's getting late and I'm tired. 22:57 hecks now back to the broken .x files 22:58 hecks i could monkey patch that by parsing the material blocks again but 22:58 hecks we literally won't have an SMaterial type soon 22:58 MTDiscord i'd rather it just silently fail or discard the data 22:58 MTDiscord or at least leave a warning in the console to use the newer exporter 22:59 hecks does a newer exporter fix it? 22:59 MTDiscord your one might 22:59 hecks i wouldn't know because i actually strip that block from my files 22:59 MTDiscord not tested it 23:00 hecks but that's not something done by the blender exporter i posted 23:00 MTDiscord suprised you didn;t intergrate that with the updated exporter 23:00 hecks that one is just the 2.7x version updated for the 2.80 depsgraph 23:00 hecks i did not integrate it because that exporter is cancer 23:00 MTDiscord fair 23:00 hecks i don't even use it anymore 23:01 hecks i export lsd, parse it, process it, and write back an .x in lua 23:01 sfan5 fyi having to reexport models does not match minetest's usual compatibility strategy 23:01 MTDiscord yes 23:02 sfan5 now this is a first because irrlicht code has never really seen changes before 23:02 hecks it's a bug, i'll fix it 23:02 MTDiscord that actually would be very annoying 23:02 MTDiscord thanks hecks 23:02 sfan5 but we have to think about it before 5.5 or face complains that N-year old mods no longer work 23:02 * sfan5 now actually off 23:02 MTDiscord other than MCL 23:02 MTDiscord lmao 23:02 hecks aren't we the only .x users 23:02 MTDiscord yes 23:04 hecks MCL... what's that again? 23:04 MTDiscord the most idiotic thing to make with the engine 23:04 hecks literally minecraft? 23:06 MTDiscord yes 23:06 MTDiscord so many interesting topics and they choose that 23:06 hecks so that's where all the stupid feature requests come from 23:06 MTDiscord yeeep 23:07 hecks 'can we have this, minecraft has this, please hardcode this we need this' 23:07 sfan5 that's rare(er) 23:07 sfan5 I'd say most raised in connection to mcl actually show lack of flexibility in the engine 23:07 sfan5 though the proposed solutions aren't always good 23:08 hecks i vaguely remember some requests literally asking to hardcode something 23:08 hecks or really close 23:08 sfan5 when you said hardcoding I was thinking of the dual wielding PR 23:08 sfan5 or in other words hardcoding a second hand 23:08 hecks :DDDD yes that one 23:08 hecks that's a prime example of minecraft myopia 23:09 hecks viewmodels? no second HAND :DDDD 23:09 hecks or this uhhh 23:09 MTDiscord honestly viewmodels would be rather lit 23:09 hecks yes they would 23:09 MTDiscord as long as they had entity like controls 23:09 hecks but instead of viewmodels someone just suggested a second hand, without figuring out how exactly this would logically work 23:09 hecks didn't they suggest a hardcoded inventory cell for it? 23:09 sfan5 there's so many easy targets of hardcoded stuff that can be unhardcoded + nice API 23:10 sfan5 someone just needs to do it 23:10 MTDiscord i actually have a way to sort of hack in dual wielding 23:10 hecks i literally have a second hand in the game... it just doesn't have a first person representation 23:10 MTDiscord exactly 23:10 hecks though with that new CAO flag or whatever that was, it might work 23:11 hecks viewmodels aren't hard, i just have more important things to do 23:28 hecks irr#50 Jordach 23:28 ShadowBot https://github.com/minetest/irrlicht/issues/50 -- Fix .x material slot parsing by hecktest 23:28 hecks try this 23:28 MTDiscord one min king 23:29 hecks i can't actually test out an unoptimized .x file at the moment because uh for one i straight up don't have the pipeline for these now 23:29 hecks and second, any of my models exported as unoptimized .x would not fit within the 8 meg limit 23:30 MTDiscord reconstructing 23:33 MTDiscord halfway there 23:36 MTDiscord loads but segfaults when checking for normals 23:36 MTDiscord 0 net.minetest.minetest checkMeshNormals(irr::scene::IMesh*) + 96 23:36 MTDiscord i see a frame of the attachments before it segfaults 23:37 MTDiscord ...now it works? 23:39 MTDiscord seems to be kind of intermittent 23:39 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/870088105259061258/Screenshot_2021-07-29_at_00.38.45.png 23:40 MTDiscord curious 23:40 MTDiscord it happened against after starting a game, exiting to menu, then starting a new game 23:41 MTDiscord hecks: checkMeshNormals(irr::scene::IMesh*) 23:41 MTDiscord seems to be where the fault lies 23:41 hecks hmmmmmmm 23:41 hecks so it no longer dies in the parser, it's just malformed now 23:41 MTDiscord lemme check 23:41 MTDiscord if it's one model 23:41 hecks and if it's random, it's something uninitialized 23:42 MTDiscord nope it's just that one model 23:42 MTDiscord memory leak spotted 23:43 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/870089006703050752/Screenshot_2021-07-29_at_00.42.36.png 23:43 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/870089011945959444/Screenshot_2021-07-29_at_00.42.39.png 23:43 hecks :DDDDD oops 23:44 MTDiscord system didn't panic so it's all good 23:44 MTDiscord one model explicitly explods 23:44 MTDiscord https://raw.githubusercontent.com/Dumpster-Studios/BattleForArkhos/fps_game/mods/weapons/models/arms_shotgun.x shits the bed 23:45 MTDiscord https://raw.githubusercontent.com/Dumpster-Studios/BattleForArkhos/fps_game/mods/weapons/models/arms_spnkrx.x doesn't 23:50 hecks sure is a lot of materials 23:50 MTDiscord i'm doing a more unique method of texturing 23:51 MTDiscord by having infinitely tileable textures 23:51 hecks be aware that this increases drawcalls 23:51 MTDiscord breathing in minetest increases drawcalls 23:51 MTDiscord what else isn't new 23:51 hecks i'm just sayin 23:52 MTDiscord i tend to use not many]