Development:Building:Common make Targets

From Camino Wiki
Revision as of 13:38, 24 January 2009 by Sardisson (talk | contribs) (initial version of these tips)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

You can run make with several different targets to perform various tasks. Most interesting make targets can be found in mozilla/client.mk and various Makefiles, such as mozilla/camino/Makefile.in and mozilla/camino/installer/Makefile.in.

client.mk

Unless otherwise noted, all targets can be used with both make in the $OBJDIR and make -f client.mk in the $SRCDIR (or make in the $SRCDIR in a srcdir build after the initial client.mk-driven build).

  • build - This target triggers a full Mozilla build without performing a checkout (or update) first (this can only be used with make -f client.mk in the $SRCDIR; in the $OBJDIR, make with no target is the equivalent).
  • checkout - This target triggers a Mozilla cvs checkout (or update of an existing checkout) without subsequently performing a build (for obvious reasons, this can only be used with make -f client.mk in the $SRCDIR).
  • clean - Removes the object files and other generated files, as well as any files or directories in the GARBAGE or GARBAGE_DIRS Makefile variables (can only be used in the $OBJDIR in OBJDIR builds and in the $SRCDIR in non-OBJDIR builds).
  • distclean - Like clean, this removes intermediate build products (like object files), but it also removes any and all final build products in dist/ (can only be used in the $OBJDIR in OBJDIR builds and in the $SRCDIR in non-OBJDIR builds).
  • export - export is usually the first target run by build or a stand-alone make; it configures the build, generates headers from IDL files, and exports various headers to locations where other parts of the build process can find them. There are few situations where you would run this target by itself in a full Mozilla build.

camino/Makefile.in

Camino shares many of the targets above with client.mk; running the client.mk target will also run the corresponding Camino target.

  • clean - Removes the object files and other generated files, the build directory, as well as any files or directories in the GARBAGE or GARBAGE_DIRS variables of Camino Makefiles (can only be used in the $OBJDIR in OBJDIR builds and in the $SRCDIR in non-OBJDIR builds).
  • distclean - Like clean, this removes intermediate build products (like object files), but it also removes any of Camino's final build products in dist/ (can only be used in the $OBJDIR in OBJDIR builds and in the $SRCDIR in non-OBJDIR builds).
  • export - For Camino, when first called by client.mk’s export target, the export target sets up the Camino part of the OBJDIR. This involves symlinking the wallet files and most source directories and copying the project files without clobbering the personal settings contained within. You should re-run this target in your $OBJDIR each time the project file is updated, when the Makefile itself changes (it will update itself in the OBJDIR), or when a new subdirectory is added to mozilla/camino.
  • libs - This target is rarely called directly; however, it is the meat of a Camino build. The targets it depends on generate all of the Camino files that depend on preprocessing (e.g., all-camino.js, Info.plist, and all of the Localizable.strings and other .strings files. This target is also responsible for the embed-replacements system, for calling xcodebuild in the initial Mozilla build and in command-line Camino builds, copying the final Camino application to dist/, and handling the xpt files. After any .strings file changes, any updates to the Gecko milestone, or Camino version number change, the various dependent targets need to be re-run; the simplest way to do this is to simply make in $OBJDIR/camino (or mozilla/camino in a srcdir build).
    • N.B. Camino also has certain “external” pieces of code that are built only by recursive make and not by separate Camino Makefile targets or by project-related dependencies. If you do not make in Camino after these pieces of code are added or modified, your Xcode build will fail or will not pick up the changes.

Other useful make tricks

make is also capable of rebuilding directories selectively using -C directory rather than performing a full recursive build. Some scenarios where this is useful include:

  • Widget code - You've made changes to Cocoa widget code; as described in the build instructions, you can make in the Widget directory and then Camino to get the Widget changes into your build. From the root of your $OBJDIR, run the following command: make -C widget/src/cocoa; make -C embedding/config; make -C camino
  • Packaging a build - If you have a static build you want to distribute, you need to make in camino/installer to invoke the packaging mechanism. After making sure you have run a command-line build in Camino (to ensure all of the steps in the libs target have run, make -C installer; open ../dist from $OBJDIR/camino to generate the disk image and open the dist/ directory. (If you have a Universal build and you only want to package one half, ensure you are in the appropriate architecture subdirectory—$OBJDIR/ppc/camino or $OBJDIR/i386/camino—and run make -C installer UNIVERSAL_BINARY=.) N.B. There is some situation in which you will need to do a full build from make -f client.mk build before performing packaging; I can't remember what that is right now, though.
  • Rebuilding an “external” piece of Camino - Some “external” Camino dependencies (those bits of code in directories sitting directly in mozilla/camino rather than in mozilla/camino/src) have their own makefiles and can be built separately (they are normally built by recursive make from camino). If you were hacking on the feedhandlers or Flashblock, you may wish to check your changes by simply rebuilding them rather than all of Camino; from $OBJDIR/camino, run make -C feedhandlers or make -C flashblock to build these pieces. External pieces that are built using Xcode projects can generally not be built in this manner.