FLTK logo

STR #3055

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]

STR #3055

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:1 - Request for Enhancement, e.g. asking for a feature
Scope:3 - Applies to all machines and operating systems
Subsystem:Build Files
Summary:CMake enhancements
Version:1.3-feature
Created By:mjsurette
Assigned To:AlbrechtS
Fix Version:1.3.3 (SVN: v10343)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 mjsurette
14:37 Feb 20, 2014
cmake-zlib-move.patch
2k
 
 
#2 mjsurette
18:05 Feb 24, 2014
cmake-import-export.patch
22k
 
 
#3 mjsurette
18:37 Feb 25, 2014
cmake-missing-gleam.patch
0k
 
 
#4 mjsurette
06:17 Mar 02, 2014
APPLE-underscore.patch
2k
 
 
#5 mjsurette
13:20 Apr 13, 2014
macros.cmake
3k
 
 
#6 mjsurette
13:23 Apr 13, 2014
cmake-enhancements.patch
39k
 
 
#7 AlbrechtS
15:43 Sep 19, 2014
cmake-enhancements_r10324.patch
38k
 
 
#8 AlbrechtS
16:27 Sep 19, 2014
freetype.patch
1k
 
 
#9 AlbrechtS
16:56 Sep 19, 2014
cmake-complete.patch
43k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#1 mjsurette
14:37 Feb 20, 2014
The CMake files in FLTK are in need of overhaul so that CMake can be used to its full potential.  I intend to post several patches here which will end with the CMake Export/Import functionality fully operational.

My first patch will fix a dependency issue now existing in the CMake build.  The jpeg library depends on the zlib library but they're built in the opposite order.  This patch fixes that.
 
 
#2 mjsurette
18:18 Feb 24, 2014
This patch simplifies and standardizes much of the CMake build system. 

The aim and end result is that the export/import code works again.  It has been tested under Linux and g++ 4.8.2 and clang++ 3.4.  It will build fltk and an fltk project using CMake with fluid support for both installed an build directory use.  it has been tested with in-tree builds under g++.  No advanced CMake features were used so the minimum required CMake version remains at 2.6.

Please test and report and findings or bugs.
 
 
#3 mjsurette
18:40 Feb 25, 2014
While doing testing for Windows I discovered that it wouldn't compile because gleam.cxx wasn't in the file list.  Further digging found that neither was Fl_Help_Dialog_Dox.cxx.  This patch fixes that issue.  
 
#4 greg.ercolano
00:12 Feb 28, 2014
Thanks Mike, I guess we should all try to keep cmake in mind
when adding new .cxx files. Currently the list is:

    > Main Makefiles
    > Windows IDE files (VS)
    > Mac IDE files (Xcode)
    > Cmake

Perhaps there's others.. we should probably make a list and document
this in the CMP somewhere..
 
 
#5 mjsurette
04:43 Mar 01, 2014
Also passed testing under Linux w gcc 2.6  
 
#6 mjsurette
12:51 Mar 01, 2014
Also passes with TDM-GCC (a MinGW derivative) on Windows, with restrictions.  See STR 3060.  
 
#7 mjsurette
06:23 Mar 02, 2014
The FLTK developers use __APPLE__ to detect OSX.  For some reason CMake uses APPLE.  Given that the standards are that compiler defined macros should have a leading underscore, the safe choice is to follow the FLTK developers' lead.

This patch changes all uses of APPLE to __APPLE__ in the CMake files.

Untested, please test
 
 
#8 mjsurette
14:09 Apr 13, 2014
It didn't take long to realize that overlapping patches in such a small codebase as the CMake build system really sends the patch system into a really confused state.  In light of that I am submitting a one-patch plus one file solution.

The main drive for this was to get the import-export functionality going, but I also fixed some compiling errors and tried to generally simplify the system for easier maintenance.

The macros.cmake which belongs in the CMake folder, and cmake enhancements patch fix all the problems relating to the building of FLTK and using the CMake export/import system that I've found to date.  One exception being able to build both static and dynamic libraries under MSVC.  This is actually an improvement as the previous CMake system was not even successful with the static build.

Testing consisted of building FLTK both intree and out of tree and using each build for building a small fluid based project.

This testing was done for each of the following compilers.

Linux gcc 4.6.4
Linux gcc 4.8.2
Linux clang 3.4
Linux x86_64-w64-mingw32-gcc-4.8.2 (cross-compile for Windows)

Visual Studio Express 2013 for Windows Desktop
tdm-gcc 4.8.1-3

Testing was not what I would call extensive, but I don't think I missed too much. I'm hoping that others will test it and report any missed bugs.  The limitation of only being able to build static libraries under the Microsoft compiler is one that I intend to fix, but I find that I don't have the CMake-foo for that at the moment and I unfortunately need to concentrate on other projects for a little while.  Any suggestions on that issue are welcome as well.  The other facets of this STR, the Doxygen support and improved fltk-config will also follow later.

See the updated README.CMake.txt for details on how to use the export/import functionality.

For now testing, especially in the Microsoft and Apple camps would be appreciated.
 
 
#9 AlbrechtS
14:59 Sep 19, 2014
Regarding comment #7, changing APPLE to __APPLE__:

Are you sure this is correct? Aren't you mixing CMake variables ("APPLE") and compiler/preprocessor macros ("__APPLE__")?

According to http://www.cmake.org/Wiki/CMake_Useful_Variables
"APPLE is TRUE on Apple systems. Note this does not imply the system is Mac OS X, only that __APPLE__ is #defined in C/C++ header files. ..."

And, BTW, I found some occurrences where APPLE was not changed in file #6 cmake-enhancements.patch, e.g.

"+if((NOT APPLE OR OPTION_APPLE_X11) AND NOT WIN32)"

I may be wrong though...
 
 
#10 AlbrechtS
15:43 Sep 19, 2014
Updated patch to match svn r10324, see attached file cmake-enhancements_r10324.patch.

Unfortunately this breaks at compile time with the same error message under Cygwin (sic!) and Fedora 19 (64-bit, BTW), because the freetype headers are not found. I'll post a patch for the patch in a few minutes.

Note that the freetype header file is in /usr/include/freetype2/freetype/freetype.h in both cases.
 
 
#11 AlbrechtS
16:27 Sep 19, 2014
Freetype adjustments, see attached file freetype.patch.

This file must be applied after cmake-enhancements_r10324.patch (#7) and needs CMake/macros.cmake (#5).

Note that I _added_ another path to the checks so that it should work with both path versions (if it worked before at all, and there may be different paths for the freetype headers). But maybe the old version was just wrong, then we should only add the corrected path.

Results: configures, builds, and runs on all three currently tested platforms:

- Linux  (fedora 19,  64-bit, g++ (GCC) 4.8.2, X11)
- Cygwin (pretty old, 32-bit, g++ (GCC) 4.5.3, X11 (sic!))
- MinGW  (pretty old, 32-bit, g++ (GCC) 4.7.2, GDI)

Bugs/errors/warnings:

Under Cygwin there are multiple warnings like these:
...
[ 98%] Building CXX object test/CMakeFiles/unittests.dir/unittests.cxx.o
Linking CXX executable ../bin/examples/unittests.exe
c++: unrecognized option '-pthread'
[ 98%] Built target unittests
[ 99%] Building CXX object test/CMakeFiles/utf8.dir/utf8.cxx.o
Linking CXX executable ../bin/examples/utf8.exe
c++: unrecognized option '-pthread'
[ 99%] Built target utf8
[ 99%] Generating valuators.h
[100%] Building CXX object test/CMakeFiles/valuators.dir/valuators.cxx.o
Linking CXX executable ../bin/examples/valuators.exe
c++: unrecognized option '-pthread'
[100%] Built target valuators

These warnings appear for ALL executables that are built.

I remember that I saw such warnings before when I tested with MinGW on another system than the one I tested today (Win7).

BTW: I apologize for the long delay. I've been very busy meanwhile and on vacation.

Now I would like to apply as much as we can w/o breaking much (__APPLE__ ?), so that we can close this STR. Note that I can't test on Mac OS X.

Once this is done, we should check this -pthread thing (I can test with MinGW, Cygwin, and Linux).

Then there are two more related STR's: #3011 and #3045 that should be checked - the patches given there are hopelessly outdated though. Sigh :-(
 
 
#12 AlbrechtS
16:56 Sep 19, 2014
Uploaded cmake-complete.patch. This is a complete patch, including macros.cmake and freetype.patch.  
 
#13 mjsurette
06:49 Sep 20, 2014
Welcome back from your vacation Albrecht, and thank you for your detailed look at, and updates to, this STR.

You are right about the APPLE/__APPLE__ definitions.  They are both defined, the first by CMake and the second by Clang.  This renders the whole point of which to use moot.  The reason I originally thought it was important was when TDM-GCC failed to compile FLTK due to it not supplying the no-underscore macros.  I had assumed that Clang might do the same, being known for being quite pedantic.  As for the omissions in the patch, that was simply an error on my part.

The freetype header search that was already there was what worked on the systems I tested on.  Your addition which adds more distros into the working set is awesome.  Let's hope that covers the gamut.

I'm sure that by now you've found that OP for STR 3011 has verified that the only problem he has left is with the CMake version of fltk-config, which is on my todo.

STR 3045 was an attempt to get the freetype headers and scandir logic right.  It has been applied, but it seems it was waiting for your fix.

From the limited research I have done, the -pthread option is GCC specific and combines -D_REENTRANT, and linking with -lpthread.  I would expect that it wouldn't take much in the line of logic changes to fix your issue.
 
 
#14 AlbrechtS
17:06 Sep 25, 2014
Michael, you're welcome; and thanks for your comments.

I prepared another patch that reverted the APPLE/__APPLE__ patch, so that we will then use APPLE again. I think that's covered by the docs and should work. Do you agree?

You may have noticed that I closed STR #3045 meanwhile.

The -pthread issue doesn't appear on a newer Cygwin installation. It's only a warning anyway, so it can be ignored for now.

I'll take another look at the patch and do some tests at the next weekend. I hope that I can commit it then.
 
 
#15 AlbrechtS
17:55 Sep 26, 2014
Fixed in Subversion repository.

Updates in svn r10342 and r10343.

FYI:

I did not use the APPLE/__APPLE__ patch.
I removed the check for the unused function strtoll().
I removed some trailing white space from README.CMake.txt.

Other than that the patch should be as discussed.

@Michael: Thanks again for all your work on FLTK's CMake support! It is very much appreciated.

@ALL: please test on as many platforms as you can. Feedback appreciated.

This STR will be closed in a few days unless there are problems with the installed updates. If there are new issues, please open another STR.
 
     

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.