You don't need to ship a shared library in order to compile an executable that dynamically links to said shared library. You just need the header files listing the shared library's exported symbols. You can treat Cocoa like any other closed-source blob of a vendor library.

I the context of CI, what’s the point if you can’t run tests?

If the application is well-structured, you can run many types of tests without ever touching the UI. You can also run things like linters and static analysis tools (although those are usually platform-agnostic).

Seems like if linked libraries weren’t present, GUI or no, it would be problematic. Im a hardware guy though so not much experience with that.

This isn't my exact area either, so my terminology is probably off, but one way to do this would be to compile the "backend" code separately and run unit tests on that. Treat it as a library in your application, if you will.

Another approach I've heard used was just faking the library from the headers - as long nothing from it is called in the course of your testing, your program wouldn't notice.

I think the Google vs. Oracle lawsuit might put a wrench into this logic.

If the outcome of that lawsuit goes that way, basically all OSS is gonna become illegal, so I think this might be the least of our worries... :(

> Oracle’s lawyers wrote. "The next Oracle will think twice about investing as heavily in a venture like Java if it knows that any competitor could freely copy its work to compete directly against it."

It would make me terribly happy if Oracle would refrain from doing so. I think this case is ridiculous. The same developer implemented a range check in the same way he did 10 years ago. Yes, copyright for software is broken...

And the lines in question were even removed, which is a tragedy itself, but I cannot see Oracle as anything but hugely detrimental to software. Developers should ignore anything they touch.

If they do indeed rule in favor of Oracle, it wouldn't be undermining OSS, it would undermine the whole judiciary system. It would be scientifically proven bullshit.

  private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
     if (fromIndex > toIndex)
          throw new IllegalArgumentException("fromIndex(" + fromIndex +
               ") > toIndex(" + toIndex+")");
     if (fromIndex < 0)
          throw new ArrayIndexOutOfBoundsException(fromIndex);
     if (toIndex > arrayLen) 
          throw new ArrayIndexOutOfBoundsException(toIndex);
  }

Suppose it is a programming language runtime, a database, an app server? Many of those get ported to Mac, but very little (or even none) of their code needs to talk to Cocoa, since they are mostly headless server components (or have CLI interfaces only).

Why port that kind of stuff to macOS? Obviously it isn't going to be the deployment platform, but developers will want to run that stuff locally during development. (Less important than it used to be with the popularity of Docker on Mac, although still it can be a bit more developer-friendly to run things directly on macOS instead of under Docker.)