ru:develop:guidelines

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Last revisionBoth sides next revision
ru:develop:guidelines [2014/06/12 16:16] – [The Directory Tree] valerius2kru:develop:guidelines [2018/08/17 14:39] – [В процессе разработки] valerius
Line 12: Line 12:
 |REXX             |ReginaREXX     | |REXX             |ReginaREXX     |
  
-Другие языки тоже могут быть использованы для разработки частей ОС. Но они тоже должны быть Open Source и использовать OS/2 API. Использование платных (то есть, которые могут быть скачаны с многих мест) не возбраняется, но не рекомендуется. Также, используйте инструменты из поставки OpenWatcom для сборки ваших исходников.+Другие языки тоже могут быть использованы для разработки частей ОС. Но они тоже должны быть Open Source и использовать OS/2 API. Использование платных и shareware (то есть, которые могут быть скачаны с многих мест, но стоят денег и лицензия которых имеет много ограничений) не рекомендуется. Желательно использовать инструменты из поставки OpenWatcom для сборки ваших исходников.
  
 Когда существуют аналогичные инструменты (например NMAKE и WMAKE), всегда используйте инструменты из поставки OpenWatcom.  Когда существуют аналогичные инструменты (например NMAKE и WMAKE), всегда используйте инструменты из поставки OpenWatcom. 
Line 18: Line 18:
 ==== Получение и сборка исходных кодов ==== ==== Получение и сборка исходных кодов ====
  
-Сначала, вы должны загрузить ниже перечисленные инструменты для вашей платформы с соответствующих сайтов:+Сначала, вы должны загрузить нижеперечисленные инструменты для вашей платформы с соответствующих сайтов:
  
   * [[http://www.openwatcom.org/]] для OpenWatcom   * [[http://www.openwatcom.org/]] для OpenWatcom
Line 24: Line 24:
   * [[http://regina-rexx.sf.net/]] для ReginaREXX   * [[http://regina-rexx.sf.net/]] для ReginaREXX
  
-Вы можете [[ru:download|загрузить]] нерегулярно обновляемые снапшоты исходников с этого сайта, или самые последние версии с SVN. Исходники osFree находятся на [[http://osfree.svn.sourceforge.net/viewvc/osfree/|Sourceforge SVN]]. Sourceforge также позволяет скачать любую ревизию в виде .tar.gz архива.+Вы можете [[ru:download|загрузить]] нерегулярно обновляемые снапшоты исходников с этого сайта, или самые последние версии из Git. Исходники osFree находятся на [[https://github.com/osfree-project/osfree/|GitHub]]. GitHub также позволяет скачать любую ревизию в виде .tar.gz архива.
  
 Перед сборкой проверьте файлы setvars-<somename>.cmd и <somename>.conf, И поменяйте настройки (в основном, пути к инструментам разработки). После этого откройте сеанс командной строки и запустите setvars-<somename>.cmd и введите Перед сборкой проверьте файлы setvars-<somename>.cmd и <somename>.conf, И поменяйте настройки (в основном, пути к инструментам разработки). После этого откройте сеанс командной строки и запустите setvars-<somename>.cmd и введите
Line 34: Line 34:
 <code>wmake clean</code> <code>wmake clean</code>
  
-Для более подробногй информации о системе сборки см. документ [[en:bldenv|Система сборки]].+Для более подробной информации о системе сборки см. документ [[en:develop:bldenv|Система сборки]].
  
 ==== Дерево каталогов ==== ==== Дерево каталогов ====
  
-Посмотрите на код в SVN, для понимания принципа размещения файлов. Обратите внимание, что дерево файлов в SVN osFree состоит из исходных кодов операционной системы и инструментов тулкита. Пожалуйста, НЕ помещайте сюда приложения и инструменты, не соответствующие назначению тулкита. Тулкит это вспомогательные утилиты, собираемые под ту систему, под которой ведется сборка и необходимые для сборки файлов ОС.+Посмотрите на код в Git-репозитории, для понимания принципа размещения файлов. Обратите внимание, что дерево файлов в SVN osFree состоит из исходных кодов операционной системы и инструментов тулкита. Пожалуйста, НЕ помещайте сюда приложения и инструменты, не соответствующие назначению тулкита. Тулкит это вспомогательные утилиты, собираемые под ту систему, под которой ведется сборка и необходимые для сборки файлов ОС.
  
-==== Global/Shared/Private Headers ====+==== Глобальные/Общие/Приватные файлы заголовков ====
  
-Each level of the SVN tree contains two standard directories: <code>FIX THIS! Now it's slightly different!</code>+Каждый уровень дерева исходных текстов содержит два стандартных каталога: <code>FIX THIS! Сейчас это немного не так!</code>
  
-|//shared//  |Contains code shared among all source at this level and deeper levels | +|//shared//   |Содержит код, общий для данного и более глубокого уровней вложенности каталогов | 
-|//include//  |Contains header files for the above |+|//include//  |Содержит заголовки для всего выше перечисленного |
  
-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>#include <all_shared.h></code> <code c>#include <all_shared.h></code>
  
-and code shared by all commandline tools should include:+и код общий для утилит командной строки должен вклюачть:
  
 <code c>#include <cmd_shared.h></code> <code c>#include <cmd_shared.h></code>
  
-Try to create as few shared code headers as possible. Each “shared” directory should contain one (1) library (.lib) file (xxx_shared.lib) with all shared code and each “include” directory should contain one main header file including all other (xxx_shared.h).+Старайтесь создавать чем меньше общих заголовочных файлов, тем лучше. Кадждый “shared” каталог должен содержать один (1) библиотечный (.lib) файл (xxx_shared.lib) со всем общим кодом и каждая “include” директория должна содержать один главный заголовочный файл, включабщий все другие (xxx_shared.h).
  
-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:
 </code> </code>
  
-==== 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. +  * Разделяемый код (разделяемый на одном уровне, или же разделяемый со всеми уровнями) должен быть документирован в исходнике и в документе “[[en:develop:bldenv|Разработка и сборка исходников]]”. 
-  * 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 (LIBC style) or dynamic runtime. +  * Используйте статическую линковку, не используйте динамических библиотек (LIBC style) или динамических рантаймов. 
-  * Use the makefiles provided with the source tree, don't “do your own”. +  * Пользуйтесь мейкфайлами из дерева исходников, не изобретайте свои собственные “велосипеды”. 
-  * Currently osFree development is done on OS/2 (minimum Warp 4) but in the future development will be hosted on osFree. +  * На текущий момент разработка osFree происходит в среде OS/2 (как минимум, Warp 4), но в будущем разработка будет производиться в самой osFree ("self-hosting"). 
-  * We use SVN to share code among developers. +  * Мы используем Git для совместной разработки. 
-  * We use Doxygen and Wiki to document our work.+  * Мы пользуемся Doxygen и Wiki для документирования своей работы.
  
-==== Submitting a Patch (FIX THIS!!!) ====+==== Присылая патчи с исправлениями (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. +  * Убедитесь, что у вас исходники последней версии,чтобы ваши патчи соответствовали текущей головной ветви (trunk). 
-  * 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 +. +  * Создавайте ваш патч используя cvs diff -u (if you are using CVS) или diff -u original-file changed-file (если вы используетсе архив с исходниками, или просто изменения к целому дереву файлов, используйте diff -r). В последнем случае, исходный код указывайте первым параметром, и измененный -- вторым.  Тогда все ваши изменения будут добавлены в патч с префиксом "+". 
-  * 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~~