Approach 1: Use architecture-specific subdirectories

Learn how to use architecture-specific subdirectories to segregate derived objects of different variants.

Each variant of an application can be built in its own subdirectory of the source directory. For example, if the source files for the executable monet are located in the directory /usr/monet/src, the variants can be built in subdirectories /usr/monet/src/sun5, /usr/monet/src/sles15, and so on. The simplest approach is to have the makefile create view-private subdirectories for this purpose. But if you want to use different derived object storage pools for the different variants, you must create the subdirectories as elements (mkdir command) and then adjust their storage pool assignments (chpool command).

Because the derived objects for the different variants are built at different path names (for example, /usr/monet/src/sun5/main.o), they are segregated by variant, and clearmake never winks in an object built for another architecture.

This approach has several advantages:

  • All variants of the application can be built in a single view.
  • You do not need to consider whether to suppress winkin for some or all targets.
  • Because the derived objects for different variants have different path names, it is easier to organize multiple-architecture releases.

But this approach might require changes to build scripts: the binaries for a build are no longer in the source directory, but in a subdirectory. The build script in Alternative approach using imake is structured for this situation:

main.o: $(SRC)/main.c
 .
 .