Cool VL Viewer forum

Building Cool VL Viewer on my ~2012 Macbook Pro (running Sonoma by using OpenCore Legacy Patcher) takes maybe between 15-20 mins. I usually start it and do something else, so haven't collected more precise times. It's dead simple to do. I have tweaked my build parameters a little, since I am using Xcode 15, but otherwise I just run the included ./macos-build.sh and away it goes.

What tweaks do you need ?... I only could test the build with Xcode 12 and 13, since newer versions require macOS versions that cannot run in a VirtualBox VM under Linux...

I adjust the following, in linden/indra/cmake/Variables.cmake:

• set(CMAKE_XCODE_BUILD_SYSTEM 15) - for Xcode 15
• # set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "") - this has to be commented out for Xcode 15 but I have lost track of why
• set(CMAKE_OSX_DEPLOYMENT_TARGET 14.6) - for my current OS version level

Since they are relative to my one and only Mac, I never brought it up in the forums and I'm not a savvy Mac builder. These options allowed me to build and were largely obtained with a little trial 'n error and Googling.

Well, among those three changes, only the commenting out of CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY seems to be relevant...

CMAKE_XCODE_BUILD_SYSTEM is 12 for anything equal or above Xcode 12, so setting it to 15 would be irrelevant (it only influences how cmake generates its project files).

CMAKE_OSX_DEPLOYMENT_TARGET is also irrelevant: it should be kept to the minimum deployment target for the built binary, and anyway all pre-built libraries are built with that minimum target, so trying to raise it just for the viewer binaries is largely pointless (the same legacy library functions will be used anyway, since they got linked already in the libraries).

I will see what can be done around CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY, since it was needed for Xcode 12 and 13, at least...

Ah, OK. My bit of trial and error along with my lack of understanding of the Mac OS/Xcode build systems resulted in those 3 changes. Probably depends on the order I did/searched for things. I made assumptions on their 'need'. Next time I build I will see if the commented line is all that is required. It's also good to know about the minimum target version and the linked libraries too.

I reverted back to the stock Variables.cmake and when not commenting out the empty code sign line, I get:
The other options I was tweaking might have been me carrying over behaviors I did before the minimums in the file were updated? I likely didn't understand and just kept doing them. Since they just worked, I never questioned.

For next release, I changed the line for:

Which should hopefully work for all (known) Xcode versions...

TL;DR — All right, as usual, Henri, you were 100% correct

I've finally managed to compile 1.32.2.8 on macOS Big Sur 11.7.9 on a 10-year old quad-core MacBook Pro, using Xcode 13.2.1 (Apple's clang version 13.0.0), and Homebrew-based Python 3.12.5 and CMake 3.30.2. Nothing else was needed or required!

There were only two things worth mentioning, for anyone trying to attempt the same feat. And here's where the post becomes too long for casual readers:

1. Xcode 12? While I had long ago removed Xcode (I just need the command-line tools for 99% of my needs, and I never liked Apple's IDE anyway), I'm pretty sure I had the "latest" version of the Command-Line Tools 12 installed. So it made sense for me to get Xcode 12, and I've used the link you provided.
   
   Unfortunately, either due to my lack of knowledge or something, there was no way I could open the package downloaded that way. Fortunately, though, I've got an Apple Developer (Basic) Account, which does not entitle you to any kind of license or signature or anything, but it does give access to the vast vault of software that Apple ever released for free, and that goes back at least 10 years, if not 15. I had no trouble in locating Xcode 12.5, and installing it was a breeze.
   
   However, using Xcode 12, I couldn't do compile the whole code successfully. A lot of the individual files did compile correctly, but when linking everything together — boom, the linker would fail, and it would complain of unknown symbols all over the place — including those on its own libraries. This should have raised some alarms in my head, but the truth was that it failed to register.
   
   Then, while attempting to read a bit of the documentation, I went back to linden/doc/macOSBuildHowto.txt. And it addresses precisely this issue on its very first paragraph, which I quote:
   

   	Quote: A.- Requirements To build on macOS you need Xcode 12, 13 or 14 (get it from the App store or the Apple developer site) and therefore macOS Catalina for Xcode 12, Big Sur for Xcode 13, or Monterey for Xcode 14 (the target system/SDK is set by the viewer build scripts to v10.13, so the resulting viewer binary should nonetheless be compatible with macOS High Sierra or newer Mac systems). When building with Xcode 13+ you get some more link-time warnings due to a few badly targetted libraries (too old a build target); these are harmless.

   
   I thought that this was a typo somewhere. Big Sur, being 11.X, should have Xcode 12, not 13; Monterey, being 12.X, should have Xcode 13, not 14; and so forth. Right?
   
   Well, no — completely wrong assumption regarding versioning! The Xcode version hasn't been "in sync" with the macOS version but had its somewhat unique and cryptic numbering (I've heard that now it's back in sync!), because Apple started to number the versions 10.0, 10.1, etc. until Catalina, which was 10.15, and Big Sur became 11 instead. I'm sure they must have skipped a few, since the idea would be that the Xcode version ought to be aligned with the minor version number. This was clearly not true for Catalina. And for Big Sur, well, Apple just renumbered things again, and the result is that nothing matches
   
   It was just a stupid, wrong assumption of my part. I had just retained Xcode 12 because, well, probably the last time I worried about Xcode was when I was running Catalina, eons ago. When I've upgraded to Big Sur, I never thought of checking if there was a more recent version of the Command-Line Tools. And probably I wouldn't get them, anyway (one of those Apple quirks... if you're EOL, you're EOL, period, even if there might be more recent versions).
   
   Anyway, I located Xcode 13.2 on Apple's repositories (13.2.1 to be more precise), because for some reason this was mentioned (where? I can't remember) as being the more "tested" version for compiling a SL-compatible viewer on a Mac under Big Sur... even though there are more recent versions of the 13 series (up to 13.4 I think, but I would have to check again), as a matter of fact, according to Apple's release notes — which I only found later — 13.2.1 is the last version that still runs on macOS Big Sur (I tried 13.4 and it clearly didn't work!).
   
   That versioning method drives me insane! Especially because, of course, the release notes are found on a different place than the actual package downloads (it took me some time to figure that out), and more often than not, on their main repository, Apple is not very fond to go into details for each package listed there. Sometimes they list the versions with which things are compatible, sometimes they don't, and it's up to us to figure out what the release notes actually say.
   
   It's also insane to change the OS requirements on a minor version! Clearly, Apple has never read anything about semantic versioning... or, more likely, they don't care. After all, they're the ones that have released an operating system every year, for fifteen years, all labeled 10.X. All that because this was supposed to be MacOS X (the tenth version, that is). I wonder — what's with those Silicon Valley guys and this obsession with the letter "X"?
   
   Anyway... I didn't get a successful build. Not yet. But at least the linker just complained about two missing references, and I thought, well, just changing two might be within my abilities (hah! Nothing like being overconfident! ).
   
   So, since that meant looking deep into the code, it also meant copying the current release, create a Git repository on my sort-of-private-but-not-totally-so self-hosted Git repository server, do all the commits and push everything into there, and get ready for changing (and breaking) things — the point being that Git will then handle the patches/diffs automagically, of course
   
   While doing so, I used my favourite code editor, Nova (from Panic, a very respectable small Mac-only software house, going back two or perhaps even three decades) — which is not really "just a code editor", obviously. It's similar to VS Code (not compatible — just similar), but it's a native application. That means it's small (small for what it does, obviously), blindingly fast, and, well, flawlessly integrated into the Apple ecosystem. I've been a beta-tester (and afterwards a fanatic enthusiast), but, obviously, I didn't test everything, just what I need. The biggest drawback of Nova is that it was created having front-end Web designers in mind, and so it's got a bit more support for HTML, JavaScript, CSS, etc., and a bit less support for backend programming languages (such as C/C++, Python, Go, etc.). It relies extensively on modern language servers for that — we have to thank Microsoft for inventing those! — and the level of integration with those languages varies, since they mostly rely on external plugins created by eager enthusiast such as yours truly (I mostly contributed a quick & dirty integration with the official Go language server, gopls, a new skin/theme, and a LSL syntax highlighter and linter — because nobody else uses Nova for that, of course).
   
   I'm just mentioning this because the truth is that I hadn't done any serious C/C++ compilation in Nova. As it happens, the guys who developed the initial C/C++ syntax highlighter now have replaced it with a C/C++/Objective-C language server instead. The cool about that is that you can then integrate the compilation with the editor, and do embedded debugging in the editor itself. In other words: just like Xcode, but without the bloat!
   
   Therefore, I had never tested some of the "extra goodies" in Nova, namely, the ability to run build scripts directly inside Nova itself. And that's way cool, because you can tweak with environment variables very easily, as opposed of doing it directly on a terminal shell (I keep opening terminal windows — I use kitty, not Apple's Terminal — and sometimes forget what env variables I have set by default on each session). By default I expected that it should inherit the environment variables I set on the shell by default, but this is not quite how it works.
   
   Indeed, the first compilation inside Nova also failed with linker errors — as expected, since I had not changed anything yet — but there was something severely wrong with the compilation itself: it was using GCC, not clang!
   
   That baffled be for half a minute, since I was 100% sure that I use clang on the command line (I just have GCC installed, for some tricky things that clang/LLVM is unable to compile). So why was it calling GCC to link everything together? Worse — it was trying to use GCC 12 to do that, but I have GCC 14.1 installed. I could have simply fixed things with a symbolic link, but that didn't make a lot of sense: the build instructions imply that everything gets properly compiled using Xcode's packaged compiler, namely, clang/LLVM, but this was not happening: for some obscure reason, Nova managed to direct the detection routines to GCC 12 as the default, for no apparent reason!
   
   Well, that was a simple fix, just change the $CC env variable to point to clang instead, and run the build script again. Right? Well, sort of. Here is where my second issue became apparent:
2. Do not use Homebrew's toolsets.
   
   Like a considerable size of the Mac population which uses the command line (meaning: doing some form of low-level work), I extensively use Homebrew, which shouldn't come as a surprise. Homebrew has everything and rarely breaks (much less than, say, Ubuntu/Debian's apt). It gets updated very frequently — again, compared to Ubuntu or even Debian, it usually has its packages upgraded within hours or days of the latest versions have been released (contrast that to months under Debian, or years under the long-term support versions of Ubuntu). And, thanks to its "cask" concept, you can even automatically keep track on almost all existing (packaged) applications out there, both open-source and commercial. It even tracks down many fonts (!) and keeps them updated (before Homebrew, I never even worried about updating fonts).
   
   Understandingly, Homebrew has to stay clear from overwriting anything that Apple has installed. Apple is also notoriously lagging behind the latest versions for several years (or more). But Apple tools assume that macOS is running the outdated versions, and complains otherwise. Therefore, Homebrew may install everything you want — completely replacing everything Apple has stuffed into macOS, if that's what you wish — but for the "sensitive" things where there could be conflicts, Homebrew never overwrites jany of the Apple-installed executables.
   
   However, there is a simple workaround: just put a different directory in your $PATH before Apple's own (/usr/bin for most tools). Most formulae in Homebrew will be already configured to put a symbolic link under /usr/local/bin anyway, so it's just a question of putting that before the rest. And if you really want to cherry-pick among the tools you want to run, you can always remove those symlinks under /usr/local/bin to Homebrew-installed apps — Apple's own tools will be called instead. It's a flexible approach.
   
   Needless to say, that's what I do — the more time passes, the more outdated Apple's software becomes, and Homebrew is the only option to continue to have command-line toold up to date. The guys at Homebrew, however, must be Apple shareholders as well — they've dropped support to Big Sur as well, and their pestering messages quoting the lack of support become increasingly more annoying and rude. A big drawback is that now everything needs to be compiled from scratch, as opposed to merely unpacked. And here is where the problems begin: many packages seem to me almost deliberately sabotaged by the Homebrew team of volunteers to make sure they will never work on Big Sur (or earlier). My claims are factual, mind you — I separately compile many tools "outside" Homebrew (when I really, really, really need them!), and these will almost always work. Because Homebrew is free and open-source and development is done on GitHub, I could undo many of the stupid patches and submit a pull request, but Homebrew states quite clearly that such procedure is absolutely forbidden).
   
   But there is a catch to that. Naturally enough, you need a working C/C++ compiling environment. Homebrew provides you with at least two — a more recent version of LLVM/clang, and a recent version of GCC as well. By juggling with environment variables, you can (relatively easy) switch among both. And you can also have Microsoft Roslyn's compiler for .NET, which will also compile most things as well (usually, much, much faster) — unless you've got something in Objective-C. Oh well. At the end of the day, in my messy Mac, I tend to have lots of different toolchains... not all of them mutually compatible. This is especially true when trying to compile the "tricky" libraries, such as OpenSSL & friends
   
   So... my problem was that I was trying to compile Cool VL Viewer with one of "my" toolsets, based on Homebrew-provided compilers.
   
   This doesn't work. (Don't bother to try!)

Once those two issues were settled — making sure the Cool VL Viewer is properly compiling with the Apple-supplied toolset & framework that comes with Xcode (13.2.1 in the case of macOS Big Sur)... then it's exactly as Henri & ZaneZimer said... it compiles cleanly, without a glitch, "straight out of the box", so to speak. It's actually one of the easiest application to compile ever just run the script, and wait.

Oh, and I'm happy to report that it does not take 17 hours Remember, that was done on a single-core, single-threaded PowerPC CPU, eons ago... now it takes less than an hour on a decade-old machine. Mind you, that is a compilation from scratch. I've tried to change ever so slightly a few files, and recompile — that took little more than a minute and a half.

And it certainly works! Thank you for all your work on this

The link to the Xcode 12 I gave works perfectly for me, as well as compiling with Xcode 12 on a hackintosh VirtualBox VM: you do not need Xcode 13 (but it works with it as well).

As for HomeBrew stuff, I never tested it... I do recommend macports in the doc/macOSBuildHowto.txt file however... And here again no need to fiddle with anything when using macports (no PATH issue or anything, as long as you follow the howto instructions to the letter).