CODEWITHSUNDEEP
makefilebuild-automation
Maxpm
Maxpm

Reputation: 25592

Makefile Support for Multiple Architectures/Configurations

What's the easiest way to give a makefile support for multiple architectures and configurations? For example, a release configuration might use more optimization than a debug configuration. Should the changing options be defined as variables in the makefile, and users be relied on to update them as needed?

# Change to -O2 for release.
COMPILER_OPTIONS := -arch x86_64 -O0

Or should this sort of thing be handled in rules?

*_Release.a:
    # Recipe for building a release library, i.e., with optimization.
    # Unsure how to integrate this with different architectures.

Or perhaps a combination of the two?

Upvotes: 2

Views: 5390

Answers (2)

Beta
Beta

Reputation: 99094

Architectures and configurations are kind of orthogonal; they call for different approaches. The user should be able to choose the configuration at build time, and the cleanest way to do that is with different targets. But I see no sense in trying to build for one architecture on another, so the choice of architecture should be handled automatically. The details will vary with your needs, but your makefile might end up looking something like this:

# Determine whatever we need to know about architecture with "uname" or its
# equivalent (I think it's "ver" on Windows).

MACHINE = $(shell "uname -m") 

ifeq ($(MACHINE), i386)
SOME_VAR = 386
foo:
    make a foo the i386 way  
else
SOME_VAR = something else
foo:
    make a foo some other way
endif


# Choice of configuration is up to the user

release: COMPILER_OPTIONS += -O0
debug: CCFLAGS += -g -Wall

debug release:
    whatever...

Upvotes: 6

user2100815
user2100815

Reputation:

Easiest way is different targets. In outline:

RELFLAGS := -O2 
DBGFLAGS := -g

release: 
    $(COMMAND) $(RELFLAGS) $(FILES)

debug:
    $(COMMAND) $(DBGFLAGS) $(FILES)

Same with different architectures, although I don't myself do any cross-compilation.

Upvotes: 1

Related Questions