|
DeveloperGuide
Guide for new developers.
The Evoke PlatformEvoke LibraryWARNING, THE EVOKE API IS NOT SET IN STONE YET V_ObjectThe basic composite data-type for the Evoke library is the 'V_Object'. A V_Object is a data structure very similar in spirit to the BMessage of BeOS and Haiku. They are a data structure which are typed, and which contain one or more data fields, all with a unique name, and all typed. It is meant to allow passing of composite data types from one function to another, without resorting to blind pointer dereferencing. Functions should also not access the V_Object directly, but instead use the following functions:
Programs must always use the function error() and evaluate the return value on any V_Object they recieve. This function checks for NULL pointers, and looks for the general error datatype. For example: V_Object * socket = V_Dial("invalid string", 0);
if (V_ErrorPrint(socket)) {
V_ErrorPrint(socket);
V_Exit(socket);
}This should be self explanatory, if the V_Dial call returns an error, the message string is printed, and the process exits with the proper errno. V_ObjectDataV_StringA V_String is a composite 'string' data type, containing a pointer to the string, and it's length. The following are the public elements:
Object TypesObject types are typically expressed in three ways. Currently there is only one hard restriction on types, which is that mime types cannot be used for the application signature. Mime TypesThe ubiquitous mime-type, which is conventionally used for V_ObjectData types, and file types. ex.
Signature TypesSignature style types, which are inverted domain name style types, typically used for application signatures and V_Object types. The / character is explicitly disallowed. Occasionally used for V_ObjectData. ex.
Quick TypesThese are used internally by V_Object. Since they are all 4 bytes in size (or less), they replace the pointer. They are almost always basic data types. ex.
Evoke program guideDefault OPTIONS values:
Command based programsExample: Search UI programsExample: File operation based programsFile operation programs must take a list of files as their argument list, each file in a seperate argv entry in the array. All options are based via OPTIONS. Example: Using the SVN RepoCheckoutIt is highly recommended that you at least check out the tools, and add them to your PATH, before any other paths. svn https://evoke.googlecode.com/svn/tools evoke-tools Commit Log format* Item A * Item B * Item C For certain commits, a short description line is necessary, like so. Description * Item A * Item B * Item C Special CommitsIssueAny commit directly or indirectly resulting from an issue, must have the following form: Issue from id1 id2 id3 ... * Item A * Item B * Item C The third field, and every field till the end of line MUST be a valid issue id number. Make sure to check the issue tracker for any issues that may be directly or indirectly related to the commit in question. This is so that in the future, we can trigger automatic hints to test possible fixes. AQAAQA's are automated quality assurance tests. They get a special description, when a fix for a bug discovered through one of these tests. Note that right now the AQA's don't live up to the 'A' portion, but they will soon. The commit message is as follows: AQA from HPAT run number: 6daae55f-f516-4afd-8a95-59e02fb8d830 * Item A * Item B * Item C The sixth field /must/ be the uuid of the run. This is done for accounting purposes. The third field is the test short name, one of the following:
Release Engineering GuideCreating a Release Branch(All commands relevant to /, not /trunk) To initially create a release branch, always use the following steps: svn copy trunk branches/releases/0.2/R1 R1 is always the first revision. Next, add a release page: svn add wiki/Release02.wiki There is only one release page per release, so ignore the revision. The first thing to do is fill out the release page with the todo list: #summary 0.2 Release Notes == Todo == * any items that need to be done before R1 Now, we commit: svn commit The format of the commit message is similar to 'Merge', except the items are not commit logs that apply, rather, it is the contents of the initial Todo list. Branch /trunk rREVISION to /branches/releases/0.2/R1 * any items that need to be done before R1 Then, we need to copy the wiki into the branch, like so: svn copy wiki branches/releases/0.2/R1/doc Finally, we commit: svn commit The format of the commit message is similar to 'Merge', however, the item list should be a todo list for the documents. Branch /wiki rREVISION to /branches/releases/0.2/R1/doc * any items that need to be done before R1 'Setting' a release branchWhen the binaries for a revision of a release branch are finished, and placed on the http mirror, you must set a property on the copy of the release tree. After this point, NO more commits may happen to that revision. You must create a new revision of the release branch and work on that. You should set it with this command: svn propset evoke-binaries-built "" https://evoke.googlecode.com/svn/branches/releases/0.2/R1 Back merging changes into a release branchUse the backmerge utility in tools/, like so. cd branches/releases/0.1/R1/ backmerge Note that there is no options to the utility yet. When we need them, I will add them. Creating a new revisionAs stated earlier, you cannot commit to a revision after the binaries have been built, therefore you must do a copy, like so: svn copy https://evoke.googlecode.com/svn/branches/releases/0.2/R1 https://evoke.googlecode.com/svn/branches/releases/0.2/R2 The rules for creating binaries apply to every revision, not just the first revision. In this way, our boot versioning system can be used by the users effectively. |
► Sign in to add a comment