2,561
edits
Howto:Submit patches: Difference between revisions
Jump to navigation
Jump to search
m
→Patch Guidelines
m (→Patch Guidelines: link) |
|||
| Line 8: | Line 8: | ||
** provide compile time switches to generally enable or disable your modifications (i.e. using #ifdefs, [http://sources.redhat.com/autobook/ autoconf and automake] macros) That way, you will ensure that your patch can be easily disabled (excluded from compilation while remaining in the source tree) if it should cause trouble while any issues are addressed. This applies in particular if your patch introduces any extra dependencies (i.e. libraries) or is any way platform specific. | ** provide compile time switches to generally enable or disable your modifications (i.e. using #ifdefs, [http://sources.redhat.com/autobook/ autoconf and automake] macros) That way, you will ensure that your patch can be easily disabled (excluded from compilation while remaining in the source tree) if it should cause trouble while any issues are addressed. This applies in particular if your patch introduces any extra dependencies (i.e. libraries) or is any way platform specific. | ||
** provide capabilities to enable or disable your code modifications at startup time or even at runtime, using command line options or preferably the PropertyTree/SGPropertyListeners and some simple GUI dialog to enable developers and users to decide whether they want to activate your code. That way, it can be ensured that your code doesn't interfere with any other FlightGear components. This will make potential bug tracking much easier and the chances of your code remaining in the source tree are much better as well. | ** provide capabilities to enable or disable your code modifications at startup time or even at runtime, using command line options or preferably the PropertyTree/SGPropertyListeners and some simple GUI dialog to enable developers and users to decide whether they want to activate your code. That way, it can be ensured that your code doesn't interfere with any other FlightGear components. This will make potential bug tracking much easier and the chances of your code remaining in the source tree are much better as well. | ||
** if you intend to add new features that may benefit from proper documentation, make sure to also provide patches to the documentation files provided under $FG_SRC/mini-docs and $FG_ROOT/Docs | |||
* Try to carefully document those passages in your source code that: | * Try to carefully document those passages in your source code that: | ||
** are non-obvious or unfinished | ** are non-obvious or unfinished | ||