Thanks for these fine instructions. I'll see if I can include these or similar instructions in the docs.

FWIW, some comments: as I wrote elsewhere you can use WIN32 and MACOSX_BUNDLE on all platforms because it's a documented feature that these keywords are ignored on "other" platforms than they are intended to be for.

target_include_directories(main PRIVATE ${fltk_SOURCE_DIR} ${fltk_BINARY_DIR}) # needed for visual studio

This is required on all platforms (not only visual studio) if and only if you use FLTK directly from its build directory because FL/abi-version.h is created (by CMake) in the build tree whereas all other header files must be included from the source tree. OTOH you need only one (the FLTK install) directory if FLTK was installed in a known target location.

For maximum safety [1] I suggest to reverse the two directories like this:

target_include_directories(main PRIVATE ${fltk_BINARY_DIR} ${fltk_SOURCE_DIR})

Note also that these instructions are best suited if you want to build only one application that uses FLTK, hence it is useful to download/pull/build FLTK together with this single app. In other scenarios it might be more sensible to download and build FLTK separately (and optionally install it in a well-known location) as a prerequisite to building more than one application.

Question: as you seem to know CMake's FetchContent module better than I do (I never found the time to study/test it): would it be possible to have more than one application using the same build directory so that downloading and building FLTK would be done only once even if you run several independent application builds? With all FetchContent directories pointing at the same place like symbolic links?

Notes:
[1] If it ever happens that "someone" runs a build in the source directory (maybe with configure/make), then FL/abi-version.h would be generated in the source directory with potentially different build options. The correct order of include directories (build directory first) makes sure the correct header file is found.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.