| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3215
| 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: | add option to suppress CMake dependency on CMake generated buildfiles |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | mjsurette |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.3.4 (SVN: v10721) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | mjsurette
08:54 Apr 12, 2015 |
| The normal behaviour of CMake is to create build files which re-run CMake on a re-build. While this is useful if you're working on FLTK's CMake build system itself, it is not what you want if you want to distribute standalone build files.
While working on the CMake build system I discovered a CMake flag which suppresses this behaviour. This patch adds this option to FLTK's CMake build system with the default set to allow standalone build files. Developers working on the CMake build system can unset it while working on their features; others can safely ignore it in the default set state.
Due to a buggy implementation in earlier CMake 2.8 releases, this option will only be displayed in CMake 3.0.0 and later gui releases. Since this is a built-in flag it can be set by the command line in any version that supports it though. | |
| |
| #2 | AlbrechtS
10:00 Apr 12, 2015 |
| Thanks for the patch.
I don't understand "it is not what you want if you want to distribute standalone build files". But if I understand you correctly then I think that this is the exception rather than normality.
I think the normal use case of the FLTK CMake build files is to build FLTK and maybe install it. Everybody who wants to stay up-to-date with FLTK (e.g. by using svn or git) will also need to run CMake if the build files changed, for instance if a new file was added.
I agree that it is useful to have the option though, but I think the default should be OFF, unless I missed an important fact. Please correct me and elaborate if I'm wrong.
...
After a little searching and reading I found out that this is not even documented in the official (3.1 and 3.2) docs, nor is it in the latest "Mastering CMake" book (3.1). I only found it in <http://www.cmake.org/Wiki/CMake_Useful_Variables> and it is only one sentence. In another mail I found that this does not work for Makefile projects. So what is it really good for? MS IDE projects only?
That said, it might even be less useful, and maybe we shouldn't add it. We could add a sentence to the README though how to achieve it by running CMake with this option explicitly defined by the developer.
Back to "if we added it": do you also know in which CMake versions it is supported? What do you mean with "buggy"? Does it not show up in the cmake-gui options, or does it not work when generating the build files? | |
| |
| #3 | mjsurette
12:43 Apr 12, 2015 |
| I noticed this on the CMake Useful Variables page as well. Googleing it showed some of the same results as you had, including a bug report/fix for CMake 2.8.18 if memory serves. The fix target was shown as 3.0. The comment on Makefile projects was rather old and seemed to be addressed by the bug fix. That is what I meant by buggy. I was not overly concerned over the lack of documentation as the CMake Useful Variables page does mention that the official documentation of these variables is an ongoing effort. I can see this a being a low priority item for them as well. Not many projects are concerned with distributing their code to platforms that wouldn't support CMake.
CMake's normal operation is to call itself on any invocation of a build. It then checks if any of the CMakeLists.txt files have been updated and reconfigures accordingly. This would be akin to potentially calling configure on every build. The implication is that CMake would be required to build FLTK using any CMake generated build files, making them redundant as a distribute-able item. If CMake is required anyway, there is no point in distributing a CMake generated Makefile for example. I seem to recall a discussion on one of the forums about this where it seemed to be assumed that standalone buildfiles were the norm. This would be a natural assumption from someone used to 'configure' not being run by make.
CMake-gui only displays important options. This includes options that the CMake maintainers consider important like CMAKE_INSTALL_PREFIX or options the programmer shows that he considers important by adding them to the CMakeLists.txt like OPTION_USE_SYSTEM_LIBPNG. Other options can be added manually at the time of running cmake-gui, but are not presented as a choice. My personal view is that if an option is ever going to be used, it should be presented. This helps the people who aren't very familiar with the system from having to know what options are available and how to invoke them. They want to use FLTK with as little knowledge of how to build it as necessary.
This STR will need further testing to verify that build files of desired types are in fact standalone. The question of the proper default will also have to be addressed. While I have no real preference, further thought brings me to the realization that the only time this code would actually have to be suppressed is when you are creating buildfiles for distribution, so OFF would be a quite reasonable default as well. Either way, developers would be the only ones affected.
I hope this helps. | |
| |
| #4 | AlbrechtS
13:25 Apr 12, 2015 |
| Yes, it helps, thanks very much.
I agree with "if an option is ever going to be used, it should be presented", but I do also note that suppressing the normal CMake behavior with a non-standard, not very well documented option, should not be the default, because it would be surprising for dev's that know CMake.
We do not plan to distribute CMake-generated standalone build files at this time. We have been warned that hardcoded paths will be in the build files, e.g. IDE solution files, which would render these files useless on another system. This needs verification though. Therefore I was surprised that a CMake variable would disable the use of CMake in the generated build files to enable distribution of standalone build files. Anyway, if this changed and if we could indeed distribute CMake-generated IDE files this would be a big help in the future. OTOH we could require devs to use CMake, as it is done by other projects that rely on CMake.
I suggest that we add the option with default OFF and mark it "advanced". Since it is only for developers anyway, it can also be in the "hidden" advanced options. | |
| |
| #5 | mjsurette
00:42 Apr 13, 2015 |
| As discussed, default now OFF and option marked as advanced.
I hadn't thought of hardcoded paths, but the same goes for 'configure' generated makefiles. Also, I would expect a decent IDE to let you change the target path as well as other options, then regenerate its configuration file. The important part would be to have a reasonable base configuration which could be used by most users of a given platform.
I thought of another use case: users who can't or don't want to install CMake on their embedded systems. I do realize that CMake only is not something that will happen overnight, if ever, but the least that is lost if that happens, the better. | |
| |
| #6 | AlbrechtS
03:08 Apr 13, 2015 |
| Thanks for the update.
WRT hardcoded paths: we don't distribute configure-generated Makefiles either. We only use autoconf to generate 'configure', but ./configure must be run on the build host.
WRT embedded platforms: I believe it is very likely that embedded platforms lack a build systems and will be cross-compiled anyway.
Anyway, our current goal should be to get CMake working on all supported target platforms. The new feature would support users that want to port their development configurations (IDE's) to other build hosts that don't (need to) have CMake installed. I imagine this could work in companies that support development hosts that are configured very similar but don't need CMake on most of the development hosts. These systems might all have the same paths for system libraries, install dirs, etc. Or something like that.
Side notes: (1) I'm working with a company that uses the CodeLite IDE and we managed to put the CodeLite IDE files in the git repository so that it can be checked out on new build hosts. Everything is configured with _relative_ paths. We still use CMake on all build hosts to configure the Makefile's, but once configured we can build and debug from within the IDE).
(2) I tried to build the CodeLite IDE files for FLTK with CMake recently (which is a generator option), but this didn't generate the correct subprojects. But that's is another story... | |
| |
| #7 | AlbrechtS
15:58 Apr 25, 2015 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
