Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| ru:develop:guidelines [2014/06/12 15:55] – created valerius2k | ru:develop:guidelines [2018/08/17 14:43] (current) – [Присылая патчи с исправлениями (FIX THIS!!!)] valerius | ||
|---|---|---|---|
| Line 12: | Line 12: | ||
| |REXX | |REXX | ||
| - | Другие языки тоже могут быть использованы для разработки частей ОС. Но они тоже должны быть Open Source и использовать OS/2 API. Использование платных (то есть, которые могут быть скачаны с многих мест) не возбраняется, но не рекомендуется. | + | Другие языки тоже могут быть использованы для разработки частей ОС. Но они тоже должны быть Open Source и использовать OS/2 API. Использование платных |
| Когда существуют аналогичные инструменты (например NMAKE и WMAKE), всегда используйте инструменты из поставки OpenWatcom. | Когда существуют аналогичные инструменты (например NMAKE и WMAKE), всегда используйте инструменты из поставки OpenWatcom. | ||
| - | ==== Downloading and Compiling | + | ==== Получение и сборка исходных кодов |
| - | First of all you need to download all above tools for your platform from corresponding sites: | + | Сначала, |
| - | * [[http:// | + | * [[http:// |
| - | * [[http:// | + | * [[http:// |
| - | * [[http:// | + | * [[http:// |
| - | You can [[en:download|download]] non-regular source snapshot from the site or latest sources from SVN. osFree | + | Вы можете |
| - | Before compiling check files setvars-somename.cmd | + | Перед сборкой проверьте файлы |
| < | < | ||
| - | build process will be started. For clean up source tree say | + | начнется процесс сборки. Для очистки дерева исходников от созданных при сборке файлов наберите |
| < | < | ||
| - | For more information about build system read [[en: | + | Для более подробной информации о системе сборки см. документ |
| - | ==== The Directory Tree ==== | + | ==== Дерево каталогов |
| - | Please look at the SVN code tree to understand how files are to be placed. Please understand that the osFree | + | Посмотрите на код в Git-репозитории, |
| - | ==== Global/Shared/Private Headers | + | ==== Глобальные/Общие/Приватные файлы заголовков |
| - | Each level of the SVN tree contains two standard directories: < | + | Каждый уровень дерева исходных текстов содержит два стандартных каталога: < |
| - | |// | + | |// |
| - | |// | + | |// |
| - | Each levels/part of the OS should have a specific prefix that allows a developer to easily find what part of the OS a header/library file belongs to. For example code shared by the whole tree should be included with: | + | Каждая часть/уровень ОС должен иметь отдельный префикс, |
| <code c># | <code c># | ||
| - | and code shared by all commandline tools should include: | + | и код общий для утилит командной строки должен вклюачть: |
| <code c># | <code c># | ||
| - | Try to create as few shared code headers as possible. Each “shared” | + | Старайтесь создавать чем меньше общих заголовочных файлов, |
| - | Example of use of common files: | + | Пример использования общих файлов: |
| <code c>// Use the normal OS/2 INCL_ since our toolkit is the OS/2 toolkit | <code c>// Use the normal OS/2 INCL_ since our toolkit is the OS/2 toolkit | ||
| Line 74: | Line 74: | ||
| </ | </ | ||
| - | ==== Documentation | + | ==== Документация |
| - | * Private code (not shared with other code) should be documented only in the source. | + | * Приватный код |
| - | * Shared code (shared with code at the same level or at all levels) should be documented in source and in a “building and developing” document. | + | * Разделяемый код |
| - | * The API of the OS and the tools documentation should NOT be documented in the source tree but in the toolkit and release tree. | + | * ОС API и документация к утилитам тулкита НЕ должна находиться в дереве исходников, |
| - | * Source code should be documented in the source file (not the header files). | + | * Исходный код должен быть документирован в нем самом |
| - | * Each function should be prefixed with a description of what it does, what parameters it uses (in and out) and any external references it uses. | + | * Каждая функция должна предваряться специальным комментарием с описанием того, что она делает, |
| - | * Place comments in the source that helps the reader to understand the logic and don't overdo it. | + | * Размещайте комментарии в исходном коде таким образом, |
| - | ==== When Developing | + | ==== В процессе разработки |
| - | * Use static linking, do not use dynamic libraries | + | * Используйте статическую линковку, не используйте динамических библиотек |
| - | * Use the makefiles provided with the source tree, don' | + | * Пользуйтесь мейкфайлами из дерева исходников, не изобретайте свои собственные |
| - | * Currently | + | * На текущий момент разработка |
| - | * We use SVN to share code among developers. | + | * Мы используем Git для совместной разработки. |
| - | * We use Doxygen | + | * Мы пользуемся |
| - | ==== Submitting a Patch (FIX THIS!!!) ==== | + | ==== Присылая патчи с исправлениями |
| - | * Make sure your changes follow the coding guidelines above. | + | * Убедитесь, |
| - | * Make sure you are using the current versions of the sources so that the resulting diffs are comparing your changes with the head of the source tree. | + | * Убедитесь, |
| - | * Create your patch either by using cvs diff -u (if you are using CVS) or diff -u original-file changed-file (if you are using a source archive - you can also create differences for the whole directory contents using diff -r) In the latter case include the old code first, the new code last – in the patch anything you added will be prefixed with a +. | + | * Создавайте ваш патч используя git diff если вы используете Git) или |
| - | * Remove all/any lines that reference files without changes. | + | * Удаляйте из патча все несущественные строки. |
| - | * Send the patch file as an attachment in your email. Do not paste the patch directly into the email body. | + | * Присылайте патчи в виде прикрепленного к письму файла. Не вставляйте его прямо в тело письма. |
| - | * Maintainers will often reply in response to your patch, pointing out things to fix up, etc. before a patch can be checked in. Please always follow the maintainer suggestions closely and respond by sending a new corrected patch. Please do not expect the maintainers to rework your changes, you want to be able to claim all the credit for your great patches! | + | * Мейнтейнеры могут ответить вам на ваш патч, указав необходимые исправления, и др. перед тем, как патч будет принят. Всегда внимательно относитесь к замечаниям мейнтейнера и в ответ присылайте исправенные патчи. Пожалуйста, |
| ~~DISCUSSION~~ | ~~DISCUSSION~~ | ||