264
edits
Changes
Restore to 1.8 version
=Getting the source=
# The following options can be used to reduce/disable debugging.# ac_add_options --enable-optimize# ac_add_options --disable-static --enable-shared# ac_add_options --disable-debug</pre># Enter the source directorycd src (we assume that src/ is Save this file to your source home directory here)to a file called ".mozconfig".
=Building the source (first time)=
If you have not previously built the source with the tree you just checked out, you need to do a full compile. Depending on platform and computer specs, this might take a while (Example: MacBook Pro, 2.2Ghz, 2GB ram, ~25-30 Minutes) Go have a beer in between or whatever you prefer :-) This will not be needed as often later on.
Assuming you are still in the mozilla directory you changed to above, now issue the following command:<pre>make -f client.mk build</pre>This will build everything needed for calendar. If everything went well, the last output won't contain any errors and you are ready to start your development build of sunbird. If you run into problems, please see the [[Calendar:Build#Troubleshooting|troubleshooting]] section at the bottom of this page. =Running Sunbird=You will find the binary to start Sunbird under the following paths. I assume <code>$MOZILLA</code> is the mozilla directory you changed to above. The <code>obj-</code> part may vary depending on platform, build system, and number of bits. The path on Mac also differs (i.e CalendarDebug.app) if you use <code>--enable-debug</code> <pre># Windows$MOZILLA/obj-i686-pc-cygwin/dist/bin/sunbird.exe# Linux/Solaris$MOZILLA/obj-i686-pc-linux-gnu/dist/bin/sunbird# Mac$MOZILLA/obj-i386-apple-darwin9.2.2/dist/Calendar.app/Contents/MacOS/sunbird</pre> Some interesting command line switches:<pre>-g (Mac,Linux) Start using gdb as a debugger -P <profile> Start using a specific profile. Leave out <profile> to start the profile manager.-console (Windows) Open a console for debug messages</pre>
=Running Lightning=
This section assumes you have a working Thunderbird thunderbird (32.0.0 beta2 or later.*) installed. The best way to add Lightning to Thunderbird is to follow the [http://developer.mozilla.org/en/docs/Building_an_Extension#Test general steps], but for Lightning and Thunderbird. The extension ID id for Lightning is <code>{3550f703-e582-4d05-9a08-453d09bdfdc6}</code>. You should use a separate profile for development, to not destroy your normal profile.
The following steps make it easy on Linux, the profile path may be a bit different depending on your system. Remember to replace your profile name. This might also work out in a similar form on Windows and Mac.
<pre>
pwd > ~/.mozilla-thunderbird/<development profile path>/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}
</pre>
Now you can start thunderbird with your development profile.
<pre>
thunderbird -P <development profile name>
=Updating Calendar=
If something has changed in calendar code, you will want to get the latest changes. The general documentation suggests you use client.py mk to get checkout all new changes:
<pre>
</pre>
Go ahead and do the partial checkouts as long as you are able to compile calendar successfully. If you cannot the program to compile and you think it might have to do with other parts of mozilla (i.e toolkit), you can do a full update and compile.
=Building Sunbird and Lightning (after first time)=
After you have done a full build, it is usually not necessary to do the full build again for a while. The only case you might want to do a full build again is if something changed outside of calendar code that seems to affect building calendar (i.e a toolkit change).
==Sunbird==
Sunbird is usually much faster to compile, since you can selectively build parts of calendar, depending on what changed:
<pre>
cd $MOZILLA/obj-*/calendar
# The following command makes a full sunbird.
make && make -C sunbird
# If you didn't change anything in the calendar/sunbird directory
make
# If you only changed things in base/content or base/themes or prototypes/wcap
make -C base chrome
# If you only changed things in base, but the above doesn't seem to be enough:
make -C base
</pre>
'''Warning''': Especially if you make chrome, be sure that you don't have sunbird running. You may override your .jar files. If this happens, go into the top-level object directory and type make. This will remake all .jar files for the whole product (i.e including toolkit)
==Lightning==
<pre>
make
</pre>
After this you can start thunderbird with your development profile, and you should be up to date.
=Debugging and Preferences=
You should set up your debugging environment in the same way you would for extension development. A nice guide can be found [http://developer.mozilla.org/en/docs/Setting_up_extension_development_environment here on developer.mozilla.org].
=Getting started with coding=
After you have changed everything you wanted to, you should take a look at the [[Calendar:Style_Guide|Style Guide]], to make sure your code follow the calendar style guidelines we use.
Next, you need to create the patch. The following command can be used to create a patch of all ''changed'' files. Additional commands are needed if you added new files. If possible, you should always do the diff inside the <code>$MOZILLA/calendar</code> directory, so its easy to apply the patch.
<pre>
# Create To add a single new file to the patchhg diff -upN /dev/null base/content/path/to/file >c:\> ~/my_first_bug.diff</pre>
Now take a final look at the patch if it contains everything you wanted it to contain. You are ready to upload the patch to the bug. If there is no bug for your patch yet, you can [https://bugzilla.mozilla.org/enter_bug.cgi?product=Calendar&rep_platform=All&op_sys=All create one].
If you changed UI, its always a good idea to add a screenshot and request ui-review from a ui-reviewer. See also the module ownership page.
The review process usually starts off with a ui-review. It is possible, that the code reviewer will postpone the review until you have ui-review+, in case it is clear that the UI will stay as proposed. In the code review, the reviewer checks if the style fits the [[Calendar:Style_Guide|Style Guide]], and does a general check if the patch works as advertised. To ease review, you should make sure there are no (new) error console warnings or errors, and all tests pass (<code>cd @TOPSRCDIR@$MOZILLA/../objdir-tbobj*/calendar; make -C test check</code>).
As soon as you have r+ from all reviewers (r+ means having a positive review, also known as r=''shortname''), you should fix everything that was requested, and upload a new patch. Unless you have Mercurial (hg) CVS access yourself, the reviewer will generally take care of checking in the patch. If that's thats not the case, or he forgets to do so, you can add the <code>checkin-needed</code> keyword to the bug.
After the patch is checked in and all aspects of the bug are taken care of, the reviewer will resolve the bug as FIXED. The patch will then be available in the next spun nightly. When it is available, it is always a good practice to test the functionality using the original steps to reproduce. If everything works as proposed, you can set the bug as VERIFIED. If any regressions show up, you should file a new bug and set the <code>regression</code> keyword on it.
====Applying a patch====
From time to time, you might need to apply a patch from someone else, or maybe your own patch. This is quite easy, but note that if you plan on applying the patch, making some changes and then want to create a patch that doesn't contain the patch you originally applied, it might be quite a bit harder. This isn't very often the case though.
If some changes went wrong, patch will create rejects files. To resolve changes, you should open the original file and the rejects file. On large rejects files, you might want to open the rejects file twice so you can see the lines that need to be removed and the lines that need to be added at the same time.
If you want to get rid of all changes at once, you can issue the following command. If there are cvs conflicts, you might have to remove the files marked with "C ...", and then issue the command again. '''Warning''': This will get rid of all changes to the calendar tree you have made.
<pre>
</pre>
