| Time |
Nick |
Message |
| 00:19 |
|
specing_ joined #minetest-dev |
| 00:21 |
|
Extex joined #minetest-dev |
| 00:22 |
MTDiscord |
<Jordach> sfan5 reverting that cmake pr might be required |
| 00:23 |
MTDiscord |
<Jordach> yes lets remove linking against macOS system libraries required for windowing and input that certainly can't go wrong |
| 00:26 |
|
v-rob joined #minetest-dev |
| 00:26 |
|
YuGiOhJCJ joined #minetest-dev |
| 00:28 |
MTDiscord |
<Jordach> also, removing of -DIRRLICHT_INCLUDE_DIR and -DIRRLICHT_LIBRARY is quite possibly the most incompetant move possible |
| 00:28 |
MTDiscord |
<Jordach> cmake prefix is not intelligent |
| 01:02 |
|
sofar joined #minetest-dev |
| 01:10 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> nope |
| 01:15 |
MTDiscord |
<Jordach> (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 |
<Jordach> 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 |
<Jordach> no |
| 01:18 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> (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 |
<Jordach> the GPU driver won't support it |
| 01:22 |
MTDiscord |
<Jordach> see: https://developer.apple.com/opengl/OpenGL-Capabilities-Tables.pdf |
| 01:22 |
hecks |
i have that open already |
| 01:22 |
MTDiscord |
<Jordach> 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 |
<Jordach> but pretty much all of the macs from 2009+ will likely run 3.3 without issues |
| 01:23 |
MTDiscord |
<Jordach> 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 |
<Jordach> 2.1 is the lowest and yes |
| 01:24 |
MTDiscord |
<Jordach> 2.1 is the default context |
| 01:24 |
hecks |
that'll do really |
| 01:24 |
MTDiscord |
<Jordach> for any OpenGL that doesn't use a core profile |
| 01:24 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> oh, Radeon HD 2400 was released in 2008 |
| 01:26 |
hecks |
first gl3 card? |
| 01:26 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> 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 |
| 02:27 |
|
sofar joined #minetest-dev |
| 03:08 |
|
v-rob joined #minetest-dev |
| 04:05 |
|
v-rob joined #minetest-dev |
| 05:29 |
|
v-rob joined #minetest-dev |
| 06:09 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:55 |
|
nrz joined #minetest-dev |
| 07:39 |
|
entuland joined #minetest-dev |
| 07:50 |
sfan5 |
<hecks> 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? |
| 09:43 |
|
calcul0n_ joined #minetest-dev |
| 10:51 |
|
nrz joined #minetest-dev |
| 12:22 |
|
specing_ joined #minetest-dev |
| 13:25 |
|
hecks joined #minetest-dev |
| 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 |
| 14:17 |
|
Fixer joined #minetest-dev |
| 15:51 |
|
Extex joined #minetest-dev |
| 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 |
<josiah_wi> The README still lists the IRRLICHT_LIBRARY etc. variables under the options header. |
| 16:15 |
MTDiscord |
<josiah_wi> 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 |
<Sublayer plank> well, there were some changes to that |
| 16:26 |
MTDiscord |
<Jordach> $25 to whoever reverts that PR |
| 16:27 |
hecks |
the directory variable names have not changed |
| 16:27 |
MTDiscord |
<Sublayer plank> 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 |
<Jordach> Because it needs to be installed as a systemwide package |
| 16:27 |
MTDiscord |
<y5nw> 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 |
<Jordach> You’re a core dev revert it |
| 16:28 |
MTDiscord |
<Sublayer plank> it doesn't need to be installed as a systemwide package, what are you talking about |
| 16:28 |
MTDiscord |
<Jordach> make install always implies systemwide install on UNIX |
| 16:28 |
MTDiscord |
<Sublayer plank> 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 |
<Jordach> Basically it expects you to use cmakes package finding subsystem |
| 16:29 |
MTDiscord |
<Jordach> Which is absolute garbage |
| 16:29 |
hecks |
:DDDD |
| 16:29 |
hecks |
peak unix |
| 16:29 |
MTDiscord |
<Jordach> On exotic systems that use MSVC or macOS Xcode |
| 16:29 |
hecks |
when are we switching to hardcoded paths |
| 16:30 |
MTDiscord |
<Jordach> It’s what I was using before the PR |
| 16:30 |
MTDiscord |
<Jordach> Why remove the one thing that doesn’t break on exotic config a |
| 16:30 |
MTDiscord |
<Jordach> 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 |
<Jordach> If DIRRLICHT_LIBRARY was specified then ignore CMakes find package |
| 16:32 |
MTDiscord |
<Jordach> It’s that simple |
| 16:32 |
hecks |
that's how it used to work |
| 16:32 |
MTDiscord |
<Jordach> Except now it requires irrlicht to be make installed post compilation |
| 16:32 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Sublayer plank> 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 |
<Sublayer plank> I've done symlinks on windows across partitions, it's worked with no issues |
| 16:44 |
MTDiscord |
<Benrob0329> 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 |
<Sublayer plank> 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 |
<sfan5> you do not need to install system-wide. |
| 16:47 |
sfan5 |
maybe I shouldn't put it in bold |
| 16:47 |
MTDiscord |
<josiah_wi> 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 |
<Benrob0329> 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 |
<josiah_wi> 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 |
<Benrob0329> Fair |
| 16:50 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<Sublayer plank> 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 |
<Jordach> Not at alp |
| 17:12 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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:49 |
|
hecks joined #minetest-dev |
| 17:51 |
MTDiscord |
<josiah_wi> 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 |
<GreenXenith> Do I have this right that we now have to install irrlicht system wide to compile Minetest? |
| 17:52 |
MTDiscord |
<josiah_wi> use -> understand*. Stupid autocorrect. |
| 17:52 |
MTDiscord |
<Sublayer plank> we don't have to |
| 17:52 |
hecks |
either install it system wide or fool cmake into thinking you did |
| 17:52 |
MTDiscord |
<Sublayer plank> if you put it in lib/irrlichtmt |
| 17:53 |
MTDiscord |
<GreenXenith> Thats system wide buddy |
| 17:53 |
hecks |
but.... that's basically installing systemwide :DDDD |
| 17:53 |
MTDiscord |
<Sublayer plank> what |
| 17:53 |
MTDiscord |
<GreenXenith> So the answer is yes |
| 17:53 |
hecks |
linux users... |
| 17:53 |
MTDiscord |
<GreenXenith> Hey, don't blame us all |
| 17:53 |
MTDiscord |
<josiah_wi> Hang on, we should be able to hax Irrlicht into working with no install. |
| 17:53 |
MTDiscord |
<Sublayer plank> I'm talking about putting the cloned irrlicht repo into lib/irrlichtmt in the cloned minetest repo |
| 17:53 |
MTDiscord |
<josiah_wi> The build tree can be the install tree. |
| 17:53 |
MTDiscord |
<GreenXenith> I'm a Linux user and I think this change is stupid |
| 17:53 |
MTDiscord |
<Sublayer plank> 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 |
<Jordach> The moment you put shit into your path environment is the moment it’s considered installed |
| 17:54 |
MTDiscord |
<Jordach> 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 |
<josiah_wi> Doesn't need to be in PATH to work. |
| 17:55 |
MTDiscord |
<Jordach> Is this officially documented |
| 17:55 |
MTDiscord |
<GreenXenith> What was this change intended to fix? |
| 17:55 |
MTDiscord |
<Sublayer plank> 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 |
<Jordach> Nice directory |
| 17:56 |
MTDiscord |
<josiah_wi> The change was intended to make the build process more automatic for people who were having trouble with the variables. |
| 17:56 |
MTDiscord |
<Jordach> I bet that isn’t even documented |
| 17:56 |
MTDiscord |
<Sublayer plank> 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 |
<Sublayer plank> the lib/irrlichtmt thing has existed for a month now |
| 17:56 |
MTDiscord |
<GreenXenith> Are we talking about minetest/lib/irrlichtmt or /lib/irrlichtmt |
| 17:57 |
MTDiscord |
<Sublayer plank> minetest/lib/irrlichtmt |
| 17:57 |
MTDiscord |
<GreenXenith> That makes more sense |
| 17:57 |
MTDiscord |
<Sublayer plank> https://github.com/minetest/minetest/commit/fa4dee0e62dcf2bbfb68b17cf97e438eab58be93 |
| 17:57 |
MTDiscord |
<Sublayer plank> this was a month ago |
| 17:57 |
MTDiscord |
<Sublayer plank> and it is in fact documented |
| 17:57 |
MTDiscord |
<GreenXenith> I still think we should be able to use the old variables, but mt/lib seems acceptable if it works |
| 17:58 |
MTDiscord |
<Jordach> 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 |
<josiah_wi> I could be wrong but I think lib/irrlicht was exempted from install. |
| 18:00 |
MTDiscord |
<GreenXenith> Meaning? |
| 18:01 |
MTDiscord |
<josiah_wi> Meaning CPackInstall will not "copy that garbage in" |
| 18:01 |
sfan5 |
lib/irrlichtmt is gitignored yes |
| 18:02 |
MTDiscord |
<josiah_wi> How does CPack RUN_IN_PLACE=FALSE work with lib/irrlichtmt as a dynamic library? |
| 18:03 |
MTDiscord |
<josiah_wi> Does it break the package? |
| 18:03 |
MTDiscord |
<Jordach> Mac static links by default |
| 18:03 |
sfan5 |
with lib/irrlichtmt it's never dynamically linked |
| 18:03 |
MTDiscord |
<Jordach> Ie instead of dyld files strewn about the app it’s all built into the resultant Minetest binary |
| 18:03 |
MTDiscord |
<josiah_wi> Phew. |
| 18:04 |
MTDiscord |
<Jordach> 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 |
<josiah_wi> People clone Minetest multiple times? I always use branches and I have about 5 build directories. |
| 18:08 |
MTDiscord |
<Warr1024> 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 |
<josiah_wi> 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 |
<Warr1024> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> The path works hecks. It's a version error. |
| 18:20 |
hecks |
it's the version from the buildbot...... |
| 18:20 |
MTDiscord |
<josiah_wi> 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 |
|
Extex joined #minetest-dev |
| 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 |
|
longerstaff13 joined #minetest-dev |
| 18:22 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> The buildbot doesn't try to build with Irrlicht in lib/irrlichtmt. |
| 18:24 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> If my hypothesis is correct then yes. |
| 18:27 |
hecks |
dcmake_prefix_path right? |
| 18:27 |
sfan5 |
yea |
| 18:27 |
MTDiscord |
<josiah_wi> But that's a hacky workaround, not a solution, and we haven't even determined the precise cause. |
| 18:28 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> Putting all the DLLs there? No. |
| 18:29 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> Irrlicht probably needs to be built first with mingw and then linked. :| |
| 18:34 |
sfan5 |
wat |
| 18:34 |
hecks |
uhhhhhhhhh |
| 18:34 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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:39 |
|
v-rob joined #minetest-dev |
| 18:41 |
sfan5 |
I have no idea at this point |
| 18:46 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> The structure of the install tree for a "fake root" can be arbitrary. |
| 19:07 |
MTDiscord |
<josiah_wi> 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 |
<Jordach> ln -s /Users/Jordach/testfolder2/irrlicht /Users/Jordach/testfolder2/minetest/lib/irrlichtmt |
| 19:44 |
MTDiscord |
<Jordach> this works for me |
| 19:44 |
MTDiscord |
<Jordach> good fucking show @josiah_wi |
| 19:45 |
MTDiscord |
<Jordach> you just broke codesigning |
| 19:45 |
celeron55 |
don't get so personal, it's just the cmake way of breaking stuff |
| 19:45 |
MTDiscord |
<Jordach> it's not CMake |
| 19:46 |
MTDiscord |
<Jordach> since minetest doesn't link to libpng anymore |
| 19:46 |
MTDiscord |
<Jordach> while irrlicht does causes it to half static-link minetest and half dynamic like |
| 19:46 |
MTDiscord |
<Jordach> link, which causes the mac kernel to shit the bed |
| 19:46 |
MTDiscord |
<Jordach> (by extension probably BSD) |
| 19:49 |
hecks |
-- Installing: ../libs/irrmt/usr/local/include/irrlichtmt/SSharedMeshBuffer.h |
| 19:49 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> that should theoretically patch macOS |
| 19:59 |
MTDiscord |
<Jordach> 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 |
<josiah_wi> 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 |
<Warr1024> 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 |
<josiah_wi> 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 |
<Warr1024> 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 |
<Jordach> if i can fix a horrifying cmake setup that only works on one machine and introduce support for vcpkg |
| 20:09 |
MTDiscord |
<Jordach> 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 |
<Jordach> ??? |
| 20:11 |
MTDiscord |
<Jordach> >removes cmakecache to force regeneration of files |
| 20:11 |
hecks |
done already |
| 20:11 |
MTDiscord |
<Jordach> >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 |
<josiah_wi> 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 |
<Jordach> using stackoverflow as a hammer to fix nails is a very bad idea™️ |
| 20:17 |
MTDiscord |
<Jordach> 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 |
<Jordach> no it's a cock up that makes the british government look functional |
| 20:19 |
MTDiscord |
<Jordach> warning: changes being made to the file will invalidate the code signature in: |
| 20:19 |
MTDiscord |
<Jordach> it's not static linking |
| 20:19 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> This is not how progress is made. |
| 20:19 |
MTDiscord |
<Jordach> 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 |
<Jordach> what we had was human understandable and god forbid |
| 20:22 |
MTDiscord |
<Jordach> 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 |
<Jordach> we've reverted worse stuff for less |
| 20:25 |
MTDiscord |
<josiah_wi> 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 |
<Jordach> i'm now hacking and chopping away at the cmake |
| 20:25 |
MTDiscord |
<Jordach> because before even with your irrlicht changes it was fine |
| 20:26 |
MTDiscord |
<josiah_wi> Ironically most of the magic happens on the Irrlicht side. |
| 20:26 |
MTDiscord |
<Jordach> it's the crap job done to CMakeLists |
| 20:26 |
MTDiscord |
<Jordach> 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 |
<Jordach> i stuffed irrmt into /libs/irrlichtmt |
| 20:27 |
MTDiscord |
<Jordach> 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 |
<Jordach> the correct result is that all libraries staticly link |
| 20:29 |
MTDiscord |
<Jordach> and have zero dylib files inside the app |
| 20:30 |
hecks |
wow finally |
| 20:30 |
MTDiscord |
<josiah_wi> 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 |
<Jordach> that was because minetest needs to depend on it from generating a linked library to a linked lib |
| 20:31 |
MTDiscord |
<Jordach> this prevents that entire scenario |
| 20:32 |
sfan5 |
does it? |
| 20:32 |
MTDiscord |
<Jordach> building MT with brew caused dylibs to lose their code signatures |
| 20:32 |
MTDiscord |
<Jordach> i've had to build every MT dependancy manually |
| 20:36 |
MTDiscord |
<Jordach> > cmake . -DRUN_IN_PLACE=FALSE -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" -DBUILD_SHARED_LIBS=FALSE |
| 20:36 |
MTDiscord |
<josiah_wi> 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 |
<Jordach> still generates a libpng dyld |
| 20:36 |
sfan5 |
minetest does not build libpng so it does not "generate" the .dylib |
| 20:36 |
MTDiscord |
<josiah_wi> Aren't you building libpng yourself? |
| 20:36 |
sfan5 |
rather it's probably picking it |
| 20:36 |
MTDiscord |
<Jordach> it's already compiled locally |
| 20:36 |
sfan5 |
so you should point it to the libpng.a |
| 20:37 |
MTDiscord |
<josiah_wi> ^ |
| 20:37 |
MTDiscord |
<Jordach> i've also stripped the offending ARM NEON nonsense from it |
| 20:38 |
MTDiscord |
<josiah_wi> 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 |
<Jordach> full clean rebuild time |
| 20:40 |
MTDiscord |
<josiah_wi> You're going to need to set the paths to your static dependencies (e.g. libpng.a) in any event. |
| 20:40 |
MTDiscord |
<Jordach> this was with src/CMakeLists.txt changes to ensure png is properly linked |
| 20:40 |
MTDiscord |
<Jordach> this test is without |
| 20:41 |
MTDiscord |
<josiah_wi> You added it without even testing the original? |
| 20:41 |
MTDiscord |
<Jordach> known working state first |
| 20:41 |
MTDiscord |
<Jordach> then play with it |
| 20:42 |
MTDiscord |
<Jordach> same result |
| 20:42 |
|
Extex joined #minetest-dev |
| 20:42 |
MTDiscord |
<josiah_wi> I actually highly recommend compiling irrlicht in a seperate directory. |
| 20:43 |
MTDiscord |
<Jordach> > Minetest.app/Contents/MacOS/minetest: Mach-O universal binary with 2 architectures: x86_64:Mach-O 64-bit executable x86_64 |
| 20:43 |
MTDiscord |
<josiah_wi> Did you try the script I modified for you? |
| 20:43 |
MTDiscord |
<Jordach> i don't make unknown changes to scripts without testing in a sandbox env first |
| 20:43 |
MTDiscord |
<Jordach> i'm not going to YOLO existing builds into the void |
| 20:43 |
MTDiscord |
<josiah_wi> The recommendation isn't for general usecase btw, just for this. |
| 20:44 |
MTDiscord |
<Jordach> my build argument looks more like |
| 20:44 |
MTDiscord |
<Jordach> 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 |
<josiah_wi> 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 |
<Jordach> i distrust other's changes for sanity |
| 20:45 |
MTDiscord |
<Jordach> the last time that happened rm and -rf were very good friends with * |
| 20:45 |
MTDiscord |
<josiah_wi> I hardly changed much. You could easily check what it does. |
| 20:47 |
MTDiscord |
<josiah_wi> 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 |
<Jordach> i can now safely test that it does build |
| 20:48 |
MTDiscord |
<Jordach> it does not mean however it's safe to use |
| 20:48 |
MTDiscord |
<Jordach> as MSVC needs checking |
| 20:49 |
MTDiscord |
<josiah_wi> I have a fear that I was ignorant and removed the PNG thing, but I will check that now. |
| 20:50 |
MTDiscord |
<Jordach> potentially |
| 20:50 |
MTDiscord |
<josiah_wi> My fear was unfounded; it's there where it should be. |
| 20:51 |
MTDiscord |
<Jordach> i never made a single PR to minetest without triple checking things work as expected |
| 20:51 |
MTDiscord |
<Jordach> set_sky went through a ton of personal scrutiny |
| 20:52 |
MTDiscord |
<josiah_wi> 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 |
<Jordach> OpenCore exists |
| 20:52 |
MTDiscord |
<Jordach> you can easily test with a VM under VESA drivers |
| 20:53 |
MTDiscord |
<Jordach> but because i'm effectively the Mac maintainer |
| 20:53 |
MTDiscord |
<Jordach> also |
| 20:53 |
MTDiscord |
<Jordach> running your modified irrlicht command didn't generate them right |
| 20:54 |
MTDiscord |
<Jordach> it didn't fix irrlicht being wrong |
| 20:54 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> Let's not forget I reached out to Jordach before PRing this to get his input. |
| 20:54 |
MTDiscord |
<Jordach> it shat the .a out in /lib/OSX/libIrrlichtMt.a |
| 20:55 |
MTDiscord |
<josiah_wi> Ok so? |
| 20:55 |
MTDiscord |
<Jordach> two months ago in PR hell |
| 20:55 |
MTDiscord |
<josiah_wi> It shouldn't have put it in /lib. I'll recheck the script. |
| 20:56 |
MTDiscord |
<Jordach> i'm not pasting the command as it's nearly six years long |
| 20:56 |
MTDiscord |
<Jordach> https://gist.github.com/Jordach/860ea57263c28c0755ef32cf222e6b28 |
| 20:57 |
MTDiscord |
<josiah_wi> Ok, so it built. |
| 20:57 |
MTDiscord |
<josiah_wi> What's the problem? |
| 20:57 |
MTDiscord |
<Jordach> builds fine, doesn't spew the things in the right places |
| 20:57 |
MTDiscord |
<Jordach> otherwise cmake won't find it |
| 20:57 |
MTDiscord |
<Jordach> which is exactly the problem hecks is havinfg |
| 20:58 |
MTDiscord |
<josiah_wi> 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 |
<Jordach> you think i want to shit up my path |
| 20:58 |
MTDiscord |
<Jordach> no |
| 20:58 |
MTDiscord |
<josiah_wi> It just puts it in a bin/ folder. |
| 20:58 |
MTDiscord |
<josiah_wi> irrlicht/bin |
| 20:59 |
MTDiscord |
<Jordach> and i have to run that on every irrlicht change |
| 20:59 |
MTDiscord |
<josiah_wi> 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 |
<Jordach> why does it even need to bother with any other directory outside of lib |
| 21:00 |
MTDiscord |
<josiah_wi> It doesn't. |
| 21:00 |
MTDiscord |
<Jordach> APFS doesn't support symlinks |
| 21:00 |
MTDiscord |
<josiah_wi> make install can keep everything in your dev directory. |
| 21:00 |
MTDiscord |
<josiah_wi> No need to symlink. |
| 21:00 |
MTDiscord |
<josiah_wi> 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 |
<Jordach> and this is exactly why i don't want to run his scripts without sandboxed testing |
| 21:03 |
MTDiscord |
<Jordach> i've been bit before by bad bash scripts |
| 21:03 |
MTDiscord |
<josiah_wi> I just modified yours slightly though. |
| 21:03 |
sfan5 |
could pass the old and the new variables at the same time |
| 21:03 |
MTDiscord |
<Jordach> you missed certain things entirely lmao |
| 21:03 |
MTDiscord |
<Jordach> x64 contains a different build argument to arm64 |
| 21:04 |
MTDiscord |
<josiah_wi> I can see myself missing that. |
| 21:04 |
|
hecks left #minetest-dev |
| 21:04 |
|
hecks joined #minetest-dev |
| 21:04 |
MTDiscord |
<josiah_wi> That's why I showed you the script early on for review e |
| 21:04 |
MTDiscord |
<Jordach> and this is why i basically have a notepad open at all times for note taking of interesting behaviors |
| 21:04 |
MTDiscord |
<Jordach> sometimes it'll be there when you're scratching your head |
| 21:04 |
MTDiscord |
<josiah_wi> I'm trying to work with you and you've done absolutely nothing to work with you. |
| 21:04 |
MTDiscord |
<josiah_wi> to work with me* |
| 21:05 |
sfan5 |
I don't think whatever you guys are doing is going anywhere |
| 21:05 |
MTDiscord |
<josiah_wi> Yeah obviously. :| |
| 21:06 |
MTDiscord |
<josiah_wi> It's just Jordach explaining to me why he's mad at me or something like that. |
| 21:06 |
MTDiscord |
<Jordach> i'm not seeing where cmake_install_prefix is even used in irrlicht's cmakelists |
| 21:07 |
MTDiscord |
<josiah_wi> It's built in to CMake. I honestly shouldn't have hijacked it for this but I did. |
| 21:07 |
MTDiscord |
<Jordach> 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 |
<josiah_wi> He doesn't because it's documented in the README. |
| 21:08 |
MTDiscord |
<josiah_wi> It's up to you v-rob. |
| 21:09 |
MTDiscord |
<Jordach> > standard install path. |
| 21:09 |
MTDiscord |
<Jordach> that reads as if it's installing systemwide |
| 21:09 |
MTDiscord |
<Jordach> and any power user or sysadmin will be largely suspicious |
| 21:09 |
MTDiscord |
<Jordach> explain that /bin will largely contain it within it's own folder |
| 21:10 |
MTDiscord |
<josiah_wi> Thank you. That's useful input. |
| 21:10 |
MTDiscord |
<Jordach> i wrote this https://github.com/Aurailus/Zepha/blob/master/docs/Building.md#windows after unscrewing the completely wack cmake |
| 21:12 |
MTDiscord |
<Jordach> and yes, cmake doesn't agree with find_package at times either |
| 21:12 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
|
entuland joined #minetest-dev |
| 21:23 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> Bummer. sfan, it is supported. |
| 21:37 |
MTDiscord |
<josiah_wi> We can export a Targets file with no install. |
| 21:37 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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:41 |
|
hecks joined #minetest-dev |
| 21:45 |
|
calcul0n joined #minetest-dev |
| 21:49 |
|
v-rob joined #minetest-dev |
| 21:50 |
sfan5 |
<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 |
<Jordach> @josiah_wi wat the fak; building with the pseudo install doesn't generate the bad dylib |
| 21:58 |
|
Extex joined #minetest-dev |
| 21:59 |
MTDiscord |
<Jordach> even with the PNG library not included |
| 22:01 |
MTDiscord |
<Jordach> and what is that segfault |
| 22:02 |
MTDiscord |
<Jordach> uh why is loading .x models causing segfaults |
| 22:02 |
MTDiscord |
<Jordach> hecks ^ |
| 22:02 |
MTDiscord |
<Jordach> Unknown data object in material list in x file: Material zsh: segmentation fault ./Minetest.app/Contents/MacOS/minetest |
| 22:03 |
MTDiscord |
<Jordach> devtest boots fine, but other games that use .x don't |
| 22:05 |
MTDiscord |
<Jordach> i know this affects your game too hecks |
| 22:05 |
sfan5 |
perhaps it doesn't hence it's not been noticed |
| 22:05 |
MTDiscord |
<Jordach> his game uses .x like mine |
| 22:06 |
sfan5 |
not all files are identical |
| 22:06 |
MTDiscord |
<Jordach> mine was made with the ancient 2.7 .x exporter |
| 22:06 |
MTDiscord |
<Jordach> his is likely with his variant |
| 22:06 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> Sure thing. |
| 22:07 |
MTDiscord |
<Jordach> i think the suspect might be in set_attach |
| 22:08 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> https://gist.github.com/Jordach/774a71aa90f7bf381d2b9b03d38519f4 |
| 22:09 |
hecks |
which section does it fault on? |
| 22:09 |
MTDiscord |
<Jordach> i did get a stack trace |
| 22:09 |
hecks |
i slightly edited the importer |
| 22:09 |
MTDiscord |
<Jordach> irr::scene::CXMeshFileLoader |
| 22:10 |
hecks |
yeah obviously |
| 22:10 |
MTDiscord |
<Jordach> namely complaining about materials |
| 22:10 |
MTDiscord |
<Jordach> lemme upload a gif to show you, as it loads unanimated meshes fine |
| 22:10 |
MTDiscord |
<Jordach> (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 |
<Jordach> 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 |
<Jordach> ah |
| 22:12 |
hecks |
and don't load the textures |
| 22:12 |
MTDiscord |
<Jordach> i never included textures as i used cycles materials to export under |
| 22:13 |
MTDiscord |
<Jordach> 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 |
<Jordach> but yes, it explodes: Unknown data object in material list in x file: Material |
| 22:14 |
hecks |
hmmm |
| 22:14 |
MTDiscord |
<Jordach> just because we bikeshedded a new exporter doesn't mean we shouldn't test with older formatszx |
| 22:14 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> it runs to the end of materials then just segfaults |
| 22:16 |
MTDiscord |
<Jordach> i could six materials which would match one of the first person attachments |
| 22:17 |
MTDiscord |
<Jordach> well count |
| 22:18 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<josiah_wi> irr#49 |
| 22:25 |
ShadowBot |
https://github.com/minetest/irrlicht/issues/49 -- Export targets to build tree by JosiahWI |
| 22:26 |
MTDiscord |
<josiah_wi> BTW this is usable as soon as it's merged by setting CMAKE_PREFIX_PATH to your Irrlicht source directory. |
| 22:26 |
MTDiscord |
<josiah_wi> No make install anymore. |
| 22:26 |
MTDiscord |
<Jordach> also consider writing that into the readme.md |
| 22:26 |
hecks |
are the artifacts gitignored properly? |
| 22:27 |
MTDiscord |
<Jordach> as this is rather outdated https://github.com/minetest/irrlicht#build |
| 22:27 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> ...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 |
<josiah_wi> Oh, but it goes in build/ which isn't .gitignored. ? |
| 22:29 |
MTDiscord |
<josiah_wi> Advice? |
| 22:29 |
MTDiscord |
<josiah_wi> Oh because I'm using a build directory and some don't. |
| 22:29 |
MTDiscord |
<josiah_wi> Nevermind. |
| 22:34 |
MTDiscord |
<josiah_wi> I fixed the .gitignore. I'm not sure what I should say in the README. |
| 22:34 |
MTDiscord |
<Jordach> 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 |
<Jordach> reading the commit, It is insecure and inconvenient to necessitate installing IrrlichtMt to access the target export |
| 22:38 |
MTDiscord |
<josiah_wi> Done. Please review. |
| 22:38 |
MTDiscord |
<Jordach> basically from what i see all it does is skip the make install step |
| 22:38 |
MTDiscord |
<josiah_wi> Correct. |
| 22:39 |
MTDiscord |
<josiah_wi> I thought that's exactly what you wanted. |
| 22:39 |
MTDiscord |
<Jordach> 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 |
<josiah_wi> No Jordach, it uses the build tree now. |
| 22:39 |
hecks |
/include/irrlichtmt became just /include/, while /lib/ became /lib/[system]/ |
| 22:40 |
MTDiscord |
<josiah_wi> Hecks, those paths are completely flexible. |
| 22:40 |
hecks |
we shall see... |
| 22:40 |
MTDiscord |
<josiah_wi> I did just test it. |
| 22:40 |
MTDiscord |
<Jordach> hecks: prefix was set to =/bin |
| 22:40 |
MTDiscord |
<Jordach> https://gist.github.com/Jordach/753e6dde979f2ca7c1f3ffa56e2f2fba |
| 22:40 |
MTDiscord |
<Jordach> entire log |
| 22:41 |
MTDiscord |
<josiah_wi> The Targets file knows where the library and headers are located. It grabs them straight from the build tree. |
| 22:42 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> I should update the docs. |
| 22:48 |
MTDiscord |
<josiah_wi> Updated. |
| 22:49 |
hecks |
i cleaned everything and tried again and now it's |
| 22:49 |
MTDiscord |
<josiah_wi> Oh. Whups. |
| 22:49 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> Ok. I think this is good for final review then. |
| 22:53 |
MTDiscord |
<josiah_wi> 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 |
<Jordach> i want minetest to be wholly much better when it comes to user experience |
| 22:54 |
MTDiscord |
<Jordach> that cannot be possible without holding contributors to standards |
| 22:54 |
MTDiscord |
<Jordach> 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 |
<josiah_wi> 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 |
<Jordach> the lack of documentation was the problem |
| 22:55 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<josiah_wi> 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 |
<Jordach> i'd rather it just silently fail or discard the data |
| 22:58 |
MTDiscord |
<Jordach> 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 |
<Jordach> your one might |
| 22:59 |
hecks |
i wouldn't know because i actually strip that block from my files |
| 22:59 |
MTDiscord |
<Jordach> not tested it |
| 23:00 |
hecks |
but that's not something done by the blender exporter i posted |
| 23:00 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> that actually would be very annoying |
| 23:02 |
MTDiscord |
<Jordach> 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 |
<Jordach> other than MCL |
| 23:02 |
MTDiscord |
<Jordach> lmao |
| 23:02 |
hecks |
aren't we the only .x users |
| 23:02 |
MTDiscord |
<Jordach> yes |
| 23:04 |
hecks |
MCL... what's that again? |
| 23:04 |
MTDiscord |
<Jordach> the most idiotic thing to make with the engine |
| 23:04 |
hecks |
literally minecraft? |
| 23:06 |
MTDiscord |
<Jordach> yes |
| 23:06 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> honestly viewmodels would be rather lit |
| 23:09 |
hecks |
yes they would |
| 23:09 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> reconstructing |
| 23:33 |
MTDiscord |
<Jordach> halfway there |
| 23:36 |
MTDiscord |
<Jordach> loads but segfaults when checking for normals |
| 23:36 |
MTDiscord |
<Jordach> 0 net.minetest.minetest checkMeshNormals(irr::scene::IMesh*) + 96 |
| 23:36 |
MTDiscord |
<Jordach> i see a frame of the attachments before it segfaults |
| 23:37 |
MTDiscord |
<Jordach> ...now it works? |
| 23:39 |
MTDiscord |
<Jordach> seems to be kind of intermittent |
| 23:39 |
MTDiscord |
<Jordach> https://cdn.discordapp.com/attachments/747163566800633906/870088105259061258/Screenshot_2021-07-29_at_00.38.45.png |
| 23:40 |
MTDiscord |
<Jordach> curious |
| 23:40 |
MTDiscord |
<Jordach> it happened against after starting a game, exiting to menu, then starting a new game |
| 23:41 |
MTDiscord |
<Jordach> hecks: checkMeshNormals(irr::scene::IMesh*) |
| 23:41 |
MTDiscord |
<Jordach> 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 |
<Jordach> lemme check |
| 23:41 |
MTDiscord |
<Jordach> if it's one model |
| 23:41 |
hecks |
and if it's random, it's something uninitialized |
| 23:42 |
MTDiscord |
<Jordach> nope it's just that one model |
| 23:42 |
MTDiscord |
<Jordach> memory leak spotted |
| 23:43 |
MTDiscord |
<Jordach> https://cdn.discordapp.com/attachments/747163566800633906/870089006703050752/Screenshot_2021-07-29_at_00.42.36.png |
| 23:43 |
MTDiscord |
<Jordach> https://cdn.discordapp.com/attachments/747163566800633906/870089011945959444/Screenshot_2021-07-29_at_00.42.39.png |
| 23:43 |
hecks |
:DDDDD oops |
| 23:44 |
MTDiscord |
<Jordach> system didn't panic so it's all good |
| 23:44 |
MTDiscord |
<Jordach> one model explicitly explods |
| 23:44 |
MTDiscord |
<Jordach> https://raw.githubusercontent.com/Dumpster-Studios/BattleForArkhos/fps_game/mods/weapons/models/arms_shotgun.x shits the bed |
| 23:45 |
MTDiscord |
<Jordach> https://raw.githubusercontent.com/Dumpster-Studios/BattleForArkhos/fps_game/mods/weapons/models/arms_spnkrx.x doesn't |
| 23:48 |
|
Alias2 joined #minetest-dev |
| 23:50 |
hecks |
sure is a lot of materials |
| 23:50 |
MTDiscord |
<Jordach> i'm doing a more unique method of texturing |
| 23:51 |
MTDiscord |
<Jordach> by having infinitely tileable textures |
| 23:51 |
hecks |
be aware that this increases drawcalls |
| 23:51 |
MTDiscord |
<Jordach> breathing in minetest increases drawcalls |
| 23:51 |
MTDiscord |
<Jordach> what else isn't new |
| 23:51 |
hecks |
i'm just sayin |
| 23:52 |
MTDiscord |
<Jordach> i tend to use not many] |
