Closed ttytm closed 12 months ago
I already taught about adding the debug version to the CI build output. Good that you bright this on.
Is dist/webui-2.dll
and dist/debug/webui-2.dll
can solve the issue?
Nice 🙂
Yes, it's no problem to fix it. The final change includes the updates necessary for the workflows and examples. I just thought to ask before making all changes if it's good to continue :+1:.
I mean, yes, it's good to continue, but I suggest keeping the file name the same, but simply add a debug
folder inside the dist
folder. dist/debug
. If it's not possible then we can add -debug
to the output file name.
I see. That's good. And it should work!
What do you think about shipping both in then in the releases and artifacts instead of separating them there
webui-linux-gcc-x64.zip
├── debug
│ ├── libwebui-2-static.a
│ └── webui-2.so
├── include
│ ├── webui.h
│ └── webui.hpp
├── libwebui-2-static.a
└── webui-2.so
something like this?
Maybe this is event what you mean by saying
I already taught about adding the debug version to the CI build output.
Because we actually already have Debug builds in the CI output. https://github.com/webui-dev/webui/actions/runs/6105660238
What do you think about shipping both in then in the releases and artifacts
Yes, that what I meant 👍 one archive for both release and debug
Testing the changes during the integration already feels like this change makes a lot of things simpler. So I feel reinforced that this is a good step to take.
The commits could have been split more fine grained, as they contain some other small fixes. But I hope until we have arrived at a new stable version some crammed up commits are okay, mainly due to time reasons.
Using a distinct file for debug builds would simplify some things imho. There are a bunch of cases where it makes sense to have both files side by side.
If you also see value in this, I'd finish it here.