FLTK logo

STR #2916

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 | SVN ⇄ GIT ]

STR #2916

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:Remove [CMake or] Autotools build system
Version:1.4-feature
Created By:astrand
Assigned To:AlbrechtS
Fix Version:1.4.0
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 astrand
01:26 Jan 17, 2014
fltk.spec
9k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#1 astrand
04:05 Jan 16, 2013
FLTK currently have two separate build systems: CMake and Autotools. It seems to me that very often changes are only done to one of them. The other one lags behind and gets out of sync. Since both systems supports cross compilation just fine, the project would benefit from just having to maintain one.  Therefore, my suggestion is to remove either the CMake or the Autotools build system.  
 
#2 mdickie
06:28 May 21, 2013
You're right. It's the best to have only build System.
Greeting,
Mariusz Wojcik
 
 
#3 AlbrechtS
04:57 Jan 11, 2014
In fact we do also support several versions of MS Windows IDE's (VC++) and XCode directly, so there are at least four different (partly) supported build tools.

This is done for user convenience, and if we can, we will probably support more than one build system in the future.

Although CMake appears to be able to create the build environments for all FLTK-supported environments, many (Linux/Unix/Mac) users expect the usual autoconf/configure/make to work w/o installing CMake. Windows users would often hesitate to install CMake, because they are not used to it.

I lowered the priority of this STR to RFE and tend to close it with "will not fix" status. More comments?
 
 
#4 astrand
23:47 Jan 12, 2014
For Windows and OS X, one solution could perhaps be to generate Makefiles with with cmake, and then commit/distribute them, so that you do not need cmake on the target system. That would be a better solution than trying to maintain manually crafted project files.

The argument that "many (Linux/Unix/Mac) users expect the usual autoconf/configure/make to work" is not very strong, IMHO. First of all, cmake is used by many large projects, see http://en.wikipedia.org/wiki/CMake#Notable_applications . Besides, FLTK is not a typical end user application but a system library and I don't think it's unreasonable that you need cmake to build it. Also, by avoiding multiple build systems, there will be less confusion (and bugs) for everyone.

Finally, if you/others believe that cmake is "not good enough", and that all the other build systems are necessary/wanted, then I think we should remove cmake instead, as the STR description points out.

This STR was opened up because we have had real problems with all the build systems getting out of sync. Something needs to be done.
 
 
#5 greg.ercolano
09:08 Jan 13, 2014
Perhaps put the cmake files in 'unsupported' so that its status is clear.

I rather Peter's suggestion though; would be interesting if there were nmake compatible Makefiles to build VS.

But I suppose if there's only one supported way to build for each platform, currently for Windows/VS that'd be the IDE files, much as
they can be a pain to manage. And they're huge. And seems like every
few VS releases we need new ones.. they really clutter up the distro IMHO.
 
 
#6 AlbrechtS
14:06 Jan 14, 2014
My gut feeling is: we need to learn CMake, maintain this in the future, and remove everything else - but that's probably too optimistic. It looks as if "the world" moves to CMake though...

However:

(1) I remember that Matt tried to use CMake-generated Xcode project files, and he wrote that he was disappointed. I don't know what the problems were, but I remember this clearly. I don't use Xcode myself.

(2) Matt also mentioned that the CMake people warned NOT to create (Windows/MS) VC++ project files and distribute them, since this might result in absolute file names in the generated project files, and hence they wouldn't be usable by end users (or other devs). Or something like that.

(3) Matt has put lots of effort in generating IDE files (VC++, Xcode) from within fluid. Although I personally don't think that this would be a good solution (too much effort if any IDE needs changes ?), he was obviously confident that this was the right way to go. IIRC he added more functions to FLTK 3 concerning generation of IDE files and even make files. However, these days Matt seems to be unavailable, and no one seems to be able or willing to continue his work :-(

That said, I'd be glad if we could switch to CMake and forget about autoconf and the others. But would this be a realistic approach? We'd need to test if VC++ and Xcode files can be generated today successfully for end users (CMake might have been improved), or we could say that everybody needs CMake...
 
 
#7 astrand
00:26 Jan 15, 2014
Thanks AlbrechtS, interesting. To me, it looks like the best approach would be to start with removing Autotools. This means that we will  gather more experience with CMake so that perhaps one day some or all of the other (Win/OSX) build systems could be removed as well. Or, it could turn out that we need to keep them after all. But in any case, IMHO, there are few arguments for keeping both Autotools and CMake. By choosing CMake, we will have more options when it comes to the other platforms.  
 
#8 AlbrechtS
03:42 Jan 15, 2014
Good points, thanks for your comments, Peter. I don't see any problems to remove the autotools build system when it comes to Unix/Linux, since installing CMake would be easy to do for developers and users.

I consider all platforms with a package installer system that support CMake as non-critical.

I just tested using Cygwin with its installed CMake, and it worked flawlessly, using X11. We could probably also do a cross compile with the MinGW compiler suite (32-bit and 64-bit), but that needs testing. This would enable Cygwin users to create native Windows programs w/o Cygwin dependencies (see also below).

One platform we should consider critical is MinGW. AFAIK there is no "native MinGW" CMake package that could be installed under MinGW. A quick search on the web with "mingw cmake" found the following link for cross-compiling with the MinGW toolchain under Linux, but I couldn't directly find a native MinGW solution.
http://www.cmake.org/Wiki/CmakeMingw
This link could also be helpful for Cygwin's MinGW cross compiler setup (see above).

However, we should also have a simple "native MinGW" solution with CMake. The current autotools way works OOTB (recently with a few new problems, though). Do you know how to set this up?

And yes, keeping the Xcode and VC++ project files together with CMake could be a good way to start.
 
 
#9 AlbrechtS
03:50 Jan 15, 2014
@Greg: I believe that I saw "NMake make files" as a supported generator option. If this is what you mean, that would be worth a try.  
 
#10 astrand
01:25 Jan 17, 2014
Hi. We do not have any experience with building on native MinGW platforms, ie on actual Windows machine. We are building FLTK for all our platforms (i386 x86_64 win32 win64 solsparc osx32 and soon ARMHF) in a Linux based cross compile environment. We are using CMake for all platforms. I'll attach our RPM spec file that does this. Although it's a bit specific for our build system, some parts might be useful/interesting.  
 
#11 AlbrechtS
18:46 Jan 20, 2016
Moved to 1.4-feature.  
 
#12 AlbrechtS
05:25 Jul 24, 2021
FTR: a current status of using CMake in FLTK 1.4 (Git):

Since we removed bundled IDE files in FLTK 1.4 Windows users need to generate their IDE files with CMake. This works flawlessly and is fully supported.

MinGW (the original one) may not provide their own CMake (do they?) but my experience shows that the "MinGW Makefiles" generator can be used by a standard CMake (GUI) downloaded and installed under Windows.

MinGW/MSYS2 (aka MinGW-w64) has its own CMake which can be installed and used to generate MinGW Makefiles but a "Windows CMake GUI" (downloaded from https://cmake.org/download/) can be used as well (I'm using this in my Windows test system).

That said, I'm confident that all platforms supported by FLTK can use CMake to build their Makefiles, IDE projects, Ninja or whatever build files.

IMHO we *could* /technically/ drop autotools if this was so decided without losing any build platforms.
 
 
#13 AlbrechtS
15:08 Jan 16, 2023
Note: I changed the title

from:
    "Remove CMake or Autotools build system"
to:
    "Remove [CMake or] Autotools build system"

This means that we will not consider removing CMake support, at least there are no plans to do this because we need it to generate all sorts of IDE projects and it has other advantages (OT to describe here).

IMHO it may be possible to remove the Autotools build system later, but this is not yet discussed nor decided.

Since the main part of this discussion is now about 8 years old. Many things have changed, and CMake is now fully established in FLTK 1.4.0.

I'm closing this STR now with the following statements:

--------------------------------------------------------------------------------

 - FLTK 1.4.x uses CMake as its primary, preferred, and supported build system.
 - Main development effort will go into further CMake improvements.
 - New features (build options) will [first] be added to the CMake system.
 - Therefore the autotools/configure/make build may lack some new features.
 - In the future we *may* remove the autotools/configure build system.
--------------------------------------------------------------------------------
 
     

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'.