On Wednesday, March 3, 2021 at 5:37:21 AM UTC-8 Albrecht Schlosser wrote:
Q: Which "package management" tool(s) did you install and which tool(s)
are you actually using?
RM: Homebrew
Unlike Erco, I've drunk the coolaid with Homebrew. I don't like that it installs stuff in /opt, but aside from that, it is far and away the easiest way to install and maintain programs on a Mac. I've taken to installing just about anything I can through Homebrew. Not just random small Unixy stuff (where a package manager is far and away the easiest way), but also big applications where normally you would directly download from there website.
The exception here is for any libraries I build against -- I have never installed a library for my own development via Homebrew. I also do not distribute my application via Homebrew. So perhaps I'm a hypocrite here.
The other popular package manager I haven't seen mentioned is MacPorts.
Q: How are you mainly building FLTK? Options are configure/make or
CMake. If CMake, please add your "Generator" as well, like "Unix
Makefiles", "Ninja", "Xcode", ...
RM: CMake, Xcode compiler, Unix Makefiles as the generator. I then use CLion as my IDE -- which uses CMake natively, but also really works well with the Makefiles on the back end. For example, I can build from the command line (make -j8) or from the IDE interchangably.
I used to use other compilers -- in particular Homebrew installed / maintained CLang and GCC. However, MacOS's reliance on Objective C and Swift now make it practically impossible to build FLTK with anything except for XCode on Mac.
In general, I would prefer to use CLang or GCC vs. XCode -- primarily because I like having explicit control over the version numbers of my toolchain. The way Apple constantly, vaguely, and silently updates XCode makes it harder to know what you actually used to build with.
Q: What build environments do you use, particularly do you use Xcode to
edit/build/test/debug (FLTK) and your FLTK application code?
RM: As mentioned earlier -- CLion. It works directly with CMake as its project files, so I use Unix Makefiles as my generator with XCode as my compiler.
Q: What else should I know about the build environments on your Macs WRT
building FLTK? Which extra build options work, which ones don't?
RM: I'm not sure if this has improved recently as I haven't updated in a while. However, historically, the FindFLTK.cmake bundled with CMake was utter garbage. When I've mentioned this before, people have suggested using autoconf (this is before the recent effort to improve CMake support). Or people have suggested other workarounds.
My project uses the 'SuperProject' pattern in CMake. This means all the dependent libraries can be built as subprojects of a Libraries project via the 'ExternalProject_Add' capability in CMake. In addition to the Libraries subproject, there is an Application subproject and a SuperProject.
A developer can choose to run CMake on the SuperProject (one make command should build all libraries and the application in one huge go) -- great for people building the application, but not actively developing on it. Or they can run on the Libraries and Application separately. That way, they aren't constantly rebuilding the Libraries, but the Application is exposed for development.
Even though the libraries are packaged and built by my own system, the Application subproject still uses FindXXXX.cmake scripts to 'find' what it needs from the Libraries subproject. This is done to allow all the individual libraries in the Libraries project to be optional -- you can use the bundled library or instead use a system-installed and maintained library. Therefore, the FindXXXX.cmake scripts need to work equally well for both cases (with some prompting for the location of the Libraries subproject).
In practice, we typically use bundled libraries on Mac and Windows and use system installed libraries on Linux wherever possible.
When FindFLTK.cmake fails, it is usually around finding fluid separately from the headers and libs. Also, this general mode of operation is fragile to extra-long paths. The SuperProject and ExternalProject_Add end up creating some really long command lines for CMake. If you set up your build directory in a deep directory, the long path can show up multiple times in some commands and you run into a character length limit for CMake or your shell. Very frustrating, but not really something FLTK can fix...
In short, I'd love to see some TLC applied to the FindFLTK.cmake script. We could distribute our own version with FLTK and I am sure the CMake project would pick up any updates quickly.
Rob
