MozillaWiki

Calendar:Build: Difference between revisions

Calendar Discussion

Calendar:Build (view source)

Revision as of 08:47, 8 March 2009

1,347 bytes added ,  8 March 2009
Some updates for the 1.9 tree
(Update Build guide)
(Some updates for the 1.9 tree)
Line 3: Line 3:
This guide gives you all the information you need to get started with calendar development. While this guide might be quite long, I assume you will need 20-30 minutes ( + time to build the app) to set up everything and have a running development environment.
This guide gives you all the information you need to get started with calendar development. While this guide might be quite long, I assume you will need 20-30 minutes ( + time to build the app) to set up everything and have a running development environment.


Note this guide is written for use directly from the console. There is no known documentation to set up a build environment inside IDE's like eclipse. If you manage to set up eclipse for calendar, it would be great if you could contribute documentation!
Note this guide is written for use directly from the console. There is no known documentation to set up a build environment inside IDE's like eclipse or netbeans. If you manage to set up eclipse for calendar, it would be great if you could contribute documentation!


=Setting up prerequisites=
=Setting up prerequisites=
Line 11: Line 11:


====Additional, Mac-Specific info====
====Additional, Mac-Specific info====
You should install Xcode (i.e 2.4.1). This may be available on your MacOS Tiger restore CD (takes about ten minutes)
You should install the latest Xcode. This may be available on your MacOS Tiger restore CD (takes about ten minutes), but a later version is probably available at [[http://developer.apple.com/technology/xcode.html developer.apple.com]].


Next you need to install either Fink or MacPorts. I went with MacPorts. You can download it [http://svn.macosforge.org/repository/macports/downloads/MacPorts-1.5.0/ here]. Installing MacPorts is as simple as running the installer found in the mounted .dmg. (five minutes)
Next you need to install either Fink or MacPorts. I went with MacPorts. You can download it [http://svn.macosforge.org/repository/macports/downloads/ here]. Installing MacPorts is as simple as running the installer found in the mounted .dmg. (five minutes)


Next, use MacPorts to install libIDL (which also installs GLib). You will need to have your administrative password ready; takes around five to ten minutes, depending on your internet connection.
Next, use MacPorts to install libIDL (which also installs GLib). You will need to have your administrative password ready; takes around five to ten minutes, depending on your internet connection.
Line 31: Line 31:


<pre># Enter the source directory
<pre># Enter the source directory
cd src (we assume that src/ is your source directory here)
cd $COMM_CENTRAL (we assume that $COMM_CENTRAL is your source directory here)


# Generate a mozconfig yourself, or use this minimal default one for Thunderbird
# Generate a mozconfig yourself, or use this minimal default one for Thunderbird
Line 60: Line 60:
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.
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.


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.
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 Lightning=
=Running Lightning=
Line 69: Line 69:
<pre>
<pre>
# Enter the Lightning directory in your object directory
# Enter the Lightning directory in your object directory
cd @TOPSRCDIR@/../objdir-tb/dist/xpi-stage/lightning
cd $COMM_CENTRAL/../objdir-tb/dist/xpi-stage/lightning


# Create a new profile directory
# Create a new profile directory
pwd > ~/.mozilla-thunderbird/<development profile path>/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}
# This path is only valid for the standard UBUNTU thunderbird
# pwd > ~/.mozilla-thunderbird/<development profile path>/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}
 
# For other distributions, or if you downloaded Thunderbird off ftp.mozilla.org:
pwd > ~/.thunderbird/<development profile path>/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}
</pre>
</pre>


Now you can start thunderbird with your development profile.
Now you can start thunderbird with your development profile:


<pre>
<pre>
Line 81: Line 85:
</pre>
</pre>


This way, when you change code you will always be able to use the latest code, without reinstalling the extension.
This way, when you change code you will always be able to use the latest code, without reinstalling the extension. This profile will automatically contain Lightning.


=Updating Calendar=
=Updating Calendar=
Line 88: Line 92:
<pre>
<pre>
# Enter the source directory
# Enter the source directory
cd src
cd $COMM_CENTRAL


# Update your local hg repository with the newest changes
# Update your local hg repository with the newest changes
Line 101: Line 105:


<pre>
<pre>
# Enter the Lightning source directory in your object directory
# Enter the Lightning directory in your object directory
cd @TOPSRCDIR@/../objdir-tb/calendar/lightning
cd $COMM_CENTRAL/../objdir-tb/calendar/lightning


# Start building
# Start building
Line 108: Line 112:
</pre>
</pre>


After this you can start thunderbird with your development profile, and you should be up to date.
After this you can start Thunderbird with your development profile, and you should be up to date.
 
==Sunbird==
Sunbird can be compiled in parts, but its always a good idea to compile the most important parts together:
 
<pre>
# Enter the object directory
cd $COMM_CENTRAL/../objdir-tb
 
# Build all general calendar components
make -C calendar
 
# Build sunbird's components
make -C calendar/sunbird
</pre>


=Debugging and Preferences=
=Debugging and Preferences=
Line 135: Line 153:
<pre>
<pre>
# Enter the source directory
# Enter the source directory
cd src
cd $COMM_CENTRAL


# Create the patch
# Create the patch
hg diff >c:\my_first_bug.diff
hg diff > ../my_first_bug.diff
</pre>
</pre>


Line 149: Line 167:
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.
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@/../objdir-tb/calendar; make -C test check</code>).  
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 $COMM_CENTRAL/../objdir-tb/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) access yourself, the reviewer will generally take care of checking in the patch. If that's not the case, or he forgets to do so, you can add the <code>checkin-needed</code> keyword to the bug.
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) access yourself, the reviewer will generally take care of checking in the patch. If that's not the case, or he forgets to do so, you can add the <code>checkin-needed</code> keyword to the bug.
Line 156: Line 174:


====Applying a patch====
====Applying a patch====
''OUTDATED - WE NEED THE APPROPRIATE HG COMMANDS HERE''


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.
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. Mercurial (hg) has [[https://developer.mozilla.org/En/Mercurial_Queues an extension called mq]] which is of help in this case.


To apply a patch you need to find out what the path prefix is and match up the -p option. Assuming you or the other person used the process above to create the patch, you can use the following commands to apply the patch
To apply a patch you need to find out what the path prefix is and match up the -p option. Assuming you or the other person used the process above to create the patch, you can use the following commands to apply the patch
Line 167: Line 184:
# ahead cleanly. Be sure to run --dry-run at least once before running
# ahead cleanly. Be sure to run --dry-run at least once before running
# the actual patching process.
# the actual patching process.
patch -p0 -i ~/my_first_bug.diff --dry-run
patch -p1 -i ~/my_first_bug.diff --dry-run
# Now check if the patch applies cleanly, or you are willing to fix the  
# Now check if the patch applies cleanly, or you are willing to fix the  
# places it went wrong. When you are confident, you can call:
# places it went wrong. When you are confident, you can call:
Line 180: Line 197:
</pre>
</pre>


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.
In case you are interested, this is how it would work with mq:
<pre>
cd $COMM_CENTRAL
 
# Import the diff file into mq. This only needs to be done once.
hg qimport ~/my_first_bug.diff
 
# Try to load the patch
hg qpush
 
# If loading fails, then you can remove the patch again:
# hg qpop
 
# If the patch has rejects, you may resolve them and then refresh the patch:
hg qrefresh
</pre>
 
 
If some changes went wrong, patch will create rejects files. To resolve changes, you should open the current 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. Instead you might want to ask the person who created the patch to give you an updated version.


If you want to get rid of all changes at once, you can issue the following command. '''Warning''': This will get rid of all changes to the calendar tree you have made.
If you want to get rid of all changes at once, you can issue the following command. '''Warning''': This will get rid of all changes to the comm-central tree you have made locally (mail,calendar, ...)


<pre>
<pre>
# Enter the source directory
# Enter the source directory
cd src
cd $COMM_CENTRAL


# Overwrite all local changes
# Overwrite all local changes
XFallenAngel
264

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/132543"