FreeBSD Support

I’ve begun getting my fork of juce_core working in FreeBSD. I copied juce_linux_Files, juce_linux_Network, juce_linux_SystemStats, and juce_linux_Threads and made bsd versions.

sysinfo() is not really available under BSD, so you’ll need to crib this function and associated header:

_NL_IDENTIFICATION_LANGUAGE seems more of a Linux extension. It is not available in FreeBSD.

Planning on a PlayStation 4 port :slight_smile: ?

I rather not contribute to anything that is Sony related. I’m working on Beast, which is a replacement for Boost. It comes with the juce_core module as well as the core/concurrent code from VFLib. It stands alone though, you don’t need JUCE or VFLib. It is a fork of JUCE, I renamed almost everything.

Much how JUCE is incredibly useful for building audio GUI applications and plugins, Beast is designed for interface-less high performance Internet servers. Specifically, peer to peer applications that make heavy use of cryptography such as Bitcoin or Ripple.

Currently, these types of applications are a mess because they need to include some very ugly external dependencies like Boost and OpenSSL. My hope is to wrap up all this functionality in a single library that, like JUCE, compiles cleanly without a complex build system (like autoconf) and uses a unity style / modules build.

Beast will incorporate things critical to peer to peer applications like LevelDB (key/hash database store), Google’s protocol buffers, and a lot of cryptographic primitives (courtesy of Wei Dai’s CryptoPP library).

Here’s a peek at the repository. Note it is by no means finished or even ready for use (although it is currently being used in Ripple)

Very cool.

I wanted to actually write something for the PS Vita i bought (just to play Wipeout), but Sony made the SDK in C#, and i’m not opening that box of nightmares. Shame.

Very cool indeed.

…I do wish you hadn’t swapped all the “juce_” prefixes to “beast_” though! That’ll make it almost impossible to diff the two things and see what’s changed - so I won’t be able to merge any of your BSD changes, and you won’t be able to pick up on any of my future bugfixes!

While your at it, would you consider adding support for all those big commercial UNIX systems. I always wanted to write a monitoring system that would work the way it should (not like all the big stuff out there, that impacts performance while monitoring and needs to be monitored, it’s a disaster).

Anyway i never could get JUCE to compile on at least Solaris (it’s the most “open” of the UNIXes i know), but it would open a big market Oracle - Soalris, IBM - AIX with the Linux support already there you could really do something and maybe i could actualy do that monitoring application.

Where is your project heading in terms of platforms ?

I agree, it was difficult to make that decision. Initially I decided to keep the prefix but this will be quite a hard fork. I also don’t want to even pretend that there will be a “juce_*” module inside beast that will be in any way compatible with JUCE.

As for the BSD changes they can just be manually applied, there shouldn’t be too much of it. If you want JUCE to work on BSD you have to compile it in that environment on a regular basis anyway - its quite the oddball of a system. They do everything their own "special "way.

Yes, exactly. There is simply NO decent C++ general purpose library for writing command line tools or these types of applications you describe.

Well for now it’s being used in FreeBSD, Ubuntu and other Linux distros, Windows, and Mac OS. I can only realistically maintain it for the platforms that it gets used on. Bitcoin and Ripple platforms to be specific.

juce_isRunningUnderDebugger needs to simply return false for FreeBSD, because of the difference in behaviors of ptrace: