Developer Mode: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
(Fixing 5 grammatical errors) |
||
| Line 1: | Line 1: | ||
{{Stub}} | {{Stub}} | ||
{{See also|Startup Modes}} | {{See also|Startup Modes}} | ||
03/2017: James pushed a build system change <ref>https://sourceforge.net/p/flightgear/mailman/message/35666576/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/35692898/</ref>, to do the following: | 03/2017: James pushed a build system change <ref>https://sourceforge.net/p/flightgear/mailman/message/35666576/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/35692898/</ref>, to do the following: | ||
* define a FG_BUILD_TYPE in Cmake, with values ‘Dev’ (default), ‘Nightly’ and ‘Release’. (other values can be added if meaningful, eg ‘release-candidate’) | * define a FG_BUILD_TYPE in Cmake, with values ‘Dev’ (default), ‘Nightly’ and ‘Release’. (other values can be added if meaningful, eg ‘release-candidate’) | ||
| Line 9: | Line 7: | ||
* initialise the default value of this based on the build-type. | * initialise the default value of this based on the build-type. | ||
*Right now*, the only controversial thing is that Nightly builds default to developer-mode=true. - allow developer-mode to be forced on and off in *any* build from the command line —developer (switches it on) —developer=false (switch it off, for testing in a self-compiled build) - use this to switch the severity of the SG_DEV_WARN and SG_DEV_ALERT log messages up or down - replace all the previous compile-time conditional warnings controlled by ‘ENABLE_DEV_WARNINGS’ to be dev warnings at runtime. - report the build type in lots of places, eg via JSON, on startup, etc I also just updated the fgmeta build script used by Jenkins to pass (I hope!) correct values for FG_BUILD_TYPE to Cmake for our nightly and release builds, but this layer can be improved now, I guess. Please test: the new splash | *Right now*, the only controversial thing is that Nightly builds default to developer-mode=true. - allow developer-mode to be forced on and off in *any* build from the command line —developer (switches it on) —developer=false (switch it off, for testing in a self-compiled build) - use this to switch the severity of the SG_DEV_WARN and SG_DEV_ALERT log messages up or down - replace all the previous compile-time conditional warnings controlled by ‘ENABLE_DEV_WARNINGS’ to be dev warnings at runtime. - report the build type in lots of places, eg via JSON, on startup, etc I also just updated the fgmeta build script used by Jenkins to pass (I hope!) correct values for FG_BUILD_TYPE to Cmake for our nightly and release builds, but this layer can be improved now, I guess. Please test: the new splash screen shows a red warning text for Nightly builds, we could also show something in developer mode if it's useful. We can also discuss hiding UI elements or picking different defaults based on the developer mode; since it’s a run-time switch, we aren’t excluding anyone from contributing by hiding things in ‘out-of-the-box’ mode in release builds, is my opinion. Candidate things to hide, more suggestions welcome: - the entire Debug menu - wireframe mode in Rendering settings (and probably a few more things there) I will gradually review warnings for dev-mode suitability, using the ‘can an end-user do anything meaningful with this message?’ criteria, I believe Richard Harrison also volunteered to do a review of that. Any feedback on this system is welcome, we have a whole release cycle to decide what, if anything, we change in developer-mode vs normal. (Oh and the launcher will get an ‘enable developer mode’ checkbox shortly)<ref>{{cite web | ||
|url = https://sourceforge.net/p/flightgear/mailman/message/35693664/ | |url = https://sourceforge.net/p/flightgear/mailman/message/35693664/ | ||
|title = <nowiki> [Flightgear-devel] Developer-mode, warnings, build-type </nowiki> | |title = <nowiki> [Flightgear-devel] Developer-mode, warnings, build-type </nowiki> | ||
| Line 17: | Line 15: | ||
|script_version = 0.40 | |script_version = 0.40 | ||
}}</ref> | }}</ref> | ||
== References == | == References == | ||
{{Appendix}} | {{Appendix}} | ||
Latest revision as of 10:38, 14 June 2020
| This article is a stub. You can help the wiki by expanding it. |
See also Startup Modes.
03/2017: James pushed a build system change [1][2], to do the following:
- define a FG_BUILD_TYPE in Cmake, with values ‘Dev’ (default), ‘Nightly’ and ‘Release’. (other values can be added if meaningful, eg ‘release-candidate’)
- replace the existing FG_NIGHTLY and ENABLE_DEV_WARNINGS Cmake options
- add a /sim/developer-mode boolean flag
- initialise the default value of this based on the build-type.
- Right now*, the only controversial thing is that Nightly builds default to developer-mode=true. - allow developer-mode to be forced on and off in *any* build from the command line —developer (switches it on) —developer=false (switch it off, for testing in a self-compiled build) - use this to switch the severity of the SG_DEV_WARN and SG_DEV_ALERT log messages up or down - replace all the previous compile-time conditional warnings controlled by ‘ENABLE_DEV_WARNINGS’ to be dev warnings at runtime. - report the build type in lots of places, eg via JSON, on startup, etc I also just updated the fgmeta build script used by Jenkins to pass (I hope!) correct values for FG_BUILD_TYPE to Cmake for our nightly and release builds, but this layer can be improved now, I guess. Please test: the new splash screen shows a red warning text for Nightly builds, we could also show something in developer mode if it's useful. We can also discuss hiding UI elements or picking different defaults based on the developer mode; since it’s a run-time switch, we aren’t excluding anyone from contributing by hiding things in ‘out-of-the-box’ mode in release builds, is my opinion. Candidate things to hide, more suggestions welcome: - the entire Debug menu - wireframe mode in Rendering settings (and probably a few more things there) I will gradually review warnings for dev-mode suitability, using the ‘can an end-user do anything meaningful with this message?’ criteria, I believe Richard Harrison also volunteered to do a review of that. Any feedback on this system is welcome, we have a whole release cycle to decide what, if anything, we change in developer-mode vs normal. (Oh and the launcher will get an ‘enable developer mode’ checkbox shortly)[3]
References
| References |