Steam Uploader

[dark yew]

The app is now in a non working spiral of hell that I just can't manage to fix

Everything works Linux side, nothing works Windows side for some reasons, and this is just demotivating me at this point to work further on it

All of these libs, I had managed to fix by just adding simple arguments to the build commands back then, and cmake I guess doesn't have any of that ? Like at this point I don't even know, I have a gun in my hands that I literally have no idea to operate and at this point I feel like throwing a rock at someone would do a better job killing them than this monstrosity of cmake

[steep zenith]

what's weird is it works flawlessly for me

i suspect it's working for me because i have mingw? (not sure) ill look into it more

[steep zenith]

btw, you dont need nlohmann json package on linux, I use the headers from it only (i was reading the github workflow you added)

and you also shouldn't need to use vcpkg either???

the whole point of using CPM was to avoid vcpkg because there is only a few dependencies (one or two of which arent on vcpkg anyway), so you setting it up in the Windows build is pointless

also it doesn't help that -static-libwinpthread doesn't exist, I just assumed it did because you used it before

[steep zenith]

set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static-libgcc -static-libstdc++ -Wl,-Bstatic,--whole-archive -lwinpthread -Wl,--no-whole-archive")

You can maybe try something like this, although im kinda done with it at this point, dynamic linking issues fuckign sucks

I would consider rewriting this in C# maybe with something like Avalonia (a ui lib), since there are cross platform UI libraries for it that are easy to set up

[dark yew]

But it works for me too, that's the thing

Building locally it works

But releasing then using that build release, it won't work

[steep zenith]

its probably something to do with the libs being dynamic

[dark yew]

And I don't build differently, only diff is the things in PATH I'd say

[dark yew]

The thing is that those problematic libs just aren't even in the folder of the app when building locally, and it finds them

[steep zenith]

yea thats how dynamic libs work

if they arent alongside the executable, system will look in paths for the dll on the PATH like C:\Windows\System32 and use those instead

and if it cant find any, will fail

[dark yew]

Not sure what you mean, the libs aren't exe files ?

[steep zenith]

I meant dlls sorry

[dark yew]

Ah ok

[steep zenith]

so most likely, it works for you because the system finds the required .so file in your package manager in some package, but when you run it in an environment without those package, doesnt work

[dark yew]

The thing is that I looked at my entries in PATH and I can't really find the needed dlls

[steep zenith]

this is one of the many downsides to dynamic libs, but we haven't got a choice unless you use C# because steam doesnt bundle their source code with it

[dark yew]

No linux works without any problems I thinn, it's the windows version that doesn't work

[steep zenith]

so whats the actual problem?

[dark yew]

What would be the difference with C# ?

[steep zenith]

doesnt build? or doesnt run

[dark yew]

It builds but doesn't run, there's a pre release 0.6.0 with the non working files

What's confusing is that on the same machine I run:

• locally built, works
• release built, doesn't work

[steep zenith]

the language is different, but the community has created an open source wrapper for the api and it's source code available (https://github.com/rlabrecque/Steamworks.NET)

[dark yew]

So it's not the PATH or it would work ?

[steep zenith]

it's probably not exactly only PATH, the system would probably have it's own folders to look at

[steep zenith]

when you try to run it, what happens?

[dark yew]

Ok but what would be the diff with C++ ? Are libs better handled ?

[dark yew]

Locally built:

• app works without any problems
  Release built:
• opens error windows on using the app that the libs I mentioned earlier couldn't be found

[steep zenith]

the only differences are a easier cross platform UI support which I think you wanted and you can statically link the steam dll because of the open source code I linked above

and also C# has a lot of libraries included in it's stdlib so you wouldn't need curl iirc

[dark yew]

What's the difference between C++ and C# overall ? Do I need to rewrite basically everything or the languages are alike ?

[steep zenith]

the languages are not as similar as C and C++ are

somewhat similar syntax, but it would basically be a rewrite

but most c# apps anyway do dynamic linking

[dark yew]

What I don't get is that the problem I'm having was fixed with a one or two arguments in the build command before
And now this cannot be fixed as easily ?

[steep zenith]

the libs not being linked shouldnt be a hard fix no

[steep zenith]

does this ^ not fix it?

[dark yew]

I'll try when I get on my pc

[steep zenith]

with mingw64, you can do ldd example.exe and it will show what libs needed
but that might not provide all the information, its limited. Better option is to use https://github.com/hfiref0x/WinDepends

[dark yew]

Wait so this line sets the exe linker flags to the exe linker flags again ?

Oooooh nvm yea that's like the previous line too

Ok testing rn

well that's a first lol, the Linux build is taking longer than the windows one for once

Not like it matters but that's curious

[steep zenith]

no, it's because if there are any other flags set, dont want to overwrite the existing ones, just add

[dark yew]

Yea figured that was probably something like that 👌

Ok release built properly, going to test in the vm

Ok that's fucking weird, why is the github release zip marked as a Trojan by Windows Defender ??? 😭

Wtf is going on ???

WTF

[steep zenith]

wacatac common windows defender false positive

this is a common issue with a lot of programs, especially open source, only fix is to submit a ticket manually to microsoft some way

otherwise. people just have to do Actions > Restore

this could also be triggered from the CURL dependency, it's hard to say what is triggering it

[dark yew]

Literally nothing was changed

I only changed with the line you sent

Why would it flag it NOW

Also I tried to do action > restore and that won't do it

[steep zenith]

idk

[dark yew]

Oh ok action > restore worked for the second one, wait

Is that going to do that for every users ?

[steep zenith]

it's possible microsoft's AI detection thing was still in the process of analysing it, and then it detected it and updated it in the database

[steep zenith]

no, per computer basis

once you restore it, generally dont need to do it again unless you move the location and stuff

[steep zenith]

i dont know what this is, I use 7zip

[dark yew]

Still same problem

[dark yew]

Default Windows stuff

I'm not using anything special

It's bcs I try extracting and it gets blocked by Windows Defender

[steep zenith]

yea that makes sense

[dark yew]

So yea this didn't work

[steep zenith]

-static-libgcc should literally link that wut

[dark yew]

It does that for the 4 libs I mentioned previously

That's been the same issue over and over

That's what I'm saying, building locally on my PC works, but github releases, it doesn't work

I'll check my release file again wait

[steep zenith]

the usual way to fix this is to just do -static but that makes every lib static which cant do obviously

[dark yew]

Also about vcpkg, it's to install cmake

No wait sorry

Not cmake

Curl

[steep zenith]

yea ik I read that file already

but im saying its not useful to install vcpkg entirely just for curl, the whole point was to not use it

on the runner, install the curl for windows and do it that way

[dark yew]

Ok but literally nothing worked with the previous solutions for curl

[steep zenith]

i literally had a working way for it on windows, already in the readme explaining you need curl for windows

[dark yew]

And it didn't work

I'm not changing shit for the sake of it aoqia, I changed it bcs it didn't work, I'm not doing it for the gigs

That's the commit when I changed it
2ba280e8776b8ef22e4e7f3b6bfad667b86fd898

I don't remember the exact issue, but I had problems with it for the release
Bcs again, locally you add curl to your path bcs you download manually, but in the release, I need to download curl somehow

The only external dependency that is required to be manually installed is curl. Windows users should install curl for Windows. Linux users need to add the corresponding libcurl package via the system's package manager.

I installed it

So if there's a cleaner way to manually install curl in the release.yml, do share it please

[steep zenith]

I dont understand why you should have issues with it on windows

My version of it uses curl for windows and builds, links and runs correctly

[dark yew]

Bcs I need to install curl in the release machine

[steep zenith]

if you get the runner to download https://curl.se/windows/latest.cgi?p=win64-mingw.zip and it should work

[steep zenith]

yes ik, i've been saying to use curl for windows ^

[dark yew]

I literally do not know fucking the difference !

[steep zenith]

all curl for windows is, is precompiled curl libs using mingw

i thought I explained this ages ago when albion was asking why it wasnt working

[dark yew]

I'm not in a proper learning environment here, I don't know anything about compiling, building and other stuff
I don't understand what is what and what are equivalent systems
I don't understand what Ninja is, I don't even know what mingw is supposed to specifically at this point, and other words and systems that literally look the same to me
Again, I've been given a gun in my hands and I end up having to learn by shooting randomly, no shit stuff is going to break and I'm not going to use anything properly

I understand what various bits do in the cmake, and possibly how to do some stuff, but overall I don't know any of the proper ways to do anything
So if I'm doing shit, it's not surprising but you can't just tell me "I don't understand why you use that or that" and not tell me what my mistake even is when you do these remarks, bcs stuff that sound sooooo obvious to you are the complete opposite of how I might see it and possibly understood it

There's so many steps needed in that cmake that were added on top of what I was previously using, that I didn't even master at all, that at this point, I'm not even sure what some systems interact with what

[steep zenith]

Ninja is a build tool similarly to how make/makefiles are, but Ninja is much faster, thats all you really need to know at a surface level

[dark yew]

What does it handle tho ?

[steep zenith]

cmake is always complicated and there's never an exact way to do things in it generally, you can do things like 4 different ways if you want, its actually frustrating to use but it's the only widespread mainstream build thing

[dark yew]

Like in the whole process, what does it handle here (Ninja)

[steep zenith]

it generates files that tells the build system how to build the stuff

generally thats how all the build systems work (same with make)

[dark yew]

What confuses me is that the cmake files adds a bunch of stuff in common between the build process of Windows and Linux, but there's so many "if windows, do that, if linux do that" that at this point wouldn't just having two separate files for the build process just be better ?

[steep zenith]

The only windows/linux if statement I did was to create custom commands (or maybe you did that?), because for some reason the copy_if_different command requires parameters in a different order on linux

I did use one previously with curl, but that is long gone

[dark yew]

Hmm I guess you're right yea it's not that much used

I think I did the custom command for Linux yea

Yea

Unless you sent it to me, I don't remember

[steep zenith]

I do remember now, I had something similar to that but removed it since the TARGET_RUNTIME_DLLS didnt work on linux

[dark yew]

Yea

So Ninja is the pre-build and mingw is the compiler ?

[steep zenith]

mingw is the linux gcc toolchain mostly but on Windows

so instead of having linux executables, they are .exe so you can use them on Windows

[dark yew]

So mingw is equivalent to gcc ?

[steep zenith]

not exactly

it includes gcc, clang, and you can install some other linux packages too

I don't really know the best way to explain it

"Mingw-w64 is a collection of header files, import libraries, libraries and tools that, when combined with a compiler toolchain, such as GCC or LLVM, provides a complete development environment for building native Windows applications and libraries."

[dark yew]

Also I'm going to look into using that instead vcpkg

[steep zenith]

I think I got MSYS2 and mingw mixed up, but something or other the same thing

[dark yew]

Just trying to understand the different concepts and steps here of the build and taking some notes to finally properly understand the process, or the general steps at the very least

[steep zenith]

you do realise that the latest release does have curl in there?

im double checking that its not using my system dlls though

[dark yew]

Wdym ?

It is in the release yes of course

[steep zenith]

oh that wasnt the issue, I keep forgetting

[dark yew]

Yea curl works now, tho if I'm not supposed to use vcpkg then I'll change it to the direct download you sent

[steep zenith]

ideally not use vcpkg

in this case*, mainly because decided not to use vcpkg at the start

if you want to switch to vcpkg, you can (it's easier to set up but has some drawbacks), but you still cant statically link the steam dll

[dark yew]

Ok so MinGW holds GCC, so on Linux we install GCC, or I guess it's already available in the Linux release chain and on Windows we install mingw which holds gcc so it installs it at the same time

Now where is it defined in the cmake to use gcc ?

[dark yew]

What is supposed to be vcpkg, and what is the equivalent we use ?

[steep zenith]

vcpkg is like a package manager that has a set list of libraries for different platforms

conan is a similar to that too, same principles

currently use CPM, which is written only in cmake, so it doesn't require any third party setup (just cmake only)

[dark yew]

ok so cpm =~ conan =~ vcpkg ?

[steep zenith]

no none of them are equal

[dark yew]

Yes not equal

equivalent

[steep zenith]

they share similarities (mainly between vcpkg and conan) but CPM is not really a full external package manager like vcpkg/conan, it's more of a lite package manager

since you didnt need that many dependencies, I opted to use CPM instead because there's not really much use for setting up vcpkg just to use 1 library imo

[steep zenith]

cmake will detect a installed compiler on the system and use it

[dark yew]

Ah ok so we don't force it

[steep zenith]

ye

[dark yew]

But the three are the same system in a way, by being package managers ?

[steep zenith]

i am no expert at cmake at all, i hate it and i mostly avoid c++ for that reason, but it really depends on what you're doing

[steep zenith]

yea, except since CPM is written in only cmake, you dont do anything outside of cmake

if you look in the cmake/cpm/ files, you will see CPMAddPackage, and this is basically adding the library to the project

[dark yew]

ok so cpm is cmake only

[steep zenith]

whereas using vcpkg you add packages to a manifest and when vcpkg runs it grabs the packages and stuff

[dark yew]

Ok I'll look into changing the vcpkg now

Ok so:

• download curl "https://curl.se/windows/latest.cgi?p=win64-mingw.zip"
• unzip
• add the folders to deps/curl
  • /bin
  • /lib
  • /include

Actually it's _deps not deps

Is it ? wait

Ok no move to packages/curl alongside the Steam one

[steep zenith]

you dont need to, but you wouldn't include curl in the repository, only the runner

I think it might need to be on the path as well, though im not sure at all

yes it does ^

[dark yew]

Can I not link it directly from the cmake ?

That was my current go to

[dark yew]

Also yes I'm downloading from the runner

I'm not adding it to the repo

Ah wait if I do it from the cmake, then users who build from their own machine won't have the files anyway ...

So do I just add the curl files to the path ?

[steep zenith]

if its on the path already, find_package will work

or it should at least

[dark yew]

Alright I'll try that

Also all this is not going to fix my issue with the other libs is it

[steep zenith]

yes, dont want to bundle files as much as possible

[steep zenith]

no, the libgcc stuff is still issue idk why

[dark yew]

Yea I'm not bundling them, but the process I was going with was not the right one, adding to path in the release runner now

[steep zenith]

I think you need to also specify in spdlog.cpm to use the -static-libgcc and others like -static-libc++

idk its a pain

[dark yew]

But why does it work when building locally, but not in the release version ?

[steep zenith]

because the libc++ dll/so is probably on your system somewhere

on windows mingw has it included

usually its where teh compiler is

and for some reason, it doesnt want to statically link it

[dark yew]

Maybe bcs it's not finding it ?

Should we just not statically link it ?

[steep zenith]

yea thats what the error message means

[steep zenith]

it's not being currently statically linked

[dark yew]

Yea but the error message is on launching the app, not building

I meant not finding it with the cmake

[steep zenith]

yes dynamically linked programs (generally) resolve the dll paths when you run the exe

[dark yew]

I meant dynamically link, like the other dlls ?

[steep zenith]

oh hmm

[dark yew]

Bcs at this point it's either:

• the release.yml process causing issues
• the environment the build is being ran in
  which is the problem ?

[steep zenith]

send the output of cmake

[dark yew]

Since building locally works, it's not the cmake the issue

[dark yew]

wdym ? The logs ?

[steep zenith]

which problem? if the libgcc_blah.dll error, then its because libgcc/libc++ dlls not being statically linked with the program when building

[steep zenith]

you said cmake couldnt find curl

[dark yew]

idk, it was an assumption of what the possible problem is

[dark yew]

Building locally works, building on release doesn't, so it can't be the cmake the issue since that works locally ?

[steep zenith]

raaaaaaaahhhhhhhhhhhhhhhhhhhhh

ok you on linux?

or window

[dark yew]

So it's ever the environment it's being built in, or the release.yml but I don't see anything about that last one, so if it's the environment it's being built in, then maybe in the cmake locally it finds it, and it doesn't in the runner

[dark yew]

Personally on Linux, and I test on a Windows VM

[steep zenith]

its not release.yml

[steep zenith]

go to the program and do ldd YourProgram on linux

[dark yew]

The release one ?

Or my locally built one ?

[steep zenith]

whichever one, the release and locally built ones should be the exact same

[steep zenith]

its not the issue of the release being bad build ^

[dark yew]

wdym

[steep zenith]

see, it find libstdc++ in your gcc toolchain installed on your computer

[dark yew]

Yea but Linux I've yet to have any issues

[steep zenith]

if you run the program on linux computer without gcc, it will fail

because you have all the stuff installed already

[dark yew]

So if I run in a raw Linux install, it won't work ?

[steep zenith]

dynamically linked libraries will be found when you run the application, not when its built

[steep zenith]

yes

it wont because you dont have spdlog, curl, libstdc++, libgcc etc

unless you include them .so/.dll alongside the exe or statically link them

[dark yew]

I mean, users could also just download the packages on their machine no ? Or that wouldn't be the proper way to do it ?

[steep zenith]

yes that is what they're supposed to do on linux

but on windows, different story

[dark yew]

Like anything in Linux when you download them they download dependencies on your machine

[dark yew]

Yea they need the dlls bundled with the app

That I clearly understood this shit show lol

[steep zenith]

though you can bundle the .so on linux too and it would work on any pc

[dark yew]

Yea, but they should just download with the package manager of their distro

Not point bundling stuff that need a single command line install

[steep zenith]

the problem here is that on windows, you go to run the exe, it tries to find libgcc dll and cant find it, fails the program

[dark yew]

Tho that might be good to tell users what they need to download on Linux

[steep zenith]

you either bundle the libgcc dll from mingw (not ideal) or you statically link libgcc and libc++ into the program

[dark yew]

Yea I thought about bundling it from mingw but that sounded so annoying I didn't go with it

[steep zenith]

statically linking libgcc and libc++ was what the linker flags being set should've done, but it didnt work

[dark yew]

Maybe the Windows runner doesn't have the libs ?

[steep zenith]

no it does,you install mingw

the problem isnt the runner at all

[steep zenith]

^

[dark yew]

That literally gives zero info on what the problem actually is

[steep zenith]

dynamically linking doesn't include the dll at all in the build, statically linking does, you might be getting confused with them

[steep zenith]

i've been explaining the problem for like 25 minutes 😭

that message is literally word for word the problem

[dark yew]

But that's not explaining why that even happens ?

[steep zenith]

because we're dynamically linking

[dark yew]

Locally, it works, release build, it doesn't, that's the problem ?
Yes it doesn't find them, that's literally the errors says, but where the fuck are they if locally it fucking works, but release it doesn't even if using them on the same computer ???

[steep zenith]

and it isn't statically linking c/c++ libs

[steep zenith]

do release you mean running it on Linux still?

[dark yew]

No Windows !

[steep zenith]

I thought so

[dark yew]

Linux we completely ignore now

Rn it works

At least on my end, tho I didn't test in a fresh Linux install

But Windows, the release DOESN'T WORK but the LOCAL BUILD DOES

On the same machine !

[steep zenith]

hmm that is really odd

[dark yew]

Right is locally built, it works
Left is release, doesn't work

That's why I'm so fucking confused about this shit

[steep zenith]

did you make any changes to the local build that the release doesnt have?

[dark yew]

No, nothing

Same exact copy of the source code

Locally built, works
Release, doesn't

[steep zenith]

https://github.com/hfiref0x/WinDepends
download this and put the local exe in there

[dark yew]

That's why my assumption was either the release.yml
or the environment they are being built on

[dark yew]

The local exe of the app you mean ?

[steep zenith]

wait

remove zlib1.dll from there, idk even why its in the folder

[steep zenith]

yes

the locally build one, put the exe in it

[dark yew]

left cmd shows the error pop ups

[dark yew]

sec, need to go on Discord from the vm

Wait what do I do with that WinDepends thing

[steep zenith]

so, drag the exe in there, click OK, wait a bit
on the top left panel, it will show all the dll it uses, and you right click and chose "Full paths"

[steep zenith]

run it

[dark yew]

Those are two separate things right:

• send the exe
• run that app

Locally built

[steep zenith]

I deleted the send me the exes, but you can if you want

locally built one statically links libgcc and libc++ correctly I think

zip the dlls too

[dark yew]

Sending them like that, apparently zip isn't possible by default on Windows lol

[steep zenith]

it still expecting libcurl-x64.dll

you should delete the files you sent from the discord chat, and use windepends on the vm

[dark yew]

wdym

This is getting extremely confusing here

[steep zenith]

the curl dll needs to be there too

unless its getting statically linked too somehow

[dark yew]

I don't understand if windepends is the process you want to use to send the files here or if two are different things

[dark yew]

It's in my PATH, I think that's why

[steep zenith]

it tells you where the dll files its finding for the program

so you can see if it picks up the wrong dlls

[steep zenith]

^

[dark yew]

Yea curl is being picked up from my PATH, as I thought

That's not a problem since curl isn't the problem here

[steep zenith]

but you look in the bottom, it probably says in the console that its missing a dll right?

[dark yew]

Also this is for the locally built one

[dark yew]

Locally built one which works

I'll try with the release one

[steep zenith]

yes

[dark yew]

For now, nothing new

[steep zenith]

it has to be a difference in the cmake

[dark yew]

It finds the dlls in the release that are bundled with it
It doesn't find those damn libs

[steep zenith]

im going to check your release.yml again, is the one in main branch the one you use?

[dark yew]

Yes, I just pushed a change that removes the copy of mingw dlls that I had tried

I don't think it'll matter since that part did nothing I think

And the build was done before cp these files too

why they don't get copied anyway

@steep zenith does locally built work on your side, and release no work like me ?

I'm starving rn so I'll go make myself some food and I come back a bit later

[steep zenith]

release works for me, probably because I have the mingw dlls it wants on my path

[dark yew]

Maybe, I can try that tbf

[steep zenith]

no thats not a good solution

[dark yew]

No of course it's not

[steep zenith]

yea it find them on my path

only spdlog require them, weirdly enough

but its also finding zlib from my mingw path too

[dark yew]

Yea it takes them from your mingw install

[steep zenith]

I thought libcurl dll included the zlib1 dll too, I guess not

ok doing the thing before with

target_link_options("${CMAKE_PROJECT_NAME}" PUBLIC -static-libgcc -static-libstdc++

does it work?

do it above target_link_libraries

actually I can do it myself

this is just in shambles lol

I also just realised you put the CMAKE_EXE_LINKER_FLAGS too far down

you should do it at the top of the program, because you do it under target_link_libraries where the libraries are already linked

ok I did ```cmake
set(CMAKE_CXX_STANDARD_LIBRARIES "-static-libgcc -static-libstdc++ ${CMAKE_CXX_STANDARD_LIBRARIES}")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static-libgcc -static-libstdc++ -Wl,-Bstatic,-lwinpthread -Wl,-Bdynamic")

and it seemed to be OK, but libwinpthread still not linking or including

idk its just such a pita

https://stackoverflow.com/questions/13768515/how-to-do-static-linking-of-libwinpthread-1-dll-in-mingw

I dont want to look at cmake anymore 😭

[dark yew]

I'll try that

[dark yew]

Wait so how far up should I put it then ?

Also could that cause problems ?

option(BUILD_SHARED_LIBS "Build shared libraries" ON)
set(BUILD_STATIC_LIBS OFF)
set(BUILD_TESTING OFF)

[steep zenith]

just anywhere above the target_link_libraries

I usually do set stuff up the top

[steep zenith]

yea

[dark yew]

Need to make sure for windows too

[steep zenith]

?

[dark yew]

Yea previously this was done for Windows only ?

[steep zenith]

oh, well ya do it for all platform

but I think winpthread is only for windows, so take that part into a windows if

basically the flags after the static gcc and stdc++ you put in a new set for windows only

but im not sure if that will work either, its just annoying

[dark yew]

set(CMAKE_CXX_STANDARD_LIBRARIES "-static-libgcc -static-libstdc++ ${CMAKE_CXX_STANDARD_LIBRARIES}")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static-libgcc -static-libstdc++ -Wl,-Bstatic,-Bdynamic")

if(Win32)
        set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -lwinpthread -Wl")
endif()

Alright I'll test that

[steep zenith]

no, -Wl and beyond is for winpthread

the -Wl,-Bstatic,-lwinpthread -Wl tells to compile libwinpthread statically, then after that it makes everything else dynamic

[dark yew]

Aaah the space is the separator

jeez

set(CMAKE_CXX_STANDARD_LIBRARIES "-static-libgcc -static-libstdc++ ${CMAKE_CXX_STANDARD_LIBRARIES}")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static-libgcc -static-libstdc++")

if(Win32)
        set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-Bstatic,-lwinpthread")
endif()

set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-Bdynamic")

That ?

[steep zenith]

ye I think

[dark yew]

Alright testing

Locally works for now

[dark yew]

Didn't work

This is madness

Ok I'm now digging in my own Cmake I had made which was used for 0.5.0

target_link_options(app PRIVATE -static-libgcc -static-libstdc++ -static)

This was used back then

[steep zenith]

hmm how did you use -static when steam sdk is dynamic only

[dark yew]

cmake_minimum_required(VERSION 3.15)
project(SteamUploader)

set(CMAKE_CXX_STANDARD 17)

# Gather all source files
file(GLOB_RECURSE SOURCES "src/*.cpp")

add_executable(app ${SOURCES})

# Platform-specific settings
if(WIN32)
    # Windows settings
    target_include_directories(app PRIVATE
        ${CMAKE_SOURCE_DIR}/include
        ${CMAKE_SOURCE_DIR}/include/curl
        ${CMAKE_SOURCE_DIR}/include/nlohmann
        ${CMAKE_SOURCE_DIR} # for steam
    )
    target_link_directories(app PRIVATE
        ${CMAKE_SOURCE_DIR}/SteamAPI/win64
        ${CMAKE_SOURCE_DIR}/lib
    )
    target_link_libraries(app steam_api64 ${CMAKE_SOURCE_DIR}/lib/libcurl.dll.a)
    target_link_options(app PRIVATE -static-libgcc -static-libstdc++ -static)
else()
    # Linux settings
    find_package(CURL REQUIRED)
    target_include_directories(app PRIVATE
        /usr/include/nlohmann
        ${CMAKE_SOURCE_DIR} # for steam
    )
    target_link_directories(app PRIVATE
        ${CMAKE_SOURCE_DIR}/SteamAPI/linux64
        ${CMAKE_SOURCE_DIR}
    )
    target_link_libraries(app steam_api curl pthread)
    target_link_options(app PRIVATE -Wl,-rpath,'$ORIGIN')
endif()

[steep zenith]

I mean you can try it, there's an option at the top of the cmake to turn on static libs

[dark yew]

No idea

[steep zenith]

and then turn off the build_shared_libs one

[dark yew]

Is the app even statically linked, I'm not sure

Wait I'll download the 0.5 on Windows and see

[steep zenith]

well actually, iirc steam has a lib stub that maybe can be statically linked, but you still need to include the dll

[dark yew]

I'll try that

[steep zenith]

so these, you would turn BUILD_STATIC_LIBS to ON, and BUILD_SHARED_LIBS to OFF

and obv remove the linker flags and the other line (or comment them)

[dark yew]

I just copied the line and changed app to the one we use

[steep zenith]

what line

[dark yew]

sorry that one

target_link_options(app PRIVATE -static-libgcc -static-libstdc++ -static)

I'm going to try to do the exact same thing

[steep zenith]

but instead of using -static, you should use the BUILD_STATIC_LIBS

because some things can rely on that cmake var being set and change their output based on it

[dark yew]

alright

locally built works

waiting for release

[steep zenith]

I want to make it clear that you locally built exe and the release exe will be the exact same

if you want to make sure the exe doesnt have the dll errors again, copy it to the computer where mingw isnt in the path and see what happen

[dark yew]

Proof they aren't, one works while the other doesn't 🙄

[steep zenith]

thats because they were different

[dark yew]

No no

They are literally built of the same commit

[steep zenith]

did you delete the build folder and do clean build?

[dark yew]

Every, single, time I test this out, they are built on the same commit, maybe a rare few exceptions

[dark yew]

Yes, every, single, time

[steep zenith]

how do they have different dlls then?

the release one you were comparing before had different dlls included

the runner is doing literally the exact same thing as what you are doing to build, it shouldnt have different results in any situation

[dark yew]

My process has been:

• edit on my PC

• push edits

• pull in VM

• delete .cache and build

• run the build commands on my local

• run the app (local)

• push a new release

• wait for it

• delete previously downloaded app files

• run the app (release)

[steep zenith]

hmm then the local and the release should be the same (exe, dlls) in theory

[dark yew]

How am I supposed to know ? I can send you the files again rn, maybe I had a commit off between the two versions I sent, but I can't 100% assure you the problem is present on locally and release builds from the same commit

Build failed on Linux release, I need to win32 only I think

Like I did in my previous version

Oooh it's the Steam that caused issues

FAILED: [code=1] bin/SteamUploader
: && /usr/bin/c++ -O3 -DNDEBUG -static-libgcc -static-libstdc++ -static -Wl,--dependency-file=CMakeFiles/SteamUploader.dir/link.d CMakeFiles/SteamUploader.dir/src/main.cpp.o CMakeFiles/SteamUploader.dir/src/Uploader.cpp.o CMakeFiles/SteamUploader.dir/src/Util/AppID.cpp.o CMakeFiles/SteamUploader.dir/src/Util/ReadFile.cpp.o CMakeFiles/SteamUploader.dir/src/Util/WarningHook.cpp.o -o bin/SteamUploader -Wl,-rpath,/home/runner/work/Steam-Uploader/Steam-Uploader/packages/steam/redistributable_bin/linux64: /home/runner/work/Steam-Uploader/Steam-Uploader/packages/steam/redistributable_bin/linux64/libsteam_api.so /usr/lib/x86_64-linux-gnu/libcurl.so _deps/spdlog-build/libspdlog.a && cd /home/runner/work/Steam-Uploader/Steam-Uploader/build && /usr/local/bin/cmake -E copy_if_different /home/runner/work/Steam-Uploader/Steam-Uploader/packages/steam/redistributable_bin/linux64/libsteam_api.so /home/runner/work/Steam-Uploader/Steam-Uploader/build/bin
/usr/bin/ld: attempted static link of dynamic object `/home/runner/work/Steam-Uploader/Steam-Uploader/packages/steam/redistributable_bin/linux64/libsteam_api.so'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Windows build worked however

It completed

[steep zenith]

did you also include the .lib file with the program?

[dark yew]

The Steam files ? They are in the repo now

I pick them up from there

Those don't cause any issues, they are recognized

Here it failed bcs I statically linked the steam, and it failed on Linux

[steep zenith]

actually nvm, only windows has the lib file

[dark yew]

On Windows the process finished

[steep zenith]

yea so basically, can statically link steam api on windows (but still have to bundle the dll because it's "fake static") but on linux you can't statically link it at all

[dark yew]

lol, make it even more annoying

[steep zenith]

you can specifically tell linker to link steam as dynamic only, one sec

how are you adding steam api to the cmake?

[dark yew]

if (CMAKE_SYSTEM_NAME STREQUAL "Windows")
    set(steamworks_sdk_OS_ARCH "win64")
    set(steamworks_sdk_LIB_NAME "steam_api64")
    set(steamworks_sdk_LIB_EXT "dll")
elseif (CMAKE_SYSTEM_NAME STREQUAL "Linux")
    set(steamworks_sdk_OS_ARCH "linux64")
    set(steamworks_sdk_LIB_NAME "libsteam_api")
    set(steamworks_sdk_LIB_EXT "so")
else ()
    set(steamworks_sdk_OS_ARCH "osx")
    set(steamworks_sdk_LIB_NAME "libsteam_api")
    set(steamworks_sdk_LIB_EXT "dylib")
endif ()

# Use local Steamworks SDK directory
set(steamworks_sdk_SOURCE_DIR "${CMAKE_SOURCE_DIR}/packages/steam")

add_library(steamworks_sdk SHARED IMPORTED)

set(steamworks_sdk_LIBDIR "${steamworks_sdk_SOURCE_DIR}/redistributable_bin/${steamworks_sdk_OS_ARCH}")
set(steamworks_sdk_LIBFILE "${steamworks_sdk_LIBDIR}/${steamworks_sdk_LIB_NAME}.${steamworks_sdk_LIB_EXT}")
set_target_properties(steamworks_sdk PROPERTIES
        IMPORTED_LOCATION ${steamworks_sdk_LIBFILE}
        INTERFACE_INCLUDE_DIRECTORIES "${steamworks_sdk_SOURCE_DIR}/public"
)

if (CMAKE_SYSTEM_NAME STREQUAL "Windows")
    set_target_properties(steamworks_sdk PROPERTIES
            IMPORTED_IMPLIB "${steamworks_sdk_LIBDIR}/${steamworks_sdk_LIB_NAME}.lib"
    )
endif ()

set(steamworks_sdk_SOURCE_DIR "${CMAKE_SOURCE_DIR}/packages/steam")

Specifically

I think the rest I kept from your own method

[steep zenith]

the add_library having SHARED should make it a dynamic library...

oh wait, the issue wasn't steam

[dark yew]

Tho I've set this :

option(BUILD_SHARED_LIBS "Build shared libraries" OFF)
set(BUILD_STATIC_LIBS ON)
set(BUILD_TESTING OFF)

No the issue isn't Steam, it's just that it tries to statically link it now

[steep zenith]

wait yes it is I lied

[dark yew]

I'll just do some if win32 and shit

[steep zenith]

im still so confused on why its trying to statically link steam when I literally tell cmake its a SHARED library

which overrides BUILD_SHARED_LIBS

[dark yew]

alright testing locally and release
I've done:

if(win32)
        target_link_options("${CMAKE_PROJECT_NAME}" PRIVATE -static-libgcc -static-libstdc++ -static)
endif()

And

if(win32)
        option(BUILD_SHARED_LIBS "Build shared libraries" OFF)
        set(BUILD_STATIC_LIBS ON)
else()
        option(BUILD_SHARED_LIBS "Build shared libraries" ON)
        set(BUILD_STATIC_LIBS OFF)
endif()

A bit sus of a process but we'll see

Works locally

Builds on Linux

[steep zenith]

should probably either be static for both or shared for both, using different (like this specifically) is just weird

[dark yew]

Yea well that's clearly not the solution here aoqia so we're testing what worked previously lol

If there's a better method, we'll see later

alright built

Still not working

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

This is insane seriously

[steep zenith]

im going to build on wsl to see what I can do

[dark yew]

wsl ?

[steep zenith]

windows subsystem for linux

basically linux on windows

but ofc mingw is breaking it

[dark yew]

What's your plan with that ?

[steep zenith]

if it's working for windows but not for linux, i need to test linux

[dark yew]

uh ?

That's not the problem rn

It's not working for Windows, the release version isn't

Unless you're talking about the SHARED thing ?

[steep zenith]

yes the shared thing

make everything static, only make steam dynamic, thats best approach I think

[shut fiber]

I've been reading the whole convo and felt frustrated myself and I'm not even doing anything lol, hope you guys can overcome this 💪🏽

[dark yew]

What I don't understand is why it worked back then and why it doesn't now

[steep zenith]

this is one area where I envy literally every other langauage (even gradle) for it's build system

[shut fiber]

Wish I could help but all this is out of my scope 😅

[steep zenith]

because a lot of moving parts in the build system changed

works for me on WSL linux without mingw paths

[dark yew]

That's on Linux tho

[steep zenith]

I did change the cmakelists slightly, but not enough to completely make it work again

[steep zenith]

ill build on windows again too

[shut fiber]

Is the main issue you guys having with cmake? If so I do have a friend who use it regularly for work

[steep zenith]

it was mainly with the nature of dynamic/static libs

basically every lib included in it can be statically linked except steam api, because they didnt want to provide source code

[shut fiber]

Oh right I mixed some part of the convo trying to remember lmao

[steep zenith]

but yeah cmake is a pain, idk how people work with it professionally if they dont use vcpkg/meson/conan

[shut fiber]

I touched cmake one time, and won't touch It again ever 😂

[steep zenith]

@dark yew I think I will get it working currently, but you should probably switch to vcpkg soon and use the static triplet later on so that if you plan on adding any more dependencies it wont be as hard

[dark yew]

What would switching to vcpkg change ?

[steep zenith]

well peopel who want to build it themselves will need vcpkg, but from user perspective not that much

[dark yew]

Yea but how would that make our current shit show easier to manage ?

[steep zenith]

but you'd have to manually add steam sdk manually to build, not using CPM

[steep zenith]

in the future if you wanted to add more libraries it would make things less complicated

for example adding a large UI library like Qt

[dark yew]

I mean you suggested C# too, that's not something I'm going to look into now, but if it makes UI making easier, then I might look into moving the whole thing there idk

Idk anything about C# tho

[steep zenith]

c# would be easier for ui imo

for most things, and it's the first language I ever learnt

I am a bit rusty in it since I used it last, because I don't really make much UI cross platform stuff, but google and some tea should get you through it relative enough, and it's concepts are sort of kinda similar to c++ in terms of syntax

thats something for down the road though

[dark yew]

Yea

Rn I want the project in a stable phase, bcs the current changes you made aren't even out

[steep zenith]

build on windows work too

it probably has some mingw dlls still, I will check, but it builds and runs

[dark yew]

Alright, I can try your changes in the release to see if that works

[steep zenith]

yea its still using libwinpthread dynamically, but gcc and c++ dlls are in fact static still

[dark yew]

Nice

[steep zenith]

wait I might've lied, one sec

[dark yew]

[steep zenith]

this is really annoying, because it like constantly says "haha actually nooo"

IO've got a batch file that runs the exe with out any path stuff, so now I can test it without mingw getting in the way

[steep zenith]

holy shit I got it to work lol

[shut fiber]

https://tenor.com/view/yes-baby-goal-funny-face-gif-13347383

[dark yew]

Now the question is will it work in release

Bcs I didn't have the libs in my PATH and it worked when building locally but not in github release so uh

[steep zenith]

im going to test it some more

[dark yew]

I can add you to the repo so you can test release it if you want ?

Would make the process easier for you to not depend on me to test in release mode

[steep zenith]

its fine, as I said before release should be the exact same

I've made sure that mingw wont interfere with it, just have to see if I can make curl static (probably unlikely)

[dark yew]

I mean i've proven it isn't 🥲

[steep zenith]

I think you had some bad luck or something else system specific going on

I really cant say what was causing that, i'll never know

[steep zenith]

God if I had known of this beforehand... https://github.com/JosephP91/curlcpp

too far in the hole now! (well, not really, can always switch if wanted)

tl;dr is it's basically a more "c++ like" wrapper of curl, but it achives the exact same thing so not to worry about FOMO

[steep zenith]

@dark yew do you have a sec with your windows vm?

when you get the chance

[dark yew]

Yea I can test it

Give me a few sec

[dark yew]

It works

[steep zenith]

nice to know

[dark yew]

Want me to push your changes as a release to test it out ?

[steep zenith]

need to make some change first

[dark yew]

👌

[steep zenith]

I switched to vcpkg, so need to update the readme with guide on how to install that (its pretty simple, but might as well add at least a link to microsoft guide just in case)

and the runner should be uploading the cpack'd zip that it should generate (to do that is also in the readme at the build part)

[steep zenith]

Ok, I added some basic instructions to install vcpkg to the readme

still the release.yml needs to add using vcpkg (which is super easy, there are available vcpkg setup actions) and also the generated cpack archive and upload it.

[dark yew]

Are you doing or should I do it ?

Also idk what that cpack archive is and how it works

[steep zenith]

im going to sleep since its 5 am

[dark yew]

Yea makes sense

I'll see, maybe I'll look into it

[steep zenith]

cpack basically just packs the files in bin folder for you, so the zip is ready to upload for the runner

[dark yew]

It packs the libs too ?

[steep zenith]

The name template I've set currently ProjectName-Platform so it was for me SteamUploader-Windows.zip

[steep zenith]

yes

but I got everything else statically linking (barring steam sdk), so hopefully that shouldn't be an issue

[dark yew]

👌

[shut fiber]

@dark yew Hey Doggy what is the last working version of Steam Uploader 0.5?

I'm making a python script to use Steam Uploader with an interactive menu so is easily to use, got most of the code done and wanted to make sure which version would be the best to use
(Just a screenshot of the main menu)

[dark yew]

The pre release is a test (0.6 iirc), the Linux version of 0.5 has issues I believe but I need to get back to working on the soft to finally release 0.6

It'll work the same anyway so you can just go with 0.5 for now 😄

[shut fiber]

Cool ty

I was still using v0.3 but tried v0.5 and If I didnt mess anything up I'm getting this running the following command:
app -a 108600 -w 3543115938 -c C:\Users\xBerkth\Zomboid\Workshop\HandmadeWeapons\Contents
Sorry if the image looks weird used google translate images to show it in english

[dark yew]

I thought this was fixed in 0.5

Yea the app is in a shit state I guess ...

I really need to get back to it

[steep zenith]

is 0.5 an old one?

[shut fiber]

I'll stick to v0.3 for now to finish the script and if anything new comes up will add it

[dark yew]

I'll get to it soon

[dark yew]

It's the last release

Before the major refactor

[slim portal]

Now this is my kinda deal. I always suck with using things with no interface. Constantly forgetting the commands and needing to relook them up.

[shut fiber]

I'm almost done with it after lunch should be finished 👀

[shut fiber]

@dark yew @slim portal Quick question, how would you guys prefer to proceed with "Multiple Uploads" like you will get a list of what can be upload/update and maybe select them typing 1,3,5,6 for example then you will be getting prompts to do each step, after everything is done the command with all the parameters combined will execute 🤔

Also maybe instead of Multiple Uploads will change it to Multiple Actions not sure lemme know if you guys have any suggestion on the namings for the menu options

[slim portal]

I leave that to you and doggy, lol. whatever you think is best

[steep zenith]

in the refactor its traditional cli lol

but not yo worry, most clis including this one has a help command built right in, generally you can do -h or --help and it will show

I prefer to use long args because people including myself can see what it does because what the hell does -t -v -V mean instead of --title --verbose --visibility

[steep zenith]

oh ok makes sense. I was wondering why it was showing the args list in a format I haven't seen before lol

also queued uploads or actions would probably be suited better in a UI maybe instead of cli args directly, because its still doable in cli only but it makes the complexity a ton more for seemingly no reason

[dark yew]

Yea no need

Only in external app

I guess

Or UI yea

[shut fiber]

Well after reviving from a deadly migraine here is the script in case anyone want to use it (sorry if your eyes explode looking at the script but it works for me lol)
Later or in another moment will add the readme with instructions and stuff, probably will change some things but hey for now does the job
https://github.com/xberkth/Steam-Uploader-Menu/

[dark yew]

I'll check it out when I can

[shut fiber]

Pushed an update to refactor some code so now uploading a description works the same way as uploading a preview image using the file explorer, also added a README with instructions and stuff

[dark yew]

Alright going to look into aoqia's last changes

[dark yew]

@steep zenith
The static linking didn't work. I think due to

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE -static -static-libgcc -static-libstdc++)

Trying to link everything with -static

I'll go without the static linking and try that. Currently it works on Linux, going to test windows

[dark yew]

Can't test the build on Windows

It just won't work, and idk why I get no errors, nothing

It gets locked in an infinite loop, this was already a problem present before, I don't think it's linked to the current cmake process

[dark yew]

Ok only Windows side is failing:
https://github.com/SirDoggyJvla/Steam-Uploader/actions/runs/18246027170/job/51954086064

[shut fiber]

Oof windows being annoying chapter 3129814 😒

[dark yew]

It's been the main enemy since day one of this project

Linux doesn't even cause as many problems, everything works so smoothly

[shut fiber]

I remember compiling Aseprite long time ago and had some issues on windows when in linux was easier 🤦‍♂️

iirc uses cmake too

[dark yew]

I mean if I don't manage to make the CMake work properly I'm slowly going to go back to how it was before where I had a Make file for Linux and it was just command line shit for Windows

The project has been stuck like this for literal weeks now

And I'm just losing my motivation to work on the app for this simple fact

The errors you get when it fucking fails to build are so unusable it's insane

[shut fiber]

Yeah I'm not even the one making it and I do feel frustrated seeing you stuck on that shit lol

[dark yew]

Like wtf am I supposed to use this error log for

[shut fiber]

I was scrolling the error log on github while it was building and I was like what in the actual fuck is this 😂

[dark yew]

https://tenor.com/view/sisyphus-rock-mp4-transparent-color-gif-11114772717737196968

Just waiting for that yellow to become red

[shut fiber]

Oh man it hurts waiting for it to be red

[dark yew]

I'm going to try and look at the building process of v0.3.0

-static was used for Windows

Going to test with the CMake process for Windows, by adding -static just Windows

If it doesn't work, I'll try with the release command line for building the Windows one

Tho it's likely it won't work since the code depends on the CMake file a bit for some variables

[neon mortar]

even after all this time i've still literally never managed to run this program

[dark yew]

Which version ?

[neon mortar]

any version

[dark yew]

Uh

What problem are you having ?

[neon mortar]

depending on the version, either it doesn't build or it complains about missing dlls or it just doesn't work mysteriously

[dark yew]

The 0.3.0 version works

The build idk, since I only had a make file for the Linux process

But 0.3.0 is confirmed working

0.5.0 I had noticed it wasn't working on my laptop for Linux, idk for Windows

0.4 idk

[shut fiber]

Yeah I can confirm 0.3.0 works, is the one im using for the script (on windows)

[shut fiber]

For windows doesnt work either gives "libcurl-x64.dll not found"

[dark yew]

gawd damn

[dark yew]

Holy shit it built

[shut fiber]

YOOOOOOOO lets go

If you want me to test something lemme know

[dark yew]

I need to fix the zip and move part of the release now

[dark yew]

Did 0.4 work ?

[shut fiber]

Cant remember lemme check

Oh 0.4 works 👌

[dark yew]

Ok good to know, there wasn't much reasons for it not to work as there wasn't any structural change in that version

Getting there

Also marked the 0.5 as pre release since it's broken

[shut fiber]

Nice getting close 👀

[dark yew]

hit the 100th release

[shut fiber]

Lol haha

[dark yew]

I didn't find any better way for testing this shit than constantly trying to make a new release

[shut fiber]

Yeah honestly not sure if there's any other way than that at this point

[dark yew]

At the end of the day, CMake makes everything slower and just fucking hellish to make work

[shut fiber]

HOLY its happening

https://tenor.com/view/jesus-christ-pigeon-anime-gif-1779095387661407881

[dark yew]

Don't get your hopes too high, I still need to verify the app actually works LMAO

[shut fiber]

Well first step done haha

[dark yew]

There's some chance the library files aren't properly moved alongside the exe, if I missed some, like the curl one

But there shouldn't be much reasons for it to not work overall

[shut fiber]

Awesome

[dark yew]

If it compiles, most of the job is done

https://github.com/SirDoggyJvla/Steam-Uploader/releases/tag/v0.6.0

Alright, time to test that out

[shut fiber]

Lets test it

Curl coming in cluch

https://tenor.com/view/me-when-i-see-my-class-gif-15768348532634343334

[dark yew]

What does the error say exactly ?

Bcs it's likely it's the problem I mentioned

[shut fiber]

Yeah it is definetly

It says something like "Code execution cant continue because libcurl-x64.dll not found"

Oh another pop-up opens after the curl one (says same thing but with libwin)

This issue is more on the app side rather than building?

[dark yew]

No it's on the building side

It's a typical error that could happen

[dark yew]

Are you getting more after this one ?

[shut fiber]

No only those 2

[dark yew]

I'll push a new release with a potential fix for the curl one but not the other one for now, and while it releases that I'll look for the fix for the others

[dark yew]

Ok that's cool

Ok going to release with libwinpthread-1.dll and curl fix

[dark yew]

https://github.com/SirDoggyJvla/Steam-Uploader/releases/tag/v0.6.0

Should be fixed

[shut fiber]

😎

[dark yew]

👀

Can you try running the app with --update only ?

[shut fiber]

It is ouh yeah

Lemme try

[dark yew]

On Linux, it was just throwing me the help screen

So I think I need to fix something inside the code itself there

I thought I had fixed that but I guess not

[dark yew]

Yea I see

Well, I'll install a Ubuntu VM to test on a fresh Linux install

And if it works properly, then I'll mark this release as the new latest release

[shut fiber]

Cool 👌

Will test it with the script and see how it goes

[dark yew]

Alright seems to work fine

I'll mark this release as the latest stable release

[shut fiber]

Works like a charm, checked if everything updated on the workshop, mod content, etc and seems to work as it should

[dark yew]

Great !

You can use this version in your script without any issues since you don't need the auto updater in your script

[shut fiber]

Yeah will push an update but first need to fix clearing the console after a successful multiple upload for some reason it leaves some left over text from the prints 🤨

[dark yew]

Weird

I'll link your script on the README of the app too

Ok I think I see what's going on with the update thing

[shut fiber]

Previously had to do a workaround before because windows console cant handle clearing the scrollback buffer properly when the print for the command is to long that it prints a newline and it get pushed to the scrollback and after clearing the console to print the menu again it doesnt remove that 😅

I was thinking on maybe just removing the [Command] stuff but I like to see the full command executed 🙃

[dark yew]

Yea it's a nice feature

I love how this whole CMake thing made CMake disappear from my computer path lmao

[shut fiber]

Lol

[dark yew]

I don't even know how that happened

[shut fiber]

Well fixed the issue imma push an update real quick to update the .exe and some small changes

[shut fiber]

CMake went on vacation 😂

[dark yew]

I found the issue lol

I added the term export somehow in my PATH and it broke the last PATH entry which was cmake

/home/simon/Libraries/cmake-4.1.0-linux-x86_64/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/simon/.dotnet/tools:/home/simon/clion-2025.2/bin:/home/simon/Libraries/cmake-4.1.0-linux-x86_64/binexport:/home/simon/.config/Code/User/globalStorage/github.copilot-chat/debugCommand:/home/simon/clion-2025.2/bin:/home/simon/Libraries/cmake-4.1.0-linux-x86_64/binexport

[shut fiber]

Oh btw Doggy rn im refering to Steam Uploader in the repo description and at the credits on the readme you want me to add it somewhere else?

[dark yew]

It's good don't worry

As long as you give credit to what app it uses, it's good

[shut fiber]

Cool 👌

[dark yew]

I think I'll completely ditch the auto updater

Adds lots of complexity for not much reward sadly

I'll look back into it if I end up working on the UI

There will still be the warning when there's a new version anyway, and I added the repo releases link for people to do a simple click, then they can download the app again

[shut fiber]

Yeah understandable I mean downloading the new version instead of updating isnt a big deal so all good 👌

[dark yew]

Yea

Also it's not like I was updating the app every week

Steam Uploader v0.6.0

v0.6.0 doesn't impact much on the user side, mostly fixes previous 0.5.0 version which was non-working.
A bit of restyling for the console logs when using the app
https://github.com/SirDoggyJvla/Steam-Uploader/releases/tag/v0.6.0

[steep zenith]

uhmmmmm what

[dark yew]

Yes it's ugly

[steep zenith]

you know, vcpkg is supposed to get all the dependencies for you...

I saw you manually curling and choco the dependencies 😭😭

[dark yew]

Yea well I'm done fighting CMake

I completely ditched CMake for the Windows release

I've been at it for weeks

I'm done

I reworked the release.yml file to use the process from 0.4.0 for the Windows build and release process

Even on a fucking VM I can't make the fucking CMake work because it will just cycle endlessly in the build process, getting stuck I don't know where

It's not even showing a fucking error when it does that

It just fucks me and repeats constantly, never finishing the process

So I'm DONE with CMake here, I won't support it further myself

Maybe for Linux since it works for that

But Windows CMake can go suck my fucking dick

[steep zenith]

dont worry its pretty much universally hated among c++ developers

but it's also universally used across majority of c++ programs

I honestly admire Rust because of this, the language is harder but the setup for the package manager is literally just cargo init for project and cargo add <dependency>

[dark yew]

Why has no one found a better solution ?

[steep zenith]

there have been, but they either have some obscure limitations or they just werent adopted enough

ill try and fix the stuff in a fork

[steep zenith]

lets just say it has taken me way too long and it still not done yet, I feel deja vu lol

[steep zenith]

ok I give up lol, it's cooked

[shut fiber]

As Doggy said not worth the headache haha, fk that shit 😂

[steep zenith]

I got most of it working, just vcpkg triplet not changing from x64-windows to x64-windows-static despite me deleting all the caches in the runner and rebuilding like a thousand times

that and for linux/macos steamapi not copying properly, but I got macos builds to work :/

[shut fiber]

Oof getting shit to work on multiple plataforms is pain in the ass

[dark yew]

Yea I'm not adding macOS support I think lol

[steep zenith]

it already supports it, cmake is just the bottleneck basically

[dark yew]

Yea ik CMake has it, but considering I won't go break my skull on CMake once more, I'm not going to bother too much with it

Especially as testing for macOS is going to be pure pain + literally no one gives a shit about macOS, there's barely any people that mod on this thing, or even play the game in the first place

• Steam ditched macOS support anyway lol

Oh no it wasn't macOS what am I saying

That's the google chrome thing I think

[shut fiber]

Playing games on macOs is literally bricking your own brain imo (bunch of issues just trying to play a game aint worth lol) 😅

[steep zenith]

I remember trying to get someone to play minecraft on macos and I swear it nearly blew up

[steep zenith]

Btw I thought I saw you say you removed or are going to remove the auto updater? If that is the case, the curl dependency can be thrown out, then might as well add back CPM and ccache (I nominate myself to do all of that btw)

[dark yew]

We need it to retrieve the last update version

If I remember right that was my conclusion, bcs I did think about it

[steep zenith]

good point

[dark yew]

@shut fiber created a fork for Linux
https://github.com/SirDoggyJvla/Steam-Uploader-Menu

The tool is pretty cool ! I might try to rework it a bit to expand it and allow for Linux usage easier

[dark yew]

@steep zenith wait I don't remember, what was this needed for ?

Is that actually needed to use the Steam Uploader ?

[steep zenith]

to compile it yourself, this should only be under the BUILDING section or whateveri ts called in the readme

for developer only basically, not needed for normal people use

[dark yew]

Ok bruh

[steep zenith]

and if you dont use vcpkg at all, then its not needed at all

[dark yew]

Idk why it's in the Usage section

[steep zenith]

i was probably really tired when I put it there lol

but im not sure if you even use vcpkg if you replaced it or something

[dark yew]

I was so fucking confused, I'm recording a video on how to upload a mod and literally saw that in the middle of it and got soooo confused why that was there lmao

[steep zenith]

I had a look, still use vcpkg, but I don't get why curl is in packages/curl when vcpkg will include curl automatically for build

[dark yew]

Currently testing to make the app able to be ran from any folder

Should greatly help with using it

https://github.com/SirDoggyJvla/Steam-Uploader/commit/951fdf93de8471d2ec2e2fbe4ec31235bd74404c

[dark yew]

If anyone can test this version on Windows please
https://github.com/SirDoggyJvla/Steam-Uploader/releases/tag/v0.7.0

[steep zenith]

Should add a dry-run arg

[dark yew]

wdym ?

[steep zenith]

because I can test it since im in windows land right now but I dont have anything to upload

[dark yew]

You can just create an empty item

SteamUploader -a 108600 -n

Don't have any choice but to release/upload for proper testing

If I understand well what you meant by "dry-run" at least, I don't have any choice but to communicate with the Steam API at some point

Else you can also just try to do SteamUploader which opens the help menu

I tested it in a VM but there seems to be a problem with a lib or some shit ...

I suppose there were some other changes in the APP

[steep zenith]

which is something with gcc/mingw

[dark yew]

yup, that's the error I got

[dark yew]

From what I found about it yea, but I don't know what

Maybe I should try a re-release of 0.6 to see if that was already present

[steep zenith]

or maybe clock_gettime is a linux-only header im not sure

[dark yew]

Ok I'm slowly getting interested in Rust, notably to just learn it, but most importantly to see if their package handling is not dogshit in comparison to C++ 💀

I found this example from the steamworks implementation in Rust, and they have a full example of an uploader, and that looks really easy to use
https://github.com/Noxime/steamworks-rs/blob/master/examples/workshop/src/main.rs

That part tho idk how I feel about, because that will lose something from the Steam Uploader, but I guess maybe that's the time to move to a file to define properties of a mod

    // uploading the content of the workshop item
    // this process uses a builder pattern to set properties of the item
    // mandatory properties are:
    // - title
    // - description
    // - preview_path
    // - content_path
    // - visibility

[dark yew]

Ok I get how Rust's syntax can be weird

[dark yew]

there's two string types in Rust ? What da hell ?

[dark yew]

Ok I got a good concept now for SteamUploader in Rust, this time we ditch all the args and simply use a manifest file associated to a mod. This should makes things easier to manage but also nicely goes with the fact that the steamworks-rs doesn't allow individual parameters upload
https://github.com/SirDoggyJvla/SteamUploader-rs

Main thing missing rn is the creation of the appid.txt file

[dark yew]

Nvm done

[steep zenith]

yes

&str is a constant string type, think of it like a low level raw representation of the string

you cant do many ops on it, its really performant though, stuff like this

a String however is like a wrapper kind of around &str which lets you do many more things, but it's an object so its slightly less performant

[dark yew]

I see

Performance isn't too much of a concert in that app since it's very light by design anyway

I will possibly see to make a CLI for the app, maybe native to it, to manage mods

[steep zenith]

you can use to_string() or to_owned() on a &str to make it a String

[dark yew]

Yes I noticed that already

Also yea Rust's syntax is really freaking weird for a lot of things

Like it's a mix of C++ and TypeScript

It's pretty weird in their typings and hovering tho, like you hover a function and shit and none of it makes fucking sense, it's a mess of keywords lol

Thank god I touched typescript and C++ first

[steep zenith]

that is true

to understand shit like named lifetimes or whatever they're called like 'a or '_ etc you have to learn alot from rust handbook or rust by examole

its definitely a way more complex language than it needs to be imo, but id you just write simple application you don't need to use all these complex features

and yeah the syntax is an eyesore sometimes lol

im in the process of building a vulkan test application in c++ and I can't even get vcpkg to include the fucking libraries right now lol

[dark yew]

Ditch C++

[dark yew]

So easy to build it on Windows, hell yea

Now to test it out

There's still the dynamic packages of the Steamworks SDK that you need to manage sadly

Off to a good start, the app runs, now to test an upload

Now main problem, colors don't work in CMD lmao

Well shit, I might just need to ditch those

[dark yew]

@robust relic my life rn lmao

[robust relic]

I just saw the pop up for like 1 seconds

and made the meme

[dark yew]

Sadly I'm pretty sure we can't do dry runs on the Steamworks SDK

[dark yew]

My test uploads might have being flagged as bot uploads and are stuck in verification, so I can't delete them lmao

💀

ups

[dark yew]

Wait, isn't Make a thing on Windows ?

I forgot how tedious everything was on Windows 😭

Ok colors work in terminals that support them 💀

[robust relic]

in bash yes

[dark yew]

Wait what, why did colors not fucking work before lmao ? Does it not use ANSI for colors ?

[robust relic]

is that windows cmd?

[dark yew]

That's so weird to see the cmd use colors, like that sounds so fucking out of place lmao

That doesn't look normal at all, jeez they just love white on black or what the fuck Microslop ???

they can use colors in that fucking shit ????

[steep zenith]

they should hmm

oh nvm you got it working nice

[dark yew]

Yea I guess it's no ansi for colors in cmd, idfk I just swapped to a different library for the color handling lmao

[steep zenith]

just dont do the uploading part

[dark yew]

Yea I went with that; by simply stopping the uploads or creation of items to verify that the manifest is properly parsed

[steep zenith]

usually dry run is just to verify you got information correct. so if the user gives the dry run arg, just print all the relevant information so they can look at it and go "that looks ok"

[dark yew]

Not exactly what I would have liked but that does the job

[steep zenith]

BTW you shouldn't need to use mane

make*

I believe you can write build scripts in rust too

[dark yew]

You mean cargo ?

[steep zenith]

yea

like you can write scripts that run when you build

so like copying files and stuff, would be super easy

[dark yew]

Tbh the make is just copying cargo, but you can build with just cargo

I still went with the explanation of using the Make bcs I expected Windows to be intelligent but forgot it fucking isn't 💀

[steep zenith]

you know you can do cargo run and it will run it 🙂

[dark yew]

I am well aware

I am aware of what the basic cargo stuff do, build, run, clean

I didn't knew cargo basically did what make does tho

[steep zenith]

https://doc.rust-lang.org/cargo/reference/build-scripts.html

[dark yew]

Tbh one of the reasons I went with Make anyway was to easily keep track of the different args for cargo on how to things. I haven't looked at what release does yet tho

Oh yea release is a proper build

Like optimized

[steep zenith]

release just provides a more optimised build faster and no debug symbols etc

[dark yew]

Yea

I just remembered that

But I guess for the github action for release I should straight up use Cargo, so I don't have to make some shitty chocolatey Make download

And I suppose Rust is natively in the github actions for Windows ?

[dark yew]

Thanks that's interesting

    // Tell Cargo that if the given file changes, to rerun this build script.
    println!("cargo::rerun-if-changed=src/hello.c");

Idk how I feel about that one lmao

Anyway I probably won't need any build script

[steep zenith]

you need a set-up rust tool chain action

[dark yew]

I see

[steep zenith]

and probably either it caches the packages or use a cache

https://github.com/marketplace/actions/setup-rust-toolchain-for-github-ci

[dark yew]

Thx

[steep zenith]

this one automatically caches dependencies i believe, there's a cache var you can set

[dark yew]

wdym it caches dependencies ?

[steep zenith]

like packages

so the runner doesn't have to redownload and recompile it

[dark yew]

Wdym ?

Between actions ?

[steep zenith]

yes

[dark yew]

How tf does that work ? Aren't actions supposed to be in their own like machine instance or some shit ?

[steep zenith]

yes but machines can save outputs and stuff

in the actions you can view caches there on the left somewhere

[dark yew]

Interesting

Rust is so easy to use god damn

Just a bit cursed in its syntax, but that's about it

[steep zenith]

yea

[dark yew]

Hmm having problems with the .so ffile for steamworks sdk

When releasing via github workflows, the released binary cannot find the so, only the locally built version

Problem comes from the binary, probably a difference in how it is built in workflows and locally

[dark yew]

@steep zenith just for the heads it
It was a problem with the Rust toolchain you provided which forces the rust flags to whatever, which overrides the configuration inside .cargo/config.toml

So I have to force the rustflags to "" so it uses the config of the project

      - uses: actions-rust-lang/setup-rust-toolchain@v1
        with:
          rustflags: ""

That's kiiiind of bad 😅
I'll see if there's an alternative later

[steep zenith]

what? why are you setting something in .cargo/config.toml?

like what is your intention with that

but yeah you're right in that it will change them, I just dont know what you need to change the flags for

[dark yew]

It didn't work without it, to my understanding bcs it doesn't link to the Steamworks SDK

[steep zenith]

oh you're manually linking to it I see

EDIT: ignore me

[steep zenith]

also its great in rust how there isn't 3+ different ways to initialize variables lol unlike c++

[dark yew]

Steam Uploader reworked in Rust

https://github.com/SirDoggyJvla/SteamUploader-rs/releases

I had some fun reworking my old tool Steam Uploader. That tool was very hard to manage to compile correctly while here the Rust aspect of this rework makes it very easy to manage.

Mod manifest file

Previously, the tool used purely CLI commands to indicate what to upload. Here this concept was ditched by instead requiring a simple mod-manifest.json file (can also be .yaml, .yml or .toml). This file can be stored anywhere but it's best to store it alongside your mod.

In the case of Project Zomboid, that manifest file would be stored in the folder which holds the workshop.txt file and it would have the following default structure:

{
  "$schema": "https://raw.githubusercontent.com/SirDoggyJvla/SteamUploader-rs/refs/heads/main/manifest_schema/mod-manifest-schema.json",
  "appid": 0,
  "content": "./Contents",
  "preview": "preview.png",
  "title": "Mod Template",
  "description": "./description.bbcode",
  "visibility": 2,
  "tags": []
}

One disadvantage of the steamworks-rs which is needed to make all of this work in Rust is that it didn't implement 1 to 1 the Steamworks SDK process to upload content. Previously, you could upload just the description, preview, tags etc, but now you have to upload everything at once.

Documentation

You can find documentation on how to use the tool here and what each parameters of the manifest file are for:
https://github.com/SirDoggyJvla/SteamUploader-rs

[meager stream]

]$ ../SteamUploader upload
Loaded JSON manifest successfully.
[S_API] SteamAPI_Init(): Loaded '/home/rinoa/.local/share/Steam/linux64/steamclient.so' OK.
Setting breakpad minidump AppID = 108600
SteamInternal_SetMinidumpSteamID: Caching Steam ID: 76561197990716172 [API loaded no]
No workshopid found in manifest. Creating new workshop item...
Error creating workshop item: Timeout waiting for workshop item creation

Urm

Is the workshop broken right now? :X

@dark yew forgot to notify

[meager stream]

nvm, Steam itself said it had "No Connection" at its bottom

restarted the client...

[dark yew]

Did it work ?

[dark yew]

CLI menu, will expand this to implement a manager that can be used from anywhere

[dark yew]

Steam Uploader 0.2.0

Added a CLI menu to not need to type commands and arguments. Should make it easier for users to use the app.

https://github.com/SirDoggyJvla/Steam-Uploader-rs/releases/tag/v0.2.0

[dark yew]

Jeez, Rust is so freaking hard

[steep zenith]

certainly

is there anything specific about it? im no expert with it at all, but maybe I can help

[dark yew]

Tbf it's likely the things I found hard are also present in C++

Was mostly about making a vec and inserting at the front of it

Doesn't look like there's anything straight forward to do that but eh, I can easily go around it for my application

[steep zenith]

yeah thats fair, but all things considering you're getting hang of it really quick

certainly helps that you dont need to spend 100 hours on your CMakeLists.txt just to get the project set up 🥲

[dark yew]

Definitely, that's insanely easy to manage rn

[steep zenith]

also you should just be able to do something like:

let mut my_vec = vec![2, 3];
println!("{:?}", my_vec); // [2, 3]
my_vec.insert(0, 1);
println!("{:?}", my_vec); // [1, 2,3]

[dark yew]

wait insert is a thing ?

[steep zenith]

ya

but maybe if you do insertion at front a lot definitely dont use vector

because it is O(n) every time

maybe you want a better thingy like:

let mut deque = VecDeque::from(vec![2, 3]);
deque.push_front(1);

[dark yew]

The way I needed that wasn't for large amount of inserts, but that's good to know

[steep zenith]

a queue/deque is more efficient for pushing to the front (than a vector, because its now O(1) instead) but its less memory efficient I think

[dark yew]

I can see why

[dark yew]

The syntax can be weird, but I find it so freaking pleasing this method of running things:

            let workshopid = inquire::Text::new("Workshop ID to delete:")
                .prompt()
                .expect("Failed to read input")
                .parse::<u64>()
                .expect("Invalid Workshop ID");

Like it's so clean and clear what this does