| Time |
Nick |
Message |
| 00:06 |
|
hecks joined #minetest-dev |
| 00:06 |
hecks |
so what do we do about the mac CI obviously not using c++11 |
| 00:20 |
|
specing_ joined #minetest-dev |
| 00:27 |
MTDiscord |
<Jordach> actually improve CMake in a proper manner |
| 00:56 |
MTDiscord |
<josiah_wi> Is there an issue for that or could you create one? |
| 00:56 |
MTDiscord |
<Jordach> by that i'm referring to setting CMake to force the compiler to build under CXX11 |
| 00:57 |
MTDiscord |
<josiah_wi> We... don't? head explodes |
| 01:25 |
MTDiscord |
<josiah_wi> Question Jordach. Does Mac have static libraries installed by default and are there ever exceptions? |
| 01:27 |
MTDiscord |
<josiah_wi> It'd be nice if the CMake had built-in support to build Minetest on Darwin, and I'd be interested in attempting this. |
| 01:45 |
MTDiscord |
<Jordach> static |
| 01:46 |
MTDiscord |
<josiah_wi> Why do you compile all the dependencies yourself? |
| 01:47 |
MTDiscord |
<Jordach> hint: homebrew are idiotic developers who refuse to support multiarch |
| 01:47 |
MTDiscord |
<Jordach> as for the next 10 years or so x64 is still likely to be supported |
| 01:48 |
MTDiscord |
<Jordach> you can have one or the other, but not both |
| 01:48 |
MTDiscord |
<Jordach> they also disallow/outright make it difficult to use different OS versions of a dep |
| 01:49 |
|
v-rob joined #minetest-dev |
| 01:52 |
MTDiscord |
<josiah_wi> Why did you need multiarch again? Was it because the M1 uses that? |
| 01:52 |
MTDiscord |
<Jordach> yes, the M1 has support for unsigned binaries as x64 and signed binaries as arm64 |
| 01:54 |
MTDiscord |
<Jordach> Macs as of Big Sur allow fat binaries, ie binaries that contain both arm64 and x64 libraries and code |
| 01:55 |
MTDiscord |
<josiah_wi> I think I have a good picture now of the situation, and I now see how dire it is. No workaround really for missing architecture support in the dependencies except what you've already done, is there. |
| 01:55 |
MTDiscord |
<Jordach> also, if i properly wanted to micromanage the shit that is homebrew deps |
| 01:55 |
MTDiscord |
<Jordach> it'd cost me 4 digits+ in cash to setup those mac minis for multiple configurations |
| 01:56 |
MTDiscord |
<Jordach> not including the ebay pains of finding one that specifically runs mavericks |
| 01:56 |
MTDiscord |
<josiah_wi> Is it really necessary to compile every dependency or do a handful support multiarch? |
| 01:57 |
MTDiscord |
<Jordach> i hacked together working cmake lists for dependancies like libpng |
| 01:57 |
MTDiscord |
<Jordach> as well as removing the offending ARMNEON nonsense |
| 01:58 |
MTDiscord |
<josiah_wi> But do any work without hacking them into submission? |
| 01:58 |
MTDiscord |
<Jordach> most dependancies already support cmake |
| 01:58 |
MTDiscord |
<Jordach> or allow me to use the native lipo tool to construct fat libraries |
| 01:58 |
MTDiscord |
<Jordach> libpng is the known piece of ass |
| 01:59 |
MTDiscord |
<josiah_wi> I'm asking about when you install from homebrew. |
| 01:59 |
MTDiscord |
<Jordach> homebrew has them precompiled for your OS version |
| 01:59 |
MTDiscord |
<Jordach> homebrew makes it easy to make builds tailored for your machine |
| 01:59 |
MTDiscord |
<Jordach> however, they're not that portable |
| 02:00 |
MTDiscord |
<josiah_wi> Ahh because of the "different OS versions of a dep" you mentioned earlier. |
| 02:00 |
MTDiscord |
<Jordach> i could probably hack neoascetics script |
| 02:00 |
MTDiscord |
<Jordach> and get that functional again |
| 02:00 |
MTDiscord |
<Jordach> for mavericks+ |
| 02:00 |
MTDiscord |
<Jordach> (and yes those ran fine under Rosetta for those asking, even JIT too) |
| 02:01 |
MTDiscord |
<Jordach> however, that is not conductive to Mac App Store or the eventual iOS version |
| 02:01 |
MTDiscord |
<Jordach> because the Mac App Store requires a fat binary |
| 02:01 |
MTDiscord |
<josiah_wi> Thank you for the discussion. I understand a lot more about Mac now (I did a little research on good 'ol Google too). |
| 02:02 |
MTDiscord |
<Jordach> leave the masochism to the person that enjoys a thorough fucking over by asinine bullshit |
| 02:04 |
MTDiscord |
<josiah_wi> Sounds good. I'll stick to PRing the C++11 requirement unless someone beats me to it. |
| 02:04 |
MTDiscord |
<Jordach> it's two trivial lines |
| 02:05 |
MTDiscord |
<Jordach> i'm sure it'd take 10 mins to review |
| 02:05 |
MTDiscord |
<Jordach> and test |
| 02:05 |
MTDiscord |
<josiah_wi> Yet it isn't there. head explodes again |
| 02:06 |
MTDiscord |
<Jordach> you're asking the most hodgepodge of projects users and developers why shits missing |
| 02:08 |
MTDiscord |
<josiah_wi> I wouldn't say there's any lack of s***. |
| 05:11 |
|
Extex joined #minetest-dev |
| 06:21 |
|
v-rob joined #minetest-dev |
| 06:46 |
|
Wuzzy joined #minetest-dev |
| 08:08 |
|
jonadab joined #minetest-dev |
| 09:29 |
|
Taoki joined #minetest-dev |
| 09:38 |
|
longerstaff13 joined #minetest-dev |
| 09:49 |
|
entuland joined #minetest-dev |
| 10:04 |
|
Guest joined #minetest-dev |
| 10:16 |
|
calcul0n joined #minetest-dev |
| 10:27 |
|
Fixer joined #minetest-dev |
| 11:30 |
|
ivanb joined #minetest-dev |
| 11:58 |
|
hecks joined #minetest-dev |
| 12:21 |
|
specing_ joined #minetest-dev |
| 12:21 |
hecks |
someone review/approve #11498 already |
| 12:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/11498 -- Add embedded PNG texture modifier by hecktest |
| 15:38 |
|
Extex joined #minetest-dev |
| 16:17 |
|
book` joined #minetest-dev |
| 17:12 |
|
Kimapr4 joined #minetest-dev |
| 18:17 |
hecks |
The GL binding is basically done |
| 18:18 |
hecks |
once again I face the question of what to do with the null driver |
| 18:19 |
sfan5 |
comment it out, can be solved later |
| 18:19 |
sfan5 |
important stuff comes first |
| 18:20 |
hecks |
the whole driver? |
| 18:20 |
hecks |
that'll break CI |
| 18:20 |
hecks |
you'll have to do something about minetest CI jobs that rely on it |
| 18:20 |
sfan5 |
e.g. throw mesa in there? |
| 18:20 |
hecks |
yup |
| 18:20 |
sfan5 |
okay |
| 18:21 |
hecks |
now technically everything will "work" without me doing anything to support null but |
| 18:21 |
hecks |
obviously all the pointers in GL will be 0x0 |
| 18:21 |
hecks |
because the null driver does not have an IContextManager and does not initialize the struct |
| 18:22 |
hecks |
so as soon as any code is written against it (materials...) the null path will start crashing |
| 18:23 |
sfan5 |
how soon do you think we'll have code that uses the GL stuff |
| 18:23 |
hecks |
#11396 already uses opengl |
| 18:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/11396 -- Shader and material system by hecktest |
| 18:24 |
hecks |
so basically as soon as i get irr52 merged i'm going back there and finishing that |
| 18:24 |
sfan5 |
I see |
| 18:25 |
hecks |
while the longer term todo is writing the GL core irr driver |
| 18:32 |
hecks |
irr#52 ready for review |
| 18:32 |
ShadowBot |
https://github.com/minetest/irrlicht/issues/52 -- Add a unified cross platform OpenGL core profile binding by hecktest |
| 18:35 |
hecks |
Honestly, the CI demo could actually be turned into an OpenGL demo |
| 18:35 |
hecks |
I should write a rotating cube for that :o |
| 18:35 |
sfan5 |
afaik the GL context code currently doesn't use the core profile a legacy one (?), that'll have to be switched over once the new driver stuff is actually written |
| 18:35 |
sfan5 |
^ just remembered this |
| 18:36 |
hecks |
Core / legacy is like |
| 18:36 |
hecks |
it's just a hint for the driver that you are not allowed to use some things |
| 18:36 |
hecks |
legacy profile is a superset of core |
| 18:36 |
sfan5 |
ah so it'll work without, good to know |
| 18:36 |
hecks |
code written for core profile will work in a legacy context |
| 18:36 |
hecks |
it'll still be a good idea to clean that up, it's just low priority |
| 18:37 |
hecks |
also, desktop GL versions before 3.3 do not have a core profile |
| 18:38 |
hecks |
the core profile is basically a favor done to new graphics programmers so that they do not have to learn ancient SGI OpenGL |
| 18:38 |
hecks |
and learn only like 200 procedures instead of a thousand |
| 18:39 |
hecks |
core GL is also more in line with how GPUs actually work; legacy GL is actually emulated in drivers |
| 18:40 |
hecks |
which is why I'm killing the fixed function path eventually, we're not actually using an ancient forgotten performance technique (GPU vendors HATE him! this man discovered one simple trick... :D) |
| 18:40 |
hecks |
but in fact on all hardware that we use, the fixed path incurs extra overhead from the emulation the driver has to do |
| 18:41 |
hecks |
and the cheaper the GPU the *less* fixed features it has because they cost more transistors on the die |
| 18:47 |
sfan5 |
the name mangling really is the solution apple recommends? lol |
| 18:47 |
hecks |
hm? |
| 18:47 |
hecks |
like the underscore prefix? |
| 18:47 |
sfan5 |
yes |
| 18:48 |
hecks |
yeah that's from their example code =] |
| 18:48 |
hecks |
I'm just glad that they provided *something* |
| 18:48 |
hecks |
unlike ios where they pretend that nobody would ever want to write any cross platform code at all |
| 18:49 |
hecks |
or maybe they think everyone has an army of poor interns to do it |
| 18:51 |
hecks |
the lack of interns or sweatshops did not stop the irrlicht people from writing their GL bindings manually though :DDDDD |
| 18:52 |
sfan5 |
hmm mac failing on the constexprs |
| 18:52 |
sfan5 |
why aren't those defines? |
| 18:53 |
hecks |
because defines are evil and can't be scoped, duh |
| 18:53 |
hecks |
it's not actually failing on those |
| 18:53 |
hecks |
just being really annoying about it |
| 18:53 |
sfan5 |
ah the scoping |
| 18:53 |
sfan5 |
so you'd use GL.TRIANGLES? |
| 18:53 |
hecks |
what it's failing on is the lack of std::unordered_set.emplace |
| 18:53 |
hecks |
yes |
| 18:54 |
hecks |
just like you no longer use the glDoThing prefix |
| 18:54 |
sfan5 |
>static constexpr const GLenum DEBUG_LOGGED_MESSAGES_ = 0x9145; |
| 18:54 |
hecks |
and you never have to add ARB or OES at the end of anything even if your card does not have the core version of a proc |
| 18:54 |
sfan5 |
is there supposed to be a trailing _? |
| 18:54 |
hecks |
there isn't, let me see |
| 18:55 |
hecks |
it should be eating the _, let me fix this |
| 18:55 |
hecks |
because it was originally DEBUG_LOGGED_MESSAGES_ARB |
| 18:56 |
sfan5 |
hope there's no DEBUG_LOGGED_MESSAGES_ARB and DEBUG_LOGGED_MESSAGES with different values |
| 18:56 |
hecks |
there is not |
| 18:56 |
hecks |
I empirically tested that not a single GL constant ever does this |
| 18:56 |
hecks |
and as for mismatching functions I do test for this and discard anything that doesn't agree with core |
| 18:57 |
hecks |
(I also discard anything that isn't KHR, ARB or OES because it makes extension checking easier and updating extensions is the driver writer's job) |
| 18:58 |
hecks |
you could also chime in on this little problem: |
| 18:58 |
hecks |
BindingGenerator.lua : 266 |
| 18:58 |
hecks |
one of those constants is a bloody define in windows.h, this is exactly why defines are evil |
| 18:59 |
hecks |
my workaround is to prefix it with _ and hope that GCC helps anybody who runs into this by suggesting it |
| 18:59 |
hecks |
it's also a rather obscure function |
| 19:00 |
sfan5 |
the technology wasn't there yet back then |
| 19:01 |
hecks |
since this has to do with threading in windows, this is probably a Windows NT define |
| 19:01 |
hecks |
so they just didn't care, they could have at least tried using a prefix |
| 19:02 |
sfan5 |
as for mac try this http://sprunge.us/r8zZ9S |
| 19:03 |
hecks |
thanks :o i hope this doesn't break mingw64 like my previous attempt did |
| 19:03 |
sfan5 |
I'd be surprised if it did |
| 19:03 |
sfan5 |
we'll see |
| 19:04 |
sfan5 |
I guess I could compile-test the thing on Android |
| 19:05 |
hecks |
let's see if I can build with this |
| 19:05 |
hecks |
thing is that I was running into really obscure mingw gremlins with std=c++11 |
| 19:05 |
hecks |
suddenly dllexporting "GL" stopped working |
| 19:06 |
hecks |
but uhh I guess I was tired, I kinda know what to check this time |
| 19:06 |
hecks |
should have actually opened the dll and seen what it produced, maybe I need an extern "C" somewhere |
| 19:07 |
hecks |
okay it didn't break |
| 19:07 |
hecks |
maybe cause uhh I didn't have to do this DISABLE_STRICT_ANSI thing which i don't even understand |
| 19:07 |
hecks |
but which irrlicht _supposedly_ requires for c++11 |
| 19:09 |
sfan5 |
compiles fine for android |
| 19:10 |
pgimeno |
hecks: about #11498, "Looks good" counts as an approval (but please ask a core dev to be sure) |
| 19:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/11498 -- Add embedded PNG texture modifier by hecktest |
| 19:11 |
hecks |
i am a core dev.... |
| 19:11 |
hecks |
:DDDD |
| 19:11 |
hecks |
this isn't the first time c55 forgot to actually click approve |
| 19:11 |
pgimeno |
yeah but a new one :) I implied to ask an _experienced_ core dev |
| 19:12 |
hecks |
well as soon as someone actually clicks approve i am allowed to merge it |
| 19:12 |
hecks |
i've been running that pr since it was made too, everything works |
| 19:12 |
hecks |
i think my gl-test branch is accidentally based on it |
| 19:12 |
hecks |
so i guess i tricked everyone else into testing it too |
| 19:13 |
pgimeno |
well, all I tested is that it didn't break starting a game, because I didn't really use the feature (AFAIK) and I did very little more than starting a game |
| 19:14 |
hecks |
wow CI passed and i managed to build it too |
| 19:14 |
hecks |
i guess osx is fixed, just gotta get Jordach to run it |
| 19:14 |
hecks |
probably works though |
| 19:14 |
hecks |
pgimeno: just starting devtest will test it |
| 19:15 |
hecks |
the mandelbrots will be rendered as soon as you receive the tile definitions |
| 19:15 |
pgimeno |
[OT] you can explicitly ping Discord users by adding @ before their names, or that's how I think it works |
| 19:15 |
hecks |
@Jordach we fixed irr#52 building on mac, you can test it now |
| 19:16 |
ShadowBot |
https://github.com/minetest/irrlicht/issues/52 -- Add a unified cross platform OpenGL core profile binding by hecktest |
| 19:16 |
hecks |
okay now let me fix the trailing underscore |
| 19:17 |
MTDiscord |
<Jonathon> fyi the ping worked |
| 19:18 |
hecks |
ok this is silly, it should be eating the underscore |
| 19:19 |
hecks |
oh duh i just forgot to use my extra arg |
| 19:20 |
hecks |
pushed, it actually removed some duplicates too |
| 19:20 |
hecks |
I think we're good to ship now? |
| 19:22 |
hecks |
i'll just go through the review |
| 19:22 |
hecks |
oh ffs |
| 19:22 |
hecks |
DIFFERENCE is also a #defined constant somewhere? |
| 19:23 |
hecks |
let me guess it's more windows clownery |
| 19:26 |
|
longerstaff13 joined #minetest-dev |
| 19:33 |
hecks |
sfan5 about the MINETEST_CLIENT define |
| 19:33 |
hecks |
okay so it should probably just be a MINETEST define though we only use GL on clients anyway |
| 19:34 |
hecks |
but anyway its purpose is to switch (dllexport) to (dllimport) on the same header if it is included by downstream code |
| 19:34 |
hecks |
on the same symbol (the GL struct) |
| 19:34 |
sfan5 |
I get that |
| 19:34 |
hecks |
so why would we need to invert it? |
| 19:34 |
hecks |
are you suggesting that MT should spawn the GL object? |
| 19:35 |
sfan5 |
no |
| 19:35 |
sfan5 |
I mean turning 'ifdef MINETEST_CLIENT' into 'ifndef CURRENTLY_BUILDING_IRRLICHT' |
| 19:35 |
hecks |
just #ifndef IRRLICHT? |
| 19:35 |
hecks |
ah ok |
| 19:35 |
sfan5 |
but actually |
| 19:35 |
sfan5 |
just use this? https://github.com/minetest/irrlicht/blob/7709e1e5f8d8429308ae20d366171fdf6e64bee8/include/IrrCompileConfig.h#L500-L508 |
| 19:36 |
hecks |
this is never ever included in minetest right? |
| 19:36 |
hecks |
(why is it in /include/...) |
| 19:36 |
sfan5 |
what do you mean? |
| 19:36 |
sfan5 |
irrcompileconfig is included by just about every irrlicht header |
| 19:36 |
sfan5 |
existing APIs use this to work in DLLs |
| 19:37 |
hecks |
oh there's IRRLICHT_API |
| 19:37 |
hecks |
ok |
| 19:42 |
hecks |
all resolved, just waiting for CI |
| 19:43 |
hecks |
sfan5: all good? |
| 19:43 |
sfan5 |
i'll take another look |
| 19:46 |
sfan5 |
just one thing |
| 19:46 |
sfan5 |
void* GetProcAddress(); |
| 19:46 |
sfan5 |
this in the header, does that do anything? |
| 19:47 |
hecks |
it seems that it no longer does, i'll delete it |
| 19:49 |
hecks |
deleted and regenerated |
| 19:52 |
sfan5 |
shall I click the button? |
| 19:52 |
hecks |
merge? do it :o |
| 19:53 |
|
v-rob joined #minetest-dev |
| 19:53 |
sfan5 |
or did you want to wait for mac testing? |
| 19:53 |
hecks |
oh uhhhhhh |
| 19:54 |
hecks |
well it'll compile anyway |
| 19:55 |
hecks |
we're not actually using this yet so we can get jordach to test it as soon as he's available |
| 19:55 |
hecks |
it shouldn't make anyone's copy blow up, no code in minetest includes mt_opengl.h yet |
| 19:55 |
hecks |
except i guess the opengl driver... |
| 19:56 |
sfan5 |
okay then |
| 19:56 |
hecks |
mac CI doesn't run the auto example does it |
| 19:56 |
sfan5 |
nah |
| 19:56 |
hecks |
would it be hard to make it? |
| 19:56 |
hecks |
that would solve this question |
| 19:56 |
sfan5 |
I don't know if the CI runs headless or whatever |
| 19:56 |
sfan5 |
and you can't just throw Mesa at it like on Linux |
| 19:56 |
hecks |
aaaaaaa |
| 19:58 |
hecks |
well this is a dev branch, we're allowed to take some risks aren't we |
| 19:58 |
sfan5 |
ye |
| 19:58 |
hecks |
we do have a stable branch in irrlicht don't we.... |
| 19:58 |
sfan5 |
there's tags for that |
| 19:59 |
hecks |
well that should be enough |
| 19:59 |
sfan5 |
for example all CI builds on minetest/minetest pull the most recent tag |
| 19:59 |
hecks |
okay then merge it |
| 19:59 |
sfan5 |
I did minutes ago |
| 20:00 |
sfan5 |
(conversely this also forces us to switch to newer tagged versions to make use of features added into irrmt without breaking CI...) |
| 20:00 |
hecks |
explain this to me actually |
| 20:01 |
hecks |
is it possible for me to run CI on the materials branch against *this* commit specifically? |
| 20:01 |
hecks |
is there something you can toggle for this |
| 20:02 |
sfan5 |
there's a version defined in util/ci/common.sh and the buildbot*.sh's but those work for tags where someone uploaded prebuilt releases (you could do this actually) |
| 20:02 |
sfan5 |
perhaps easier is to edit the CI scripts a bit to pull irrlicht master into lib/irrlichtmt |
| 20:03 |
hecks |
so we make a new tag on irrmt |
| 20:03 |
sfan5 |
https://github.com/minetest/irrlicht/releases/tag/1.9.0mt2 <- the prebuilt libs in case you haven't seen them |
| 20:04 |
hecks |
okay so we make a new one, it emits some files and we make CI use those? |
| 20:04 |
hecks |
let me read the script |
| 20:05 |
hecks |
oh i guess i just change the wget url |
| 20:05 |
sfan5 |
...if you have a tag that is |
| 20:06 |
sfan5 |
for the tag you have to upload the prebuilt libs manually, the linux one is just the one from ci (convenient) windows is from scripts/ci-build-mingw.sh plus some packaging around it |
| 20:06 |
sfan5 |
I once planned to write down how the irrmt packaging and related stuff is supposed to work but never got around to it |
| 20:06 |
hecks |
so the release can't be auto made from CI artifacts? |
| 20:06 |
sfan5 |
no |
| 20:06 |
sfan5 |
would be possible if desired |
| 20:06 |
hecks |
shucks |
| 20:07 |
hecks |
of course it would be desired to not have to do this manually |
| 20:07 |
sfan5 |
but like I said if you really just want to test any revision the the clone to lib/irrlichtmt thing works |
| 20:07 |
hecks |
i guess so |
| 20:08 |
hecks |
and cmake will prefer that one? |
| 20:08 |
sfan5 |
yes |
| 20:08 |
hecks |
what about the mingw issues |
| 20:09 |
hecks |
didn't building irr in this way confuse mingw last time |
| 20:09 |
sfan5 |
idk what you're referring to |
| 20:11 |
hecks |
remember when we changed that target thing and people had problems building mt against irrlicht, myself included |
| 20:11 |
hecks |
and the lib/irrlichtmt trick specifically did not work for me |
| 20:12 |
hecks |
i just hope it doesn't mess up CI too, we'll see |
| 20:12 |
sfan5 |
¯\_(ツ)_/¯ |
| 20:13 |
hecks |
oh and how do you prevent the CI changes from polluting master, manual squash while merging? |
| 20:13 |
sfan5 |
revert the commit before merge |
| 20:13 |
hecks |
works |
| 20:13 |
sfan5 |
or what you said |
| 20:31 |
|
entuland joined #minetest-dev |
| 20:52 |
hecks |
oh gee wiz i sure hope nobody notices me making those last minute fixes! |
| 20:53 |
hecks |
and man I really hate #defines |
| 23:36 |
|
Alias2 joined #minetest-dev |
| 23:42 |
|
jonadab joined #minetest-dev |
| 23:53 |
|
Taoki joined #minetest-dev |
