Calendar:Build: Difference between revisions

Jump to navigation Jump to search

Calendar:Build (view source)

Revision as of 16:40, 25 February 2009

2,926 bytes removed ,  25 February 2009
Update Build guide
(Reverting my previous change; it's inconsistent with the rest of the page.)
(Update Build guide)
Line 22: Line 22:


=Getting the source=
=Getting the source=
''General documentation [http://developer.mozilla.org/en/docs/Mozilla_Source_Code_(CVS) here]''
There is extensive ''[https://developer.mozilla.org/en/Comm-central_source_code_(Mercurial) documentation]'' on how to get the Calendar source code on [https://developer.mozilla.org developer.mozilla.org].


Source code should be checked out via CVS. To do so you should first create your mozconfig. This is an example mozconfig for calendar which can be used:
The source code must be checked out via Mercurial (hg).


<pre>
In general, you should use a directory for the source code that does not contain spaces or such, i.e on windows "C:\Documents and Settings\MyUsername\My Documents\mozilla" is not a good choice.
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
 
mk_add_options MOZ_CO_PROJECT=calendar # We want to checkout calendar
Before you start to build, you will need to configure your build environment to build Lightning. Since Lightning is an extension it needs to be built together with its host application Thunderbird.
mk_add_options MOZ_CO_USE_MIRROR=1 # use cvs-mirror
# mk_add_options MOZ_CO_LOCALES=de # Can be used to also checkout a language
# mk_add_options MOZ_MAKE_FLAGS="-j3" # Can be used if you have multiple processors
mk_add_options JS_READLINE=1


# ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk # Needed on MAC
<pre># Enter the source directory
ac_add_options --enable-application=calendar # We want to build calendar
cd src (we assume that src/ is your source directory here)
ac_add_options --disable-installer # Installer not needed for development
ac_add_options --disable-airbag # I have had problems with airbag in the past
ac_add_options --disable-crashreporter # (Optional) Disable if you don't want it
ac_add_options --enable-debugger-info-modules=yes # More debug info
# ac_add_options --enable-debug # (Optional) Lots of debugging. Maybe more than you actually want!
ac_add_options --enable-extensions=default,lightning,inspector,venkman # Some extensions in the /extensions directory
ac_add_options --enable-tests # You should enable tests to make sure everything works before posting a patch
# ac_add_options --enable-system-cairo # I needed this on linux


# The following options can be used to reduce/disable debugging.
# Generate a mozconfig yourself, or use this minimal default one for Thunderbird
# ac_add_options --enable-optimize
echo 'ac_add_options --enable-application=mail' > .mozconfig
# ac_add_options --disable-static --enable-shared
# ac_add_options --disable-debug
</pre>
Save this file to your home directory to a file called ".mozconfig".


Now you can start checking out code. Use the following commands for the initial checkout. Do this in a folder where you want to have your tree. In general, you should use a directory that does not contain spaces or such, i.e on windows "C:\Documents and Settings\MyUsername\My Documents\mozilla" is not a good choice.
# Add calendaring to Thunderbird
echo 'ac_add_options --enable-calendar' >> .mozconfig


'''A note about versioning''': While with other projects like Firefox, TRUNK is the latest and greatest, calendar code is commited to both MOZILLA_1_8_BRANCH and TRUNK. This means the only differing factor is the mozilla codebase. We are currently releasing from the more stable MOZILLA_1_8_BRANCH, so you should also develop on this branch.
# Builds with the object directory the same as the source directory are not
# supported, so set the object directory here. Note: Whether you have the
# object directory within the source directory is up to you. .hgignore includes
# objdir-* and obj-*, making your object directory start with one of them
# will make change finding easier and hg faster, but moving it to outside
# will make things like grep easier and quicker as well.
echo 'mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-tb' >> .mozconfig


To clarify, Calendar version 0.8 is MOZILLA_1_8_BRANCH, while Calendar 0.6a1 is TRUNK.
# configure will be automatically generated using the 'autoconf-2.13'
# command.  If autoconf-2.13 isn't the right name for your system, as
# is the case on OS X using MacPorts and on Ubuntu Linux, use the
# real command name as demonstrated below. (Note: it's "autoconf2.13"
# rather than "autoconf213" for Ubuntu 8.04, at least.)
echo 'mk_add_options AUTOCONF=autoconf213' >> .mozconfig


<pre>
# Now do the build; configure will be run automatically
cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -r MOZILLA_1_8_BRANCH mozilla/client.mk
make -f client.mk build</pre>
cd mozilla
make -f client.mk checkout
</pre>


=Building the source (first time)=
=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.
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:
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.
<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=
=Running Lightning=
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>
This section assumes you have a working Thunderbird (3.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 for Lightning is <code>{3550f703-e582-4d05-9a08-453d09bdfdc6}</code>. You should use a separate profile for development, to not destroy your normal profile.


<pre>
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.
# 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>
<pre>
-g              (Mac,Linux) Start using gdb as a debugger
# Enter the Lightning directory in your object directory
-P <profile>    Start using a specific profile.
cd @TOPSRCDIR@/../objdir-tb/dist/xpi-stage/lightning
                Leave out <profile> to start the profile manager.
-console        (Windows) Open a console for debug messages
</pre>


=Running Lightning=
# Create a new profile directory
This section assumes you have a working thunderbird (2.0.0.*) 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 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>
cd $MOZILLA/obj-*/dist/xpi-stage/lightning
pwd > ~/.mozilla-thunderbird/<development profile path>/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}
pwd > ~/.mozilla-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>
thunderbird -P <development profile name>
thunderbird -P <development profile name>
Line 110: Line 84:


=Updating Calendar=
=Updating Calendar=
If something has changed in calendar code, you will want to get the latest changes. The general documentation suggests you use client.mk to checkout all changes:
If something has changed in calendar code, you will want to get the latest changes. The general documentation suggests you use client.py to get all new changes:


<pre>
<pre>
cd $MOZILLA
# Enter the source directory
cvs up -A -r MOZILLA_1_8_BRANCH client.mk
cd src
make -f client.mk checkout
</pre>


Fortunately, this is not needed very often, especially on MOZILLA_1_8_BRANCH. All you need to do is update the calendar directory. This is '''much''' faster than doing a full checkout.
# Update your local hg repository with the newest changes
 
python client.py checkout
<pre>
cd $MOZILLA/calendar
cvs up
</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)=
=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).
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==
==Lightning==
Line 155: Line 101:


<pre>
<pre>
cd $MOZILLA/obj-*/calendar/lightning
# Enter the Lightning source directory in your object directory
cd @TOPSRCDIR@/../objdir-tb/calendar/lightning
 
# Start building
make
make
</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.


=Debugging and Preferences=
=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].
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=
=Getting started with coding=
Line 184: Line 131:
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.
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.
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.


<pre>
<pre>
cd $MOZILLA/calendar
# Enter the source directory
cvs diff -u -U8 -p > ~/my_first_bug.diff
cd src


# To add a single new file to the patch
# Create the patch
diff -upN /dev/null base/content/path/to/file >> ~/my_first_bug.diff
hg diff >c:\my_first_bug.diff
</pre>


# To add all new files to the patch (advanced)
If you want to add new files, you will need to add those with the ''hg add'' command. After doing this, you can create the patch as described above.
for i in `cvs -n up 2>/dev/null | grep '^?' | awk '{print $2}'`; do diff -upN /dev/null $i >> ~/my_first_bug.diff; done
</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].
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].
Line 203: Line 149:
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 $MOZILLA/obj*/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 @TOPSRCDIR@/../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 CVS access yourself, the reviewer will generally take care of checking in the patch. If thats 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.


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.
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====
====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.


Line 234: Line 182:
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 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. '''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. 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>
# Enter the source directory
cd src


<pre>
# Overwrite all local changes
cd $MOZILLA/calendar
hg update -C
cvs up -C
</pre>
</pre>


Sipaq
287

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/130446"

Navigation menu