I know that this a known bug and @Albrecht-S and @ManoloFLTK work on it, but I could not find an Issue attached to this.

I believe we concluded with Albrecht this is an issue to tackle after 1.4 has been released. The present situation where FLTK does not create frameworks (apart from the badly named non-framework /usr/local/FLTK.framework/ mentioned above) but creates .dylib's is OK and allows client apps to link to installed shared FLTK libraries.

Notice that /usr/local/FLTK.framework/ is necessary at present to build a client FLTK app with "modern" cmake against an installed version of FLTK shared libs. So, this badly named directory should be kept until the next step for FLTK 1.5.

After the release, we could work to make the FLTK build procedure create proper frameworks. I like very much the macOS approach where all frameworks are put inside the client bundle because this allows the app to be self sufficient and distributed without having to fiddle in the file system. This has the drawback that any FLTK client app would duplicate each FLTK framework. That's what can be seen, for example, in /Applications/Microsoft\ Word.app/Contents/Frameworksand /Applications/Microsoft\ PowerPoint.app/Contents/Frameworks.

I am happy to help.

Great.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/issues/961/2081320961@github.com>