bflattened / bflat

C# as you know it but with Go-inspired tooling (small, selfcontained, and native executables)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

macOS support?

trufae opened this issue · comments

I see only linux and windows builds in the release page, are there any plans to support macOS too?

No macos plans. I would have to pay apple to a) get a mac so I can build and test it, b) get a "developer account" with a recurring yearly fee so that apple doesn't flag bflat malware.

No need to have a developer account to develop or distribute software on mac, there's brew, and you can always ask users to trust the signature you create in local, the only need for this, is when you want to push it to their appstore, which i guess you won't because i dont see bflat in windows store either.

you can use a mac CI for fere in github CI, and it's also possible to run macOS on a VM or even run XCode in Linux if you copy the SDK files. apple dont flag software as malware, there's no antivirus included in the system. it's just up to the users to choose what they accept or not to run.

i would love to have bflat on mac, and i barely have spare time to work on more projects. but if you give me some pointers about how to build on linux and challenges/dependencies/requirements i can give it a try and make a PR that builds all that in the CI

No macos plans. I would have to pay apple to a) get a mac so I can build and test it, b) get a "developer account" with a recurring yearly fee so that apple doesn't flag bflat malware.

I’m willing to buy you the Mac and sponsor the developer fee if you can add this to the roadmap.

Thank you but at the end of the day generating executables for macos requires collecting random files from an xcode installation like so: https://github.com/tpoechtrager/osxcross#packaging-the-sdk (with a big "read the Eula, this is all on you" warning). It's fundamentally incompatible with the no frills approach to crosscompilation that bflat has. Apple doesn't want anyone to make software for their platforms without paying Apple first. I honestly don't know how an apple targeting bflat would work.

Might be worth looking at how Go does it. I write plenty of Go, and use plenty of Go programs on macOS, without any Xcode funny business.

Might be worth looking at how Go does it. I write plenty of Go, and use plenty of Go programs on macOS, without any Xcode funny business.

Go doesn't call into any OS functionality because it just rolls its own version of everything. In .NET one can't even make a https request without calling into OS-provided crypto frameworks. Go with CGO would be a better comparison and I don't think that one works.

I see, thanks. Maybe a bounty could be opened for this, I might be willing to throw some pennies in at some point. Love the project.

Avoid Bountysource though!

I see, thanks. Maybe a bounty could be opened for this, I might be willing to throw some pennies in at some point. Love the project.

Avoid Bountysource though!

I'm not looking for someone to contribute this. In the end I'm the one who will have to maintain it. Apple has the worst track record of any os vendor when it comes to compatibility. They drop bombs every year and expect everyone to bend over for whatever the new thing that breaks everything is (I see this in the dotnet/runtime issue tracker all the time when new xcode or macos drops). Replicating pieces of xcode will definitely break every year due to code signing, entitlements or whatever new thing apple invents to help user privacy protect their profits. Bflat is a project I do for fun. Doing anything on apple platforms is work. Making this feel like work is guaranteed to make me lose interest in this. It's a hard no, I don't know how else to say this.

That's a shame. It sounds like you have a personal vendetta against Apple. That's perfectly fine, it's your project.

Keep up the good work regardless.

Looks like cultural decision rather than pragmatic, unless concoctions of tools this project rely on isn't support macos, but they rather do.