Q: Which "package management" tool(s) did you install and which tool(s) are you actually using?
A: Homebrew
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", ...
A: autoconf + CMake/Ninja + CMake/Xcode (I did not yet try CMake/"Unix Makefiles").
Q: If you are using autoconf/configure, how did you install 'autoconf'?
A: Homebrew (brew install autoconf)
Q: If you are using Homebrew, what is your Homebrew install directory?
A: /opt/homebrew
Ya, that's why I don't like homebrew; creating directories in
root just seems wrong,
and I think in recent OS versions (Big Sur, Catalina), it's
seriously frowned apon by the OS
and actively prevented by having the root system mounted read
only.
No longer can you be root and use 'mkdir' in the root
directory. Even in safe mode, creating
entries in the root directory on the OS volume magically
disappear on reboot. To pull it off
in Big Sur, you have to mess around with some hacky thing
called /etc/synthetic.conf,
or whatever it's called, and it will create a directory or
some new magic symbolic links,
and recommend you put stuff you'd normally put in root in a
new directory called /System/Volume/Data
or some such appley crazy thing that has nothing to do with
the unix world. Don't get me started 😠
FYI: Homebrew installs its packages on new "arm64" Macs to /opt/homebrew and places symbolic links in /usr/local whereas it installs to /usr/local on Intel Macs.
Q: Do you have pkg-config installed; if yes: by which package manager or self-built or ...?
A: yes, Homebrew
Q: How are you building/using the bundled libs (jpeg, png, zlib), i.e. system or bundled (aka "local") versions?
A: all three either system (WIP) or bundled, i.e. all combinations of system and/or bundled libs work with either configure/make or CMake/Ninja (see below for "WIP").
Note: I like Ninja (brew install ninja). It's much faster than "Unix Makefiles" particularly if only a few files were changed.
Q: What build environments do you use, particularly do you use Xcode to edit/build/test/debug (FLTK) and your FLTK application code?
A: VS Code (Visual Studio Code) is now my preferred editor and build/test environment.
I leave my windows machines off as much as possible.
I'm using VS Code on Linux and macOS for editing and debugging. There are currently some limits on M1 (arm64) Macs: debugging with VS Code works only for x86_64 builds (using Rosetta which makes it somewhat slower), not for native arm64 but I'm confident this will be resolved soon (there are open GitHub Issues). Meanwhile I can build x86_64 target code for debugging with VS Code or I can use Xcode to debug arm64 code. Universal binaries (arm64 + x86_64) build but not yet tested with debugger (lldb).
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?
A1: I installed Cairo (brew install cairo) and I can now build the Cairo demo - either with configure/make or CMake (after a recent commit).
Q: If you are using Homebrew, what is your Homebrew install directory?
A: /opt/homebrew
But to answer the question, I leave it at the default which is apparently /opt.Ya, that's why I don't like homebrew; creating directories in root just seems wrong [..]
Q: Which "package management" tool(s) did you install and which tool(s)
are you actually using?
CMake. If CMake, please add your "Generator" as well, like "Unix
Makefiles", "Ninja", "Xcode", ...
Q: What build environments do you use, particularly do you use Xcode to
edit/build/test/debug (FLTK) and your FLTK application code?
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?
The other popular package manager I haven't seen mentioned is MacPorts.
Oh yeah, I've used ports from time to time too.
Thanks for the reminder!
I think only one of these, brew or ports, uses /opt as a
default.
The other uses /usr/local.. I think?
Sniffing around, might it actually be that (mac)ports uses
/opt,
and (home)brew uses /usr/local/opt?
The times I use package managers are when I'm installing tools
that have complex
dependencies on other projects, and magically pulls in the
right versions and builds
it all with the least pain, avoiding having to carefully pick
through the package specific
README/INSTALL docs on how to build for each platform. There's
so much variance,
and so often build errors incompatible with the local
compiler.. it's great that brew/ports
handles all that.
I don't find myself installing packages from source with wide
dependencies often.
Most of the libs I build against are minimal dependency-wise,
like FLTK.
This is on purpose, so my apps don't get forced to specific
hardware/OS versions;
the more dependencies, the more restrictions.. esp. with
things like movie libraries
that sometimes depend on specific compiler features, hardware
for playback, or
take advantage of particular features only available in newer
OS versions.
And any apps that have many dependencies, like image/movie
viewers, photo
manipulation tools like GIMP, etc. I often install as
prepackaged bins; it's usually
utter madness to build those from source, due to the massive
dependencies.
Rob and others, thanks for taking the time to reply. It's very much
appreciated. I need some time to read and reply to details ...
> 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.
AFAICT it is still. And it's not very likely that this will change.
Don't use it!
> 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.
Our documentation (README.CMake.txt) tells you how to invoke
find_package(FLTK ...) correctly in "config mode", not in "module mode".
Unfortunately this requires that FLTK has been built with CMake and
created (and ultimately installed) the CMake Config script.
other shared libraries (xft, cairo, pango) pull in the system libs which
can lead to problems.
Exactly for that same reason I want to make it at least *possible* to
use the system libs on macOS (*) rather than the bundled libs to avoid
conflicts. The bundled libs are now updated (not yet released, maybe not
even in Git for 1.3.6 though), but that will be the case soon.
(*) whatever "system libs" you install, be it Homebrew, Fink, MacPorts,
others.
There are still cases that can make it unavoidable to build your own
libs - not only the bundled jpeg, png, zlib, but also more libs (and
link statically) to avoid system dependencies. But that's another story.
On Windows there are no standard system libs so it's clear that you need
to build other dependencies as well.
> In short, I'd love to see some TLC applied to the FindFLTK.cmake
> script.
What is TLC? https://www.acronymfinder.com finds 237 results.
> We could distribute our own version with FLTK and I am sure the
> CMake project would pick up any updates quickly.
I'm not sure they'd want this. Here are some links that show why they
don't want to distribute a FindSDL2 module:
https://stackoverflow.com/questions/54005991/what-happened-to-findsdl2-in-cmake
See Brad King's reply here:
https://github.com/Kitware/CMake/pull/149#issuecomment-87666029
... and the linked discussion:
The gist being (citation): "Package configuration files that come with
the package are technically superior to find modules because they know
exactly what comes with the package and where it is located...".
Another drawback is (CMake) backwards compatibility, I mean: we want to
support the oldest CMake versions possible (to *build* FLTK). I know
it's a different issue, but we can't push FindFLTK modules to older
CMake versions than the most current, i.e. the next version at best.
This will never work.
That said, I think we will need to produce CMake config files that can
be distributed with FLTK so find_package(FLTK CONFIG) aka "NOMODULE"
works. The FindFLTK module in CMake is really only for FLTK 1.1, not
1.3, nor any future release.
In short, I'd love to see some TLC applied to the FindFLTK.cmake script.
What is TLC? https://www.acronymfinder.com finds 237 results.
Tender Loving Care -- it's an old, pre-internet acronym, if I
remember cor.. uh, IIRC.
I'm not sure when it came about, but it's a really common
english thing, seems
as old as the hills.
No, it's okay, points taken. Thanks for all constructive criticism.
We're all (and particularly I am) still learning how to deal with CMake.
I don't like autoconf so I'm striving to make the best of our CMake support.
> I will have to parse and understand everything you say later about the
> alternatives, but I submit that using FindXXXX.cmake is still the
> default mode of using CMake.
AFAIC it's officially find_package(NAME options ...) which will
eventually call FindXXXX.cmake (which is called "module mode") or use
XXXXConfig.cmake (which is called "config mode"). See the CMake docs for
find_package(). The way you call it decides which option is chosen or if
you leave it to find_package() to choose - whatever it finds.
Someone asked (maybe it's an open issue, I don't remember) if we could
provide FLTKConfig.cmake even with autoconf builds. This is something we
(I?) might consider. The effect would be that all Linux distributions
would provide it, whether they build FLTK with autoconf or CMake.
Another option (also a user question, IIRC) was if we could provide
pkg-config (.pc) files. That's also something that would likely help
some people.
Your idea to provide FindFLTK.cmake with FLTK sources (or somewhere
installed by the build?) is also something that might be doable. I need
to make myself familiar with "how to write a CMake find module" to be
able to do this. But if it helps FLTK users to use FLTK in their
projects it might be worth it.
All valid points and a lot of work to do. Particularly to do it *right*.
> > In short, I'd love to see some TLC applied to the FindFLTK.cmake
> > script.
>
> What is TLC? https://www.acronymfinder.com
> <https://www.acronymfinder.com> finds 237 results.
>
> Tender loving care
Thanks for explanation. Also, Greg Ercolano wrote:
> ... it's an old, pre-internet acronym, if I remember cor.. uh, IIRC.
> I'm not sure when it came about, but it's a really
> common english thing, seems as old as the hills.
Yeah, "common english thing". Hard to know for a non-native english
speaker. But now I know, thanks.
And I'll try to do my best.
Q: Which "package management" tool(s) did you install and which tool(s)
are you actually using?
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", ...
A:
Q: If you are using autoconf/configure, how did you install 'autoconf'?
Q: Do you have pkg-config installed; if yes: by which package manager or
self-built or ...?
Q: How are you building/using the bundled libs (jpeg, png, zlib), i.e.
system or bundled (aka "local") versions?
Q: What build environments do you use, particularly do you use Xcode to
edit/build/test/debug (FLTK) and your FLTK application code?
Great! Now we can share our (FLTK) build experiences on M1 Macs!
BTW: Rumors say (and I think this is sensible) that there are no M1
(arm_64) versions of Virtualbox and maybe many or all the other VM tools
(particularly parallels) - and these VM tools are not expected to come
(at least not soon) since they would have to *emulate* an Intel
processor, at least for Windows. Windows is officially available for ARM
but (again, rumors say) is only distributed to/by OEM's and can't be
bought by single users. Did you research this already for your own
development?
If it's true you'd certainly need to keep an older Intel Mac for your VM's.
The only issues I'm having (so far):
(1) VS Code can't debug arm64 (or universal) apps (using lldb), but this
is a VS Code problem and will hopefully be fixed soon. I can circumvent
this issue by building for x86_64 and debug with VS Code - unless I need
"other" libs (see (2)). My alternative option to debug is to use Xcode
(I built FLTK with CMake/Xcode, tested, works) but I'm not yet familiar
with it. It's very similar to what I used previously though. I'll try
again later when I have a real use case.
(2) I can't build x86_64 or universal apps if I need to link to
libraries (e.g. Cairo) installed with Homebrew because these libs are
all arm64 only - which means I can't debug such apps with VS Code, see
(1). But that's a minor issue for now and can be resolved later. I think
that I can build such libs myself (with Homebrew) and then hopefully as
universal libs. Maybe, we'll see.
On 3/4/21 2:10 AM, Manolo wrote:
On Wednesday, March 3, 2021 at 2:37:21 PM UTC+1 Albrecht Schlosser wrote:
Q: Which "package management" tool(s) did you install and which tool(s)
are you actually using?
A: Fink. Although it doesn't work yet with macOS 11, so I may have to change.It's installed in /opt/sw
..which lets me put my actual mounts in /some/where/else.
Note that's a /tab/ between /net and /some/where/else; I
believe this is to allow
for spaces in the names (yuck) without having to use quoting.
Some questions:
What is your PATH after installation and configuration of MacPorts?
What does `which pkg-config' output ?
Are there potential conflicts with other tools / symbolic links in
/usr/local or elsewhere?
Finally, pkg-config is a nice example but having a universal executable
is less important than being able to *build* universal apps. The main
purpose of installing 'universal' packages is IMHO for libraries so they
can be linked in universal binaries. Did you try this too? Is it possible?
On 3/4/21 2:10 AM, Manolo wrote:
A: Fink. Although it doesn't work yet with macOS 11, so I may have to change.It's installed in /opt/swI'm guessing Fink and other tools that use /opt will get what they want using
/etc/synthetic.conf, which is apple's workaround to making / read-only.
I'm guessing they'll use the 'special link' approach, and put their actual data
in either /usr/local/opt or /System/Volumes/Data/opt (again, just a guess!).
I would hope they choose the former, as the latter is something Apple could
change in future releases (as they often do with stuff they just make up).
/etc/synthetic.conf tells the OS on boot to create empty dirs and/or special kinds of
symbolic links to another place. This is apparently is Apple's workaround to making
root completely unwriteable. With this approach, apparently Apple can supervise
(and deny) what can be done in the root dir.
I have once found in the web the name of the file that lists those directories which are writableand don't remember that info. But it's mostly useless because that file is unchangeable.
On Thursday, March 4, 2021 at 4:28:08 PM UTC+1 er...@seriss.com wrote:
I'm guessing Fink and other tools that use /opt will get what they want using
/etc/synthetic.conf, which is apple's workaround to making / read-only.
I'm not aware of this /etc/synthetic.conf file and its function.There's no such file here neither in my Intel nor my M1 macOS machines (macOS 11.2.2)
Like /etc/exports, the file doesn't exist until you create
it.
Check out 'man synthetic.conf' for details.
There's no /usr/local/opt nor /System/Volumes/Data/opt here either.
/etc/synthetic.conf tells the OS on boot to create empty dirs and/or special kinds of
symbolic links to another place. This is apparently is Apple's workaround to making
root completely unwriteable. With this approach, apparently Apple can supervise
(and deny) what can be done in the root dir.
My understanding, which must be partial, is different. macOS now uses 2 "intertwinedfilesystems" (my wording for this concept), one holding the system and one for user files.
That for the system is readonly.It's readonly in a strong sense: even root cannot write to it or mount it rw.
It used to be possible to bypass that:mount the system disk on another, earlier, macOS machines and you can write to /then reboot and you had your /xxx folder. I did that for /sw to get my fink.But then fink was improved to use /opt/sw and /opt is not in the system filesystembut in the user filesystem. So root can write to it.
However, in Big Sur, for sure if you try to create subdirs on
the bootable root
volume, your changes are REMOVED on boot. They just disappear.
The OS is /really/ enforcing integrity of the OS, not only
read-only,
but insisits on no modification (see above link regarding
crypto-signed features)
That those filesystems are interwined is visible with /opt which is a top-level directorybut in the writable part. It's also visible when you install an app, say Firefox, in /Applications:there you have some files of /Applications in the readonly filesystem, and others in the writable filesystem.
Ya, notice OS applications are now in /System/Applications,
and /Applications is empty.
That scared the crap outta me one day.. I thought I'd been
hacked.
With macOS 11, it's much worse: the system part of the file system is cryptographically signed,so it's impossible to change anything in it, unless you recreate the signature, with obscureand not well documented means.
My understanding is also that Apple intends to leave /opt a part of the filesystem that usersare free to colonize. That's visible with XQuartz, Macports, Fink that are all put there.
But this may of course change at some future time.
AFAIC it's officially find_package(NAME options ...) which will
eventually call FindXXXX.cmake (which is called "module mode") or use
XXXXConfig.cmake (which is called "config mode"). See the CMake docs for
find_package(). The way you call it decides which option is chosen or if
you leave it to find_package() to choose - whatever it finds.I've read through the CMake docs and a few other resources on this.
> If I can still edit [the CMake ForFLTK wiki page], maybe it would be
> useful to modify / annotate it to make it consistent with the current
> README.CMake.txt build advice, no?
If you can, it would be useful to annotate it; say it's outdated now
(i.e. usable for outdated FLTK 1.1), and refer users to the current
README.CMake.txt
> If I can still edit [the CMake ForFLTK wiki page], maybe it would be> useful to modify / annotate it to make it consistent with the current
> README.CMake.txt build advice, no?If you can, it would be useful to annotate it; say it's outdated now
(i.e. usable for outdated FLTK 1.1), and refer users to the current
README.CMake.txt