OmniMake Features Overview
Last modified November 17th, 1997 - luke

After working on several multideveloper, multiplatform OPENSTEP projects, Omni has come up with a series of enhancements to the Apple build system which speed development, reduce bugs, and generally make your life easier---we call it, unsurprisingly, "OmniMake".

Here's a quick overview of system benefits:

- Avoids conflicting framework search paths caused by different developers installing their frameworks in separate locations. Especially nice since in some cases, invalid framework search paths can cause compilation to fail.
- Keeps object files, derived source, and product binaries out of the source tree, and thus the repository. This source/product organization system also makes it easy to develop with remote source trees, and allows you to backup project source without backing up large, reproducable products.
- Fixes several bugs with .DEF file generation under NT, allowing functions and other symbols to be exported by frameworks properly.
- Increases application performance by setting framework base addresses, and avoiding dynamic relocation at run-time.
- Provides an easy way to set framework installation paths without actually installing frameworks. This is very useful when the default installation strategy (copying the product from one location to another) doesn't fit the installation model well.
- Provides convenience targets for updating projects and project components from the source repository.
- Enforces compilation with full warnings enabled, rather than the default setting which lets some legitimate warnings slip by unannounced.
- Automatically makes explicit references to symbols in each of the omnimake-built frameworks, ensuring that those frameworks get loaded at application run-time. This is necessary on NT.
- Suppresses unnecessary build output, letting you see errors and warnings as easily as possible.
- Completely disables "clone headers", a feature which we found to be more troublesome than not. Replaces this mechanism with a simple copy operation.
- Provides targets for creating optimized, debug builds--something you cannot do with the default Apple Makefiles.
- Fixes several bugs which appear when trying to compile a common codebase on all supported OPENSTEP and PDO platforms.

OmniMake works primarily by taking advantage of the LOCAL_MAKEFILEDIR extension hooks provided by Apple. Using that mechanism to customize the build process, we've plugged in our own Makefiles, scripts, and compiled tools which provide the benefits listed above.

We've also written a series of bundles for ProjectBuilder which make using the OmniMake system very simple. Essentially, when you open a project, you are presented with a panel displaying the differences between the default build settings and the "omnimake" build settings. You can then choose to: 1) reset the project settings to the "omnimake" values, 2) leave the settings as they are and don't ask again for this project, or 3) put off the decision until the next time you open this project.

After installing the appropriate bundles, there are only two rules to remember for general use. 1) When adding a framework to a project, don't add that framework to the "Framework Search Path". OmniMake takes care of this automatically and prevents conflicting search paths from being hard-coded into the PB.project file--and, 2) When building from the command line, invoke "omnimake" rather than "gnumake" for projects configured to use the OmniMake system.

It's worth noting that OmniMake isn't exclusive with the default build system (the exception being on NT). OmniMake doesn't override any environment variables used directly by Apple, nor do we change gnumake in any way. On OPENSTEP/mach, Rhapsody, & the various incarnations of PDO, no Makefile patches are required. The only caveat is that we completely override .DEF file generation on NT by directly patching the Apple Makefiles. In future version of OPENSTEP Enterprise, this requirement may be eliminated.