I’m hitting an assert on Thread::setCurrentAffinityMask, because CPU_ISSET is not set.
Where is it supposed to be defined ?

It’s a linux macro, but isn’t included in all distros, so I disabled the affinities if it’s not available.

Perhaps you’ve got it, but it’s not being included - maybe try grepping your include dir for it?

Well, the assert fired on the Mac emulator. Is it defined on Mac ?

No, I think it’s only there on linux, not BSD.

Well, XCode’s debugger (it’s a strange version of GDB) stops on juce_posix_SharedCode.h:750. It’s definitively a Mac here.
The code reads:

    /* affinities aren't supported because either the appropriate header files weren't found, 
        or the SUPPORT_AFFINITIES macro was turned off

// And the definition looks like this (20 lines above):
#if defined(CPU_ISSET) && !defined(SUPPORT_AFFINITIES)

If I grep the source code for CPU_ISSET that’s the only references.
So I guess building on Mac require setting this macro so we can get affinities support, or at least, the #else part should read #elif !defined(JUCE_MACOS) not to trigger the assertion.

There’s probably a completely different mechanism for affinities on the mac, I’ve never looked into it…

Well, you’re right, it’s not supported(from developper.apple.com documentation) : “Mac OS X does not export interfaces that identify processors or control thread placement-explicit thread to processor binding is not supported”.
Well, at least please don’t assert in that case, so it doesn’t stop the process.
This removes the ugly #if !defined(JUCE_MAC) in our code.

No… I think an assertion is totally justified in that case - if you’re porting an app to the mac, you’d want to know if it tries to do an operation that’s not supported. Just because in your case you don’t care whether it works or not doesn’t mean that nobody else cares either!

So, finally, the software is undebuggable, since it stops when the operation happens, if I don’t put the call to the operation inside “if not mac” preprocessor block.
I would have preferred a message to the output debug console, but not stopping, since it’s not an error we can solve on our side (user side), unlike other asserts.
This is called vexing assertion (like vexing exception).
Or at least put a “attribute warning(“Not supported on MAC”)” on the function declaration on Mac, so it appears on building but doesn’t trigger runtime assertion.

I think the query above is worth a look, when something is not implemented, you should use the “__attribute((warning(“Not supported on MAC”)))” so it appears at compile time, and not at runtime.
That’s the second time I hit a platform discrepancy, and it’s a pain to figure them out in run time (since I don’t test all the functions, and all the cases each time).

The attribute above on the function declaration gives a useful warning message on GCC, where each invokation points are listed (so you can’t forget one, instead of the runtime test where you’ll probably miss many).

Yes, fair point, a warning would be best there.