8
\$\begingroup\$

I am working with CUDA and I am currently using this makefile to automate my build process. However, there are multiple --compiler-options, basically one for each flag I want to pass to gcc.

How can I avoid repeating it over and over?

(Any suggestion about improving my makefile is also really welcome)

CC=nvcc
LIBS=-lm
CFLAGS=-Wno-deprecated-gpu-targets --compiler-options -Wextra --compiler-options -Wall --compiler-options -O3 --compiler-options -Wno-unused-result --compiler-options -Wno-unused-parameter

all:    main

main:   main.o
    $(CC) $(CFLAGS) $(LIBS) main.o -o main

main.o: main.cu
    $(CC) $(CFLAGS) $(LIBS) -c main.cu -o main.o

clean:
    rm -f *.o main
\$\endgroup\$
  • \$\begingroup\$ You may use a makefile template and a loop to inject the --compiler-options flag to a list like -Wextra -Wall -O3 ... \$\endgroup\$ – πάντα ῥεῖ Apr 19 '17 at 1:35
  • 1
    \$\begingroup\$ @πάνταῥεῖ Comments are for seeking clarification to the question. Please put all suggestions in answers. \$\endgroup\$ – 200_success Apr 19 '17 at 3:20
4
\$\begingroup\$
  • As mentioned in the comments, define two macros:

    COMPILER_OPTIONS := -Wextra -Wall -O3 -Wno-unused-result -Wno-unused-parameters
    CUDA_COMPILER_OPTIONS := $(foreach option, $(COMPILER_OPTIONS), --compiler-option $(option))
    
  • C in CFLAGS stands for compiler, and should contain only the compile phase options. Don't send CFLAGS to the linker, it is surely not interested in, say, -Wall. Conventionally the link phase options are passed in LDFLAGS.

  • I am surprised that

        $(CC) $(CFLAGS) $(LIBS) main.o -o main
    

    did pick the math library. The linker processes the command line once and sequentially. As written, there is no undefined symbols lm could resolve by the time it is processed. The bulletproof way is to specify libraries after objects:

        $(CC) $(CFLAGS) main.o -o main $(LIBS)
    
  • Nitpick. CC is conventionally assumed to produce .o from .c. Since your source is .cu I recommend to alias nvcc to something else. NVCC perhaps.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ For point 3, that rule should be omitted entirely, since it merely duplicates the built-in pattern rule to create main from main.o. \$\endgroup\$ – Toby Speight Feb 4 at 9:04
3
\$\begingroup\$

There are two different problems. One is to pass the same options to gcc and to gcc via nvcc (the accepted solution). The other is to pass several options without repeating the long command.

The second problem is easier. Instead of

-Wno-deprecated-gpu-targets --compiler-options -Wextra --compiler-options -Wall --compiler-options -O3 --compiler-options -Wno-unused-result --compiler-options -Wno-unused-parameter

you say

-Wno-deprecated-gpu-targets --compiler-options="-Wextra -Wall -O3 -Wno-unused-result -Wno-unused-parameter"

or more common, for some reason,

-Wno-deprecated-gpu-targets --compiler-options=-Wextra,-Wall,-O3,-Wno-unused-result,-Wno-unused-parameter

Also there is the option -X-Xcompiler that is a shortcut for --compiler-options.

This works at least for nvcc 10.1. I don't know about earlier versions.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Welcome to Code Review! The original question is almost three years old. Do you happen to know if the options you presented were already present back then? \$\endgroup\$ – AlexV Feb 4 at 8:45
  • \$\begingroup\$ @AlexV no, I don’t know. Perhaps someone with a historical system can test it. \$\endgroup\$ – alfC Feb 4 at 22:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.