| |
| #1 | mjsurette
23:07 Mar 29, 2016 |
| The CMake CREATE_EXAMPLE macro has example specific tests to allow for Mac bundles.
This patch removes example specific tests and creates a more generic macro to create Mac bundles.
I know nothing of the Mac build process and have made certain assumptions based on the scripting that I have removed. If these assumptions are correct then this should work ootb.
Please test. | |
| |
| #2 | mjsurette
20:20 Apr 04, 2016 |
| This updated patch also simplifies the build file for fluid, replacing all the Apple specific code with one macro call.
The decision to put the bundle code in its own macro is working out quite well. Thanks for the guidance Albrecht. | |
| |
| #3 | AlbrechtS
05:15 Apr 05, 2016 |
| Thanks for the patch. Unfortunately it didn't work under Linux w/o changes:
The 'else' statement in the original CREATE_EXAMPLE macro was missing, so there was no target created at all for all test programs. I added the add_executable() statement with the WIN32 option back to the macro. Note that WIN32 is ignored on non-Windows platforms, so this should not do any harm, but we need the target.
After that I got errors about wrong numbers of macro calls (FL_ADD_BUNDLE). I fixed this by adding empty arguments. FTR: I'm using CMake 2.8.12.2 (Ubuntu 14.4 LTS).
I also had to revert the part that deals with the reserved target name 'help'. Although I agree that this is not a good solution, it's the only one for now because we can't rename the executable name in FLTK 1.3.x. There are too many other changes we'd have to do, including demo.menu (easy) and all IDE files (not feasible).
I promise that this will be fixed in FLTK 1.4.0 when we don't have these restrictions any more. My plan is to rename the target (and the .cxx file) to helpview which is a much better name.
Please see attached file MacBundle_v2.patch (use patch -p1). | |
| |
| #4 | AlbrechtS
06:58 Apr 05, 2016 |
| I'm wondering if the relative addresses in test/CMakeLists.txt are correct in all cases. What do they refer to?
If the base of these relative directories is the current source directory (test), then "../test" is redundant. However, if the directory is relative to the (current) build directory then this is definitely wrong, because the build directory can be anywhere else (unrelated to the source directory tree).
I suggest to replace "../test" with "${CMAKE_CURRENT_SOURCE_DIR}" in all FL_ADD_BUNDLE calls, but I can't test it.
Note: the original code used "${PROJECT_SOURCE_DIR}/test" which might be equivalent to my proposal.
@Mike: why did you change this in your patch? | |
| |
| #5 | mjsurette
07:31 Apr 05, 2016 |
| My apologies for the basic errors in my patch. I was thinking "Mac patch, I can't test it", so I didn't. Bad mistake.
As for the relative paths, hard won experience more than any documentation has taught me that CMAKE_CURRENT_SOURCE_DIR is equivalent to ".". I changed that on a whim, but an explicit path would be immune to changes in undocumented behaviour. | |
| |
| #6 | mjsurette
19:59 Apr 05, 2016 |
| Fixed as discussed here and in fltk.coredev.
CMake/FLTKfunctions.cmake created and
functions FLTK_RUN_FLUID and FLTK_ADD_BUNDLE moved to it.
Resource files in tests referenced to ${CMAKE_CURRENT_SOURCE_DIR}
Function internal_ADD_BUNDLE created with test for NOT OPTION_APPLE_X11 and used for test programs
Tested on Debian Stretch with GCC 5.3.1. | |
| |
| #7 | AlbrechtS
01:24 Apr 07, 2016 |
| Please see attached file MacBundle_v4.patch with the following additional features as compared to MacBundle_v3.patch:
- fix an error [1] reported by Manolo off-list (hopefully)
- add missing WIN32 property to fluid
[1] CMake Error at fluid/CMakeLists.txt:47 (install):
install TARGETS given no BUNDLE DESTINATION for MACOSX_BUNDLE executable
target "fluid". | |
| |
| #8 | manolo
04:07 Apr 07, 2016 |
| Error also with
CMake + FLTK 1.3 current + Mac OS X + MacBundle_v4.patch :
.
.
.
Looking for pthread_create - found
Found Threads: TRUE
Found ZLIB: /usr/lib/libz.dylib (found version "1.2.5")
cannot find system jpeg library - using built-in
Found PNG: /usr/local/lib/libpng.a (found version "1.5.23")
CMake Error at fluid/CMakeLists.txt:47 (install):
install RESOURCE given directory
"xxxxxxx/fltk-1.3devel/fluid/Fluid.app/Contents/Resources"
to install.
CMake Error at CMake/FLTKfunctions.cmake:68 (target_compile_definitions):
target_compile_definitions called with invalid arguments
Call Stack (most recent call first):
CMake/macros.cmake:128 (FLTK_ADD_BUNDLE)
test/CMakeLists.txt:39 (internal_ADD_BUNDLE)
Configuring incomplete, errors occurred!
See also "xxxxxxxx/build/CMakeFiles/CMakeOutput.log".
See also "xxxxxxxx/build/CMakeFiles/CMakeError.log". | |
| |
| #9 | mjsurette
05:43 Apr 07, 2016 |
| One of my assumptions just bit me.
The fluid resource used to be the path to fluid.icns. I dropped the filename and CMake doesn't like that.
I'll fix that tonight. | |
| |
| #10 | mjsurette
16:04 Apr 07, 2016 |
| Here's the fix for the missing filename issue.
I added the filename to the original call.
I fixed the logic so it checks for a filename before adding a resource.
I inserted quotes around variables to handle embedded spaces.
Checked under Linux. | |
| |
| #11 | AlbrechtS
06:13 Apr 09, 2016 |
| Michael, thanks for the new patch.
I tested it under Linux by (basically) changing the condition "if (APPLE)" to "if (APPLE OR USE_X11)" so I could run the entire FLTK_ADD_BUNDLE function under Linux.
FYI: The idea was that doing platform-specific things in CMake would be ignored on other platforms, just like the WIN32 keyword in add_executable().
This worked with a few minor corrections (likely caused by adding the quotes in MacBundle_v5.patch). Other change are only minor formatting differences.
Changes:
(1a) removed keyword PUBLIC from arguments in test/CMakeLists.txt (demo)
(1b) added keyword PUBLIC in FLTK_ADD_BUNDLE before "${DEFINITIONS}".
I believe this is the correct solution (PUBLIC is an implementation detail, not a "definition" to be added).
With this patch I could run the entire FLTK_ADD_BUNDLE function(s) for fluid and all example programs and compile and link successfully under Linux. I'm confident that this patch is at least syntactically correct, so that CMake should also run successfully under Mac OS X.
Please see attached file MacBundle_v6.patch for the full patch.
Manolo or anybody with Mac OS X, could you please test again and report if the created bundles are correct? TIA. | |
| |
| #12 | AlbrechtS
06:45 Apr 09, 2016 |
| FWIW: See FLTK_ADD_BUNDLE_test.diff for my test code (apply after the patch). Here is what I got from running cmake:
...
-- FLTK_ADD_BUNDLE 'fluid' '/path/to/fltk/fluid/Fluid.app/Contents/Resources/fluid.icns' '' ''
-- ICON_NAME = 'fluid.icns'
-- find_file(RES '/path/to/fltk/fluid/Fluid.app/Contents/Resources/fluid.icns')
-- include_directories('/path/to/fltk/fluid/Fluid.app/Contents/Resources')
-- FLTK_ADD_BUNDLE 'blocks' '/path/to/fltk/test/blocks.app/Contents/Resources/blocks.icns' '' ''
-- ICON_NAME = 'blocks.icns'
-- find_file(RES '/path/to/fltk/test/blocks.app/Contents/Resources/blocks.icns')
-- include_directories('/path/to/fltk/test/blocks.app/Contents/Resources')
-- set_target_properties('blocks' PROPERTIES MACOSX_BUNDLE_ICON_FILE 'blocks.icns')
-- FLTK_ADD_BUNDLE 'checkers' '/path/to/fltk/test/checkers.app/Contents/Resources/checkers.icns' '' ''
-- ICON_NAME = 'checkers.icns'
-- find_file(RES '/path/to/fltk/test/checkers.app/Contents/Resources/checkers.icns')
-- include_directories('/path/to/fltk/test/checkers.app/Contents/Resources')
-- set_target_properties('checkers' PROPERTIES MACOSX_BUNDLE_ICON_FILE 'checkers.icns')
-- FLTK_ADD_BUNDLE 'demo' '/path/to/fltk/test/demo.menu' '' 'USING_XCODE'
-- ICON_NAME = 'demo.icns'
-- find_file(RES '/path/to/fltk/test/demo.menu')
-- include_directories('/path/to/fltk/test')
-- set_target_properties('demo' PROPERTIES MACOSX_BUNDLE_ICON_FILE 'demo.icns')
-- target_compile_definitions('demo' PUBLIC 'USING_XCODE')
-- FLTK_ADD_BUNDLE 'sudoku' '/path/to/fltk/test/sudoku.app/Contents/Resources/sudoku.icns' '' ''
-- ICON_NAME = 'sudoku.icns'
-- find_file(RES '/path/to/fltk/test/sudoku.app/Contents/Resources/sudoku.icns')
-- include_directories('/path/to/fltk/test/sudoku.app/Contents/Resources')
-- set_target_properties('sudoku' PROPERTIES MACOSX_BUNDLE_ICON_FILE 'sudoku.icns')
-- Configuring done
-- Generating done
Worked well, and I hope it makes sense... | |
| |
| #13 | AlbrechtS
07:13 Apr 09, 2016 |
| The following note is only partially about this patch, but more about the previously existing code to add the Mac bundles.
Reading the log above I believe that this is not optimal concerning our test programs. We use 'include_directories' which adds the include directories to all targets in the test directory, according to the CMake docs at
https://cmake.org/cmake/help/v3.5/command/include_directories.html
"The include directories are added to the INCLUDE_DIRECTORIES directory property for the current CMakeLists file. They are also added to the INCLUDE_DIRECTORIES target property for each target in the current CMakeLists file. The target property values are the ones used by the generators."
Note that this was not changed in the current patch, but I believe that we'd better use target_include_directories() to be more specific.
https://cmake.org/cmake/help/v3.3/command/target_include_directories.html
However, this seems to have been added in CMake 2.8.11, and (looking into it) this was added together with target_compile_definitions(). From 2.8.11 release notes:
"Added target_include_directories and target_compile_definitions commands with PUBLIC/PRIVATE/INTERFACE options"
Conclusion: since we're using target_compile_definitions() already in the FLTK_ADD_BUNDLE we can also use target_include_directories(), but this would require CMake 2.8.11 at least on Mac OS X when creating bundles, whereas we're now only requiring CMake 2.6.3.
There are four choices:
(1) use the better target_*() commands and require 2.8.11 on Mac OS X
(2) use the worse include_directories() and add_definitions() instead
(3) use (1) or (2) depending on the CMake version
(4) require 2.8.11 generally
Opinions? | |
| |
| #14 | AlbrechtS
08:57 Apr 09, 2016 |
| Attached MacBundle_v7.patch checks the CMake version (2.8.11) and uses different statements dependent on the CMake version (option (3) above).
Test statements are included.
Hint: If you like to test both versions (old and new CMake statements) with your installed CMake version, just change all version strings ("2.8.11") to a version higher than the one you have installed, e.g. "3.5.0", and CMake should use the "old" statements. | |
| |
| #15 | AlbrechtS
09:01 Apr 09, 2016 |
| I forgot to mention: I also changed "PUBLIC" to "PRIVATE" in the "new" CMake statements, because I think that this is correct.
Please correct me if I'm wrong (why?). | |
| |
| #16 | mjsurette
09:17 Apr 09, 2016 |
| To me your experiment with the if (APPLE OR USE_X11) would indicate that CMake is smart enough to not apply bundle code if it's not appropriate. So we can remove platform checks.
====
Requiring different CMake versions for different platforms in general would complicate things, which is in itself undesirable.
CMake 2.8.11 was released on 17 May 2013 which makes it 3 years old. I would say making it a requirement is not unreasonable.
This would allow us to also remove the check for CMake 2.8.4 needed for GNUInstallDirs. If we went just a little further to 3.0.0 (June 2014) we could also remove the check for CMAKE_SUPPRESS_REGENERATION. Even Debian Stable has 3.0.2, and it's not exactly bleeding edge.
So I would think that the simplest solution and in this case the best solution is to bump the required version of CMake and remove a bunch of checks. The only question is how far do we bump. | |
| |
| #17 | manolo
02:43 Apr 10, 2016 |
| I have tried MacBundle_v7.patch with
CMake + Mac OS + FLTK 1.3-current
It's much better because there are no errors, and the whole
thing can be built.
But there are still a few problems:
- most resulting test programs are not bundles but just executables
- those that have been processed by FLTK_ADD_BUNDLE
(e.g., checkers, fluid)
are bundled but have lost their bundle icon.
The attached bundle.png image shows two panels
- the top one is what the checkers.app bundle contains
- the bottom one shows what it should contain
Thus, the Resources subdirectory and the icon file therein are missing. | |
| |
| #18 | AlbrechtS
06:46 Apr 10, 2016 |
| @Manolo: Thanks for testing.
The fact that most of the test programs are just executables was to be expected. If we wanted to make all to bundles we'd need icons and maybe more for all these programs. It would be easier with the new FLTK_ADD_BUNDLE function, but I don't think that this is worth the effort because these are only test programs.
The missing icon needs to be investigated. Is your image with the correct bundle from the porting branch w/o the patch? If yes, then something must be wrong with the patch and we need to find out why. | |
| |
| #19 | AlbrechtS
07:01 Apr 10, 2016 |
| @Michael, comment #16: I don't like the idea to raise the required version number in FLTK 1.3.4 - we should leave it at 2.6.3. It is better to have a few work-arounds in out library CMake code than to force end users to use a higher CMake version.
If we raised it (for FLTK 1.4, maybe), then we should not go higher than 2.8.11, but we need to investigate more. IIRC I heard of Redhat (RHEL 7?) using 2.8.11, but I'm not sure. Commercial users of RHEL (any version) may be forced to use the existing CMake version because of company policies.
CMake 3.0.0 (June 2014) would also be later than current Ubuntu LTS versions (Ubuntu 14.04 LTS). Typical LTS users may upgrade during the next year to Ubuntu 16.04 LTS (should be released this month), but since Ubuntu LTS is now supported for 5 years, the latest 14.04 LTS users might upgrade in 2019.
That's only a few examples...
I believe we should be very conservative in our CMake usage to keep the hurdle low for users, paticulary since we will be forcing Windows IDE users to use CMake in the future (FLTK 1.4). Although Windows users might download the latest version anyway... It's difficult to decide. | |
| |
| #20 | AlbrechtS
07:04 Apr 10, 2016 |
| FTR: My Ubuntu 14.04 LTS has: cmake --version
cmake version 2.8.12.2 | |
| |
| #21 | mjsurette
13:46 Apr 10, 2016 |
| Side note: It occurred to me that my brother had acquired an iMac for his university courses some months ago. So thanks to my brother and TeamViewer (he lives about 1000 miles away), I can now test for the Mac.
The problem with no icons stems from the fact that CMake functions pass arguments by value rather than by reference. The fix was to change FLTK_ADD_BUNDLE from a function to a macro.
I have checked for an alternate solution to no avail. I will ask the CMake users list for further ideas, but for now this works.
I have also simplified the code by removing any platform checks on the basis of Albrecht's experiment which suggests that CMake will do the right thing. This made internal_ADD_BUNDLE obsolete.
Works on Linux and Mac. | |
| |
| #22 | manolo
22:31 Apr 10, 2016 |
| About MacBundle_v8.patch:
in my hands, it makes no difference with MacBundle_v7.patch.
Most test programs are not bundled.
The few bundled ones have no icon.
#21 contains "The fix was to ..." which made me expect that
the bundle problem was fixed.
But it also contains "I have checked for an alternate
solution to no avail.". So, may be, what should be expected
is that V8 and V7 produce similar results.
About leaving test programs unbundled on the mac platform:
Such programs do run, but when they are double clicked,
this also opens a Terminal window.
Such behaviour is completely obscure for the average mac user.
I believe it is very important to show that FLTK is able to
produce well behaved Mac OS apps.
Please, notice that the unpatched FLTK 1.3 + CMake produces
only correctly bundled apps.
App bundles are not obliged to contain an icon file.
That is what the patched FLTK 1.3 does with fluid, for instance.
Is it possible to use the standard CMake Mac bundle creation
mechanism for simple test apps, and reserve the new mechanism
to those with an icon (e.g., fluid, checkers)? | |
| |
| #23 | mjsurette
18:21 Apr 14, 2016 |
| Thank you @Manolo for your explanation of what was expected. After that I decided to start from scratch.
The result is a much simplified and hopefully more satisfactory solution. All test programs are automatically put in bundles when compiled under Mac. Those that need icons call the FLTK_SET_BUNDLE_ICON function. Any further Mac specific processing is called locally on an as-needed basis. I left blank lines before and after the examples that do anything Mac specific for better visibility.
Tested under Linux and Mac. Please test further.
A patch to export the functions in FLTK-Functions.cmake for the end-user and depricate UseFLTK.cmake will follow. The name FLTK-Functions.cmake was chosen to be in the same form as the CMake generated FLTK-Targets.cmake. | |
| |
| #24 | AlbrechtS
05:11 Apr 15, 2016 |
| Thanks for updating the patch again. However, I still see two issues with this patch w/o having access to an OS X system:
(1) Our code in CREATE_EXAMPLE uses
"if (APPLE AND NOT OPTION_APPLE_X11)"
to restrict the bundle creation to "real" OS X apps that should have a bundle, as Manolo stated. This condition has been (or will be) extended in FLTK 1.4 to
"if (APPLE AND (NOT OPTION_APPLE_X11) AND (NOT OPTION_APPLE_SDL))"
which makes it more complicated (I don't know if this is necessary though).
Although the bundle related statements should do no harm on "other" platforms, these additional constraints can not be known by CMake (CMake only knows that we're on "APPLE").
The problem with this arises in test/CMakeLists.txt when the addditional (ICON etc.) statements are used w/o this precondition.
(2) As discussed before
"target_compile_definitions(demo PRIVATE USING_XCODE)"
is only available in CMake 2.8.11 and later. I don't intend to raise the requirement in FLTK 1.3.4 above 2.6.3, so we need a version dependent workaround for this as given in my previous patch.
Other than that: Patch looks good to me, thanks. Looking forward to Manolo's test results. | |
| |
| #25 | mjsurette
09:59 Apr 15, 2016 |
| I'll fix the "target_compile_definitions(demo PRIVATE USING_XCODE)" issue, just an oversight.
For now, "if (APPLE AND NOT OPTION_APPLE_X11)" should be ok.
For 1.4, we could set a variable (FLTK_VIDEO)? in our options.cmake to whichever video environment you pick. This would then get exported to the user as well as used by our CMake scripts. | |
| |
| #26 | mjsurette
15:19 Apr 15, 2016 |
| Add CMake version check for target_compile_definitions. | |
| |
| #27 | mjsurette
16:08 Apr 17, 2016 |
| v11 fixes a bug in the funcion FLTK_RUN_FLUID. FLTK_FLUID_EXECUTABLE should be called instead of fluid in order to be 100% reliable. | |
| |
| #28 | mjsurette
01:42 Apr 19, 2016 |
| The auto-functions patch is meant to be used after the MacBundle patch.
It installs the exported functions for the user and depricates the UseFLTK.cmake file. | |
| |
| #29 | manolo
04:03 Apr 20, 2016 |
| Here is the effect of MacBundle_V10.patch + auto-functions.patch + CMake:
All apps are bundled.
Fluid is perfect : bundle + icon
Other apps (e.g., sudoku, checkers) that should have an icon
don't have it (but they are bundled).
Notice that MacBundle_V11.patch is an empty file. | |
| |
| #30 | mjsurette
17:10 Apr 20, 2016 |
| The v12 patch is what the v11 should have been. It's not different enough from the v10 patch to make any difference in the Mac bundles. I'm looking into that issue. | |
| |
| #31 | manolo
00:26 May 01, 2016 |
| I believe attached file #17 fixes the problem of getting
icons in bundled test programs under Mac OS X.
The problem was that the icon file name should be included
in the add_executable() command.
This patch + CMake + current svn source code under Mac OS X
produces correctly bundled test programs. | |
| |
| #32 | manolo
03:50 May 01, 2016 |
| Attached patch #18 uses the CREATE_EXAMPLE macro also
to build fluid.
Also, in test/CMakeLists.txt,
add_definitions("PRIVATE USING_XCODE")
is commented out because it does not seem to work. | |
| |
| #33 | mjsurette
21:29 May 09, 2016 |
| Thank you @Manolo for finding the solution to the missing icons.
The original intent of this STR was to remove example specific tests from the CREATE_EXAMPLE macro. The idea was to streamline the process by having a standardized way to handle Mac specific concerns in the examples build. The plan was to simplify the scripts and keep the same functionality. I believe that we are getting very close to this.
This STRs objectives have grown a bit since then though. The plan is to split off this new function FLTK_SET_BUNDLE_ICON along with the existing FLTK_RUN_FLUID so that they can be exported for general use.
A separate patch would deprecate the use of UseFLTK.cmake so that it could be dropped in a future release.
Another kink is changing the call to "${FLTK_FLUID_EXECUTABLE}" from "fluid" in FLTK_RUN_FLUID which is strictly speaking an error, although it would likely only give grief in cross-compiling scenarios.
I am finally getting a little free time to organize all this and have a question concerning the comment about commenting out
add_definitions("PRIVATE USING_XCODE")
because it doesn't work. What is the expected behaviour? | |
| |
| #34 | manolo
23:38 May 09, 2016 |
| About PRIVATE_USING_XCODE:
The intention was to add the -DUSING_XCODE argument to the
compilation command when using the Xcode generator.
It was done in 2 ways depending on the version of CMake.
And the way for old versions is not correct.
I have now a better and simpler solution. Add this
if (CMAKE_GENERATOR STREQUAL Xcode AND NOT OPTION_APPLE_X11)
add_definitions(-DUSING_XCODE)
endif(CMAKE_GENERATOR STREQUAL Xcode AND NOT OPTION_APPLE_X11)
in test/CMakeLists.txt, just before the first call to CREATE_EXAMPLE
and remove other stuff related to USING_XCODE | |
| |
| #35 | mjsurette
03:35 May 10, 2016 |
| Would it not be appropriate to add this stanza
if (CMAKE_GENERATOR STREQUAL Xcode AND NOT OPTION_APPLE_X11)
add_definitions(-DUSING_XCODE)
endif(CMAKE_GENERATOR STREQUAL Xcode AND NOT OPTION_APPLE_X11)
to CREATE_EXAMPLE itself? | |
| |
| #36 | manolo
06:35 May 10, 2016 |
| Add it to CREATE_EXAMPLE would make it apply to fluid also,
which is not necessary.
At this point only programs in test/ use the USING_XCODE preprocessor
variable.
But it would do no harm, I believe. | |
| |
| #37 | mjsurette
20:43 May 10, 2016 |
| fixMac.patch has been tested under Ubuntu and Mac.
Using Manolo's findings I have simplified the building of examples as much as I could while still having it work.
Fluid is not built using the CREATE_EXAMPLE function but it has also been simplified.
A patch to depricate UseFLTK.cmake will follow. | |
| |
| #38 | manolo
05:55 May 11, 2016 |
| fixMac.patch runs well with CMAKE under Mac OS X
and all apps wrae correctly bundled with correct icons.
There remains a minor problem
These statements:
set_target_properties(demo PROPERTIES RESOURCE "${CMAKE_CURRENT_SOURCE_DIR}/demo.menu")
expected to put file demo.menu within the bundle of the demo app
don't do it.
I will see if I find a way to get this result. | |
| |
| #39 | manolo
07:48 May 11, 2016 |
| To copy file demo.menu within the bundle of the demo app
under Mac OS X, put this in file test/CMakeLists.txt :
CREATE_EXAMPLE(demo "demo.cxx;${CMAKE_CURRENT_SOURCE_DIR}/demo.menu" fltk)
set_source_files_properties(${CMAKE_CURRENT_SOURCE_DIR}/demo.menu PROPERTIES MACOSX_PACKAGE_LOCATION Resources)
in replacement of statements related with demo | |
| |
| #40 | mjsurette
08:06 May 11, 2016 |
| Updated the patch to fix the demo problem.
The path was removed from demo.menu as unnecessary for the same reason that the path for menu.cxx is unnecessary.
Untested, please test. | |
| |
| #41 | manolo
10:04 May 11, 2016 |
| All good with fixMac-v2.patch | |
| |
| #42 | mjsurette
17:29 May 11, 2016 |
| Now tested on Ubuntu | |
| |
| #43 | mjsurette
22:41 May 11, 2016 |
| deprecate_useFLTK.patch transfers functionality from useFLTK.cmake to FLTKConfig.cmake. This removes the need to call useFLTK.cmake. | |
| |
| #44 | manolo
06:33 May 15, 2016 |
| Attached file #22 (cmakemac.patch) gathers all last
patches and a few more changes to copy support files
(e.g. demo.menu) for test apps within their bundles.
Tested OK on Mac OS and with USEX11.
@Albrecht: would you agree to commit it? | |
| |
| #45 | mjsurette
07:00 May 15, 2016 |
| I'll be as happy as anyone to see this one put to bed, but I assume that the second copy of FLTK-Functions.cmake in the root directory is an error. | |
| |
| #46 | manolo
08:48 May 15, 2016 |
| I believe there's a misunderstanding at comment #45.
cmakemac.patch is to be committed with :
cd <root-dir-of-source-tree>
patch -p0 < cmakemac.patch | |
| |
| #47 | mjsurette
09:02 May 15, 2016 |
| Yes, my bad, sorry for the noise. | |
| |
| #48 | AlbrechtS
07:58 May 16, 2016 |
| Fixed in Subversion repository.
Thanks to Manolo and Michael for all updates and tests. I committed Manolo's latest patch (#22: cmakemac.patch) with a few minor modifications.
I fixed a regression in UseFLTK.CMake that caused an external project that used 'include(${FLTK_USE_FILE})' to fail finding the FLTK include directories. I added a warning and restored the statement 'include_directories("@INCLUDE_DIRS@")' in the UseFLTK file for now.
Reasoning: Users should have a choice to use either 'include_directories' or 'target_include_directories', as appropriate for their projects. The recommended way to add the needed include directories is to use ${FLTK_INCLUDE_DIRS} in one of the above mentioned statements once a user does not include UseFLTK.CMake. I intend to document this in the README.CMake.txt file soon.
Note: I did not yet commit this in the porting branch. I'd like to wait a while until we're sure everything is complete. Tested on Linux, will test on Windows later.
Please test again... | |
| |
| #49 | manolo
08:41 May 17, 2016 |
| Tested OK with CMake on Mac OS X | |
