new dependency on pthread-embedded about pspsdk HOT 11 CLOSED

I understand the motivation, but our SDK is not really responsible for keeping backward compatibility with custom personal implementations.

I'd suggest @rofl0r to fork any PSP SDK repos he needs to customize and keep the changes there. (also, could keep a personal fork of an older version before the newlib 4.4.0)

from pspsdk.

aren't most changes here changes that benefit mostly the one that came up with the change to begin with ? for example, bucanero recently changed the startup code so his C++ stuff works.

demeaning (e.g. "aka dropping support for anything else", "that commit is big enough as is.")

what is demeaning about this ?

arrogant (e.g. "and losing me as a contributor to pspdev")

and what is arrogant about this ?

now i feel offended, especially since you just voted to be more welcoming and inclusive by installing a CoC. it's your attitude here that is demeaning. you should be more welcoming regarding other people's diverse opinions.

from pspsdk.

this specific statement comes off very passive aggresive:

well, i might have been a tad frustrated because i had just spent half a day to reverse engineer the needed changes for my toolchain to stay compatible with master (i feared that moment would come in the moment i saw the newlib 4.4 commit.... the main reason to update was the commit that inlines the GU commands in the hope that my app would become faster, but since it made whitespace changes all over the place i opted for a general update instead of backporting the patch cleanly)...

anyway you guys couldn't have known that there are people out there using the patches and the sdk with custom gcc versions. but despite the frustrated undertone, it was never my intention to start a flamewar. i was honestly surprised about some of the reactions.

this sound like you're saying we don't know what we're doing

quite the opposite of what i'm thinking. as a long time contributor to musl libc i was impressed when i first stumbled about this organization's skillfully written makefiles, and especially the clever way newlib interacts with the sdk.

anyway, with that out of the way, i would very much welcome if we could get back to the technicalities.

from pspsdk.

Glad we speak the same language now. I'll take a look at the PR. Next time try to pick a friendlier tone or wait for the frustration to go down a bit, then we'll gladly help you out.

from pspsdk.

the culprit is this commit 8a0ab6b , written in 2021, but merged somewhere after march 2022, which was the checkout i've been using ( cc887d7 ). i wouldn't mind having the pthread support, if it wouldn't involve cloning yet another repo from git and figuring out how to integrate it into my automated build process. can't you just put the missing few files in here ? that commit is big enough as is.

from pspsdk.

Pthread embedded was moved at toolchain level instead being a port as I was before, in this way we can use std threads from CPP.
I don’t have anything against your PR, but the fact you have your owns scripts to compile the toolchain not sure if actually makes sense, would be better to understand why you require to have your owns script in order to see if we miss something or we can improve the processes .

from pspsdk.

ftr, my toolchain lives here https://github.com/rofl0r/newlib-cross
it supports old gcc versions which are good enough for my purpose (C99 only) and take up only like 30MB of harddisk space and moderate memory consumption vs the recent C++ monsters. also the requirements of installed dependencies are minimized, and the entire toolchain builds in like 5 minutes.

from pspsdk.

oh, i forgot to mention that i use my own linux distro based on musl libc, that means i often need additional patches for binutils, gcc, etc to get them to compile, unlike on a glibc host.

from pspsdk.

our SDK is not really responsible for keeping backward compatibility with custom personal implementations.

the toolchain produced is identical from an ABI/API pov, using the same patches and components.

I'd suggest @rofl0r to fork any PSP SDK repos he needs to customize and keep the changes there. (also, could keep a personal fork of an older version before the newlib 4.4.0)

we're talking about merging a 5 line change nobody else will even notice vs me getting a new half-day job as maintainer of 50 forked repositories (and losing me as a contributor to pspdev). besides, i already got the support for newlib 4.4.0 working (apart from several issues that are in that port)

from pspsdk.

Have you considered that your attitude here might be why this "five-liner" is being debated? It is very difficult to justify accepting a change that will only benefit one person where that person is also being demeaning (e.g. "aka dropping support for anything else", "that commit is big enough as is.") and arrogant (e.g. "and losing me as a contributor to pspdev").

from pspsdk.

@rofl0r this specific statement comes off very passive aggresive:

before newlib 4.4.0 "support" was added (aka dropping support for anything else)

We had a good reason to make this change and this sound like you're saying we don't know what we're doing. That's why you're getting some backlash here.

from pspsdk.