RULES ~~~~~ Submitting patches ~~~~~~~~~~~~~~~~~~ First, please, read all the sections below to get familiar with our build system and rules. When you feel comfortable with the code and decide to make your contribution to the project, please follow those guidelines: 1. One logical change per patch, the smaller the patch the easier it is for us to review and commit it. 2. Try to keep inline with the overall style of the code. 3. Provide detailed changelog for your patch. 4. If your patch requires updating the documentation (help, Enc., etc.), please provide the needed updates. 5. Patches should be submitted as a collection of diff files, the best and easiest way to create a patch is: svn diff > file.diff Please create the patch against the latest code from the repository. 6. To submit a patch you should send it to one of the people mentioned in the MAINTAINERS file, please use their preferred method of contact - either way patches should be submitted through Mantis or E-Mail only. You should receive a response about your submission in not more than 10 days. 7. If you plan on creating large patches or want to keep current with the development of Far Manager, subscribe to the Developers mailing list http://groups.google.com/group/fardeven (fardeven@googlegroups.com). 8. Frequent patchers will be eligible for full SVN access, by our discretion. 9. Be patient, we are new to Open Source :) Compilation ~~~~~~~~~~~ 1. To compile with VC you can either use the VS project file or makefile_vc. For example, to build with the makefile run the following command: nmake /f makefile_vc 2. To compile with GCC you can use makefile_gcc. For example, to build with Mingw run the following command: mingw32-make -f makefile_gcc Changelog - "changelog" file ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. All comments on committed changes should be written to the "changelog" file. You should leave comments in the source code only if you think the code is not self explanatory and won't be understood by "future generations". 2. Recent changes go on top. 3. Each entry starts with a header of the form: warp 05.12.2006 01:39:38 +0300 - build 2149 4. Changes not always require a build increase (i.e. cosmetic or non code related changes). farversion.m4 ~~~~~~~~~~~~~ 1. This file contains information used to generate Far version: a. BUILDTYPE, a string that defines the build type, can be: - `' - empty string - release version - `alpha' - alpha version - `beta' - beta version - `RC' - release candidate - `AnyThingElse' - intended for Far versions which code has not been committed yet to the SVN so we and the users will not be confused. Far version will look something like that: FarVersion alpha AnyThingElse based on build BuildNumber b. MAJOR - MAJOR Far version (i.e. 2). c. MINOR - MINOR Far version (i.e. 0). vbuild.m4 ~~~~~~~~~ 1. If the build number in "vbuild.m4" was changed then after committing the changes to the SVN you should call "svn_tag_build.bat". Adding new lines to language files ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. If you've added a new line to language files, you need to add the "upd:" prefix in farlang.templ.m4 to its variants that you did not translate. GCC - ensuring "successful" compilation with GCC ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Instead of postfixes i64 and ui64 use postfixes ll and ull. x64 - ensuring "successful" compilation for x86 and x64 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. DWORD_PTR, LONG_PTR, etc. are used instead of DWORD/long/etc. in the following cases: a) needed where previously int/long/dword/or_any_other_non_pointer_type were used and a pointer value was assigned to it. b) ... c) ... REMINDER ~~~~~~~~ Reminders, todos, notes should be written to the "REMINDER" file.