13:38 < bridge> [teeworlds] <Dune> What's the issue with VS?
13:53 < bridge> [teeworlds] <Assa> VS is the issue
13:55 < bridge> [teeworlds] <Assa> if i try to compile with 'cl', standard c headers aren't found
13:55 < bridge> [teeworlds] <Assa> like "stdlib.h"
14:01 < bridge> [teeworlds] <Assa> i tried clang now, but it doesn't seem supported by tw
14:01 < bridge> [teeworlds] <ChillerDragon> What vs do you use!
14:01 < bridge> [teeworlds] <ChillerDragon> ?*
14:01 < bridge> [teeworlds] <Assa> 2019
14:02 < bridge> [teeworlds] <Assa> yes, in the guide it says 2017, the gh-actions workflow run on 2019
14:02 < bridge> [teeworlds] <ChillerDragon> Yea for me it mostly works with 2019 community
14:04 < bridge> [teeworlds] <ChillerDragon> https://cdn.discordapp.com/attachments/490150878934990850/664816701283500042/image0.png
14:06 < bridge> [teeworlds] <Assa> yes i installed it
14:13 < bridge> [teeworlds] <redix> When you use the developer command prompt it should find the headers. Just make sure that you use the same version, which you used for compiling bam (x86 vs x64).
14:13 < bridge> [teeworlds] <redix> You could also try cmake. For me it even works with clang + msvc headers.
14:13 < bridge> [teeworlds] <Assa> clang tells me this:
14:13 < bridge> [teeworlds] <Assa> bam.exe: error: 'other/icons/teeworlds_srv_clang.rc' does not exist and no way to generate it
14:14 < bridge> [teeworlds] <redix> I think bam + windows + clang does not work
14:15 < bridge> [teeworlds] <Assa> i wonder why, clang is explicitly noticed in the bam.lua
14:16 < bridge> [teeworlds] <redix> cmake can use clang-cl. It has the same interface like the cl from visual studio
14:16 < bridge> [teeworlds] <redix> I think the clang in bam is for Linux and mac
14:17 < bridge> [teeworlds] <Assa> take a look at this line, shouldn't clang be supported with bam and windows?
14:17 < bridge> [teeworlds] <Assa> https://github.com/teeworlds/teeworlds/blob/aa0bf33ad9149b7d86f9aa634c592c1a5712f3dc/bam.lua#L233
14:18 < bridge> [teeworlds] <Assa> wait lol
14:18 < bridge> [teeworlds] <redix> In theory. I doubt this was ever tested 😅
14:19 < bridge> [teeworlds] <Assa> I am known to break everything <.<
14:20 < bridge> [teeworlds] <heinrich5991> @Assa please report a bug for `-Winconsistent-missing-override`
14:20 < bridge> [teeworlds] <heinrich5991> warnings are rarely a good sign
14:20 < bridge> [teeworlds] <Assa> @heinrich5991 this warning was due to the introduction of "-std=c++11" in my mod and because i used the override annotation
14:21 < bridge> [teeworlds] <Assa> I didn't want to use the annotation everywhere where you didn't
14:22 < bridge> [teeworlds] <heinrich5991> ah, I see
14:23 < bridge> [teeworlds] <redix> @heinrich5991 you know why cmake uses all the cpack variables but generated the script with custom commands instead of using the cpack generator?
14:24 < bridge> [teeworlds] <heinrich5991> it can also use the cpack generator
14:24 < bridge> [teeworlds] <heinrich5991> try `make package`
14:24 < bridge> [teeworlds] <redix> Yeah but at least for mac it won't generate a dmg
14:25 < bridge> [teeworlds] <heinrich5991> hm
14:26 < bridge> [teeworlds] <heinrich5991> I'm usually on linux, maybe I didn't get it to work on mac
14:26 < bridge> [teeworlds] <heinrich5991> cross-compilation from linux to mac and windows works though 😛
14:26 < bridge> [teeworlds] <redix> Cpack has a generator for creating bundles, but this requires some more setup
14:26 < bridge> [teeworlds] <heinrich5991> we should fix it though
14:26 < bridge> [teeworlds] <heinrich5991> I see
14:26 < bridge> [teeworlds] <heinrich5991> does the non-cpack version work for you?
14:27 < bridge> [teeworlds] <redix> Well I don't have a mac 😅 
14:27 < bridge> [teeworlds] <redix> Just noticed that while setting up the gh actions stuff
14:29 < bridge> [teeworlds] <Assa> what is 'windres'?
14:30 < bridge> [teeworlds] <heinrich5991> sounds like a way to provide icon data for executables on windows
14:31 < bridge> [teeworlds] <heinrich5991> but I don't know the name, that's just a guess rn
14:31 < bridge> [teeworlds] <heinrich5991> oh yea, it is
14:31 < bridge> [teeworlds] <heinrich5991> ```
14:31 < bridge> [teeworlds] <heinrich5991> $ cat other/icons/teeworlds_srv_cl.rc
14:31 < bridge> [teeworlds] <heinrich5991> 50h ICON "teeworlds_srv.ico"
14:31 < bridge> [teeworlds] <heinrich5991> ```
14:32 < bridge> [teeworlds] <Assa> `build\icons\teeworlds_srv_clang.coff : fatal error LNK1112: Modul-Computertyp "x86" steht in Konflikt mit dem Zielcomputertyp "x64".`
14:33 < bridge> [teeworlds] <Assa> shit
14:33 < bridge> [teeworlds] <heinrich5991> mixing targets? ^^
14:35 < bridge> [teeworlds] <Assa> i don't understand why this is happening on every compiler
14:35 < bridge> [teeworlds] <heinrich5991> have you cleaned everything (deleted the build directory) between every attempt?
14:36 < bridge> [teeworlds] <Assa> yes
14:36 < bridge> [teeworlds] <Assa> i learned that the hard way
14:36 < bridge> [teeworlds] <Assa> deleting build directory and config.lua every time
14:37 < bridge> [teeworlds] <heinrich5991> afk
14:41 < bridge> [teeworlds] <Assa> it's always the link step <.<
14:48 < bridge> [teeworlds] <Assa> is there a flag to tell bam to use x64?
14:50 < bridge> [teeworlds] <Dune> arch=x86_64
14:51 < bridge> [teeworlds] <Assa> thank you, but didn't help
14:57 < bridge> [teeworlds] <Dune> use 64 bit everything, build bam with 64 bit, start the msvc 64 bit command prompt and it should use the right headers
14:59 < bridge> [teeworlds] <Assa> i already checked everything
14:59 < bridge> [teeworlds] <Assa> except of visual studio itself, everything should be 64 bit
15:25 < bridge> [teeworlds] <Assa> it get's more and more interesting:
15:25 < bridge> [teeworlds] <Assa> - mingw64 compiles and links, but crashes immideatly when starting
15:25 < bridge> [teeworlds] <Assa> - cl doesn't find the standard c++ headers
15:25 < bridge> [teeworlds] <Assa> - clang gives me an LNK2019
15:38 < bridge> [teeworlds] <heinrich5991> that's so 2019
15:39 < bridge> [teeworlds] <heinrich5991> which symbol is missing?
15:39 < bridge> [teeworlds] <heinrich5991> for clang?
15:39 < bridge> [teeworlds] <Assa> _chdir
15:41 < bridge> [teeworlds] <Assa> i managed to get the opposite error now
15:41 < bridge> [teeworlds] <Assa> `build\icons\teeworlds_srv_clang.coff : fatal error LNK1112: Modul-Computertyp "x64" steht in Konflikt mit dem Zielcomputertyp "x86".
15:41 < bridge> [teeworlds] <Assa> `
15:42 < fstd> i18n'ed error messages are literally hitler
15:43 < bridge> [teeworlds] <heinrich5991> good think they include a error ID, fstd
15:43 < bridge> [teeworlds] <heinrich5991> so it's not so bad
15:43 < fstd> true
15:43 < bridge> [teeworlds] <redix> Are you using bam master or 0.5.1?
15:43 < bridge> [teeworlds] <redix> There was some issue with win64 in 0.5.1
15:44 < bridge> [teeworlds] <heinrich5991> cmake doesn't work for you, either, Assa?
15:48 < bridge> [teeworlds] <Assa> bam master
15:48 < bridge> [teeworlds] <Assa> i will try cmake now
15:57 < bridge> [teeworlds] <Assa> cmake worked instantly
15:57 < bridge> [teeworlds] <Assa> i don't even know which compiler it used
15:59 < bridge> [teeworlds] <heinrich5991> it tells you at the top
16:00 < bridge> [teeworlds] <Assa> cl
16:00 < bridge> [teeworlds] <heinrich5991> that's msvc++
16:00 < bridge> [teeworlds] <Assa> can you tell me what the cmake-target is for the client?
16:00 < bridge> [teeworlds] <Assa> i don't want to build everything
16:01 < bridge> [teeworlds] <Dune> I don't understand why bam+cl doesn't work, maybe you could `bam -v` to see where he's looking for headers?
16:01 < bridge> [teeworlds] <heinrich5991> `teeworlds`
16:03 < bridge> [teeworlds] <Assa> `bam -v` gives me a crazy big log
16:03 < bridge> [teeworlds] <Dune> that's the point, it's verbose
16:04 < bridge> [teeworlds] <Dune> it will tell you the commands it executes
16:05 < bridge> [teeworlds] <Assa> I don't get smart from the log, should i send it here?
16:05 < bridge> [teeworlds] <Dune> just look at one cl line
16:08 < bridge> [teeworlds] <Assa> `cl /nologo /D_CRT_SECURE_NO_DEPRECATE /c /wd4244 /wd4577  /D "WIN64" /Od /MTd /Z7 /D "_DEBUG"  -I"src" -I"src/engine/external/pnglite" -I"src/engine/external/wavpack" -I"build/src" -I"src/engine/external/zlib" -DCONF_DEBUG   /Fobuild/x86_64/debug/objs/engine/shared/console.obj src/engine/shared/console.cpp`
16:08 < bridge> [teeworlds] <Assa> ???
16:08 < bridge> [teeworlds] <Dune> ah right, this only shows custom headers, I'm being silly
16:09 < bridge> [teeworlds] <Assa> needed a grep to find this one
16:11 < Oy> does the 32bit version build?
16:11 < bridge> [teeworlds] <Assa> bam didn't find the headers so no
16:12 < Oy> odd
16:12 < bridge> [teeworlds] <Assa> i manged to compile everything 32 bit in MinGW except the client btw
16:12 < bridge> [teeworlds] <Assa> *with
16:12 < Oy> what was the problem?
16:12 < bridge> [teeworlds] <Assa> weird linker problems with sdl2 and freetype
16:13 < Oy> u have an error message?
16:13 < bridge> [teeworlds] <Assa> give me a sec. I will lookup bash_history
16:14 < bridge> [teeworlds] <Assa> No I don't, since it's still imited on 500 lines ...
16:16 < bridge> [teeworlds] <Assa> build/x86_64/release/objs/engine/client/backend_sdl.o:backend_sdl.cpp:(.text+0xea): undefined reference to SDL_MinimizeWindow'
16:16 < bridge> [teeworlds] <Assa> this is just the first, practically all calls to sdl2 failed
16:17 < Oy> it's 64bit u can't build it with normal mingw
16:18 < Oy> make sure to build bam with make_win32_mingw
16:19 < Oy> then do bam config forteeworlds 
16:19 < bridge> [teeworlds] <Assa> makes sense
16:19 < Oy> and then try to force a recompile
16:19 < bridge> [teeworlds] <Assa> the bam i used was 64bit windows cl
16:19 < Oy> yeah
16:19 < bridge> [teeworlds] <redix> Or use mingw-w64
16:20 < Oy> yeah
16:20 < bridge> [teeworlds] <Assa> i tried mingw-w64
16:20 < bridge> [teeworlds] <Assa> the list above shows: compiling: yes; linking: yes; crashing: yes
16:21 < bridge> [teeworlds] <Dune> what about mingw32?
16:21 < bridge> [teeworlds] <Assa> see above
16:21 < bridge> [teeworlds] <Dune> did you build bam with make_win32?
16:21 < bridge> [teeworlds] <Assa> no
16:25 < bridge> [teeworlds] <Assa> but cmake is now working and I can compile the client
17:04 < bridge> [teeworlds] <Assa> can you tell me where the text width is calculated?
17:07 < bridge> [teeworlds] <Assa> nevermind iam blind
17:35 < bridge> [teeworlds] <Dune> so should https://github.com/teeworlds/teeworlds/pull/2176/files be reverted?
17:39 < Oy> dunno, low values feel much smoother with the log scrollbar now, so it would be ok to keep them
18:02 < Oy> oh the pr broke the build
18:06 < bridge> [teeworlds] <Dune> oh, there are no more CI checks? that's not great
18:06 < bridge> [teeworlds] <Dune> I foresee a lot of cmake breaking :p
18:07 < bridge> [teeworlds] <Dune> or disabled by default warnings
18:08 < bridge> [teeworlds] <redix> The workflow only triggers on push. It can also be enabled for pull requests
18:28 < Oy> yeah, should do that
18:48 < bridge> [teeworlds] <Assa> it's a oneliner in build.yaml: `on: [push, pull_request]`
18:49 < bridge> [teeworlds] <Assa> ironicly the build is failing because the current master is failing in cmake
18:50 < bridge> [teeworlds] <Assa> oy was faster 😮
18:55 < bridge> [teeworlds] <Assa> I am in my own fork on github on master - i upload to my own branch changes  -  "Do you want to do a PR?" - I click yes - I PR to teeworlds/teeworlds -  thx github
19:55 < bridge> [teeworlds] <Dune> Makes sense, you forked teeworlds/teeworlds
20:50 < bridge> [teeworlds] <jxsl13> man, those friendlist features are hidden as hell, I wouldn't find them for another 5 years if I didn't read about them in pull requests...
21:02 < bridge> [teeworlds] <Sonix> 😄
22:12 < bridge> [teeworlds] <Dune> https://pastebin.com/G8XMt5bm
22:12 < bridge> [teeworlds] <Dune> huh
22:13 < bridge> [teeworlds] <Dune> gotta do some explicit conversion