Makefile for CGI program using SQLite library
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
1
down vote
favorite
I am developing a CGI program in C on Linux using gcc, GNU make and the SQLite library. How does my makefile look?
# Automatic Variables
# $@ file name of target
# $< name of the first prerequisite
# $? name of all prerequisites newer than target
# $^ names of all prerequisites
# Pattern rule example - complile object files from prerequisites
# %.o: %.c
# $(CC) -c $(CFLAGS) $< -o $@
#
# Predefined Variables
# CC compiler, default gcc
# CFLAGS compiler flags
# LDFLAGS linker flags such as -L (extra directories searched for -l)
# LDLIBS libaries such as -lfoo
CC=gcc
CFLAGS=-ansi -pedantic -Wall -Wextra -O2
LDLIBS=-ldl -lpthread
# directory of SQLite library
SQLITEDIR=sqlite
sqlfun.cgi: sqlfuncgi.o sqlite3.o
$(CC) -o $@ $^ $(CFLAGS) $(LDLIBS)
sqlite3.o: $(SQLITEDIR)/sqlite3.c
$(CC) -o $@ $^ -c -Os
sqlfuncgi.o: sqlfuncgi.c
$(CC) -o $@ $^ -c $(CFLAGS)
.PHONY: clean test
clean:
rm -f sqlfun.cgi *.o
test:
clear
cppcheck --enable=all --inconclusive --std=c89 sqlfuncgi.c
valgrind --leak-check=yes ./sqlfun.cgi test
c sqlite makefile
add a comment |Â
up vote
1
down vote
favorite
I am developing a CGI program in C on Linux using gcc, GNU make and the SQLite library. How does my makefile look?
# Automatic Variables
# $@ file name of target
# $< name of the first prerequisite
# $? name of all prerequisites newer than target
# $^ names of all prerequisites
# Pattern rule example - complile object files from prerequisites
# %.o: %.c
# $(CC) -c $(CFLAGS) $< -o $@
#
# Predefined Variables
# CC compiler, default gcc
# CFLAGS compiler flags
# LDFLAGS linker flags such as -L (extra directories searched for -l)
# LDLIBS libaries such as -lfoo
CC=gcc
CFLAGS=-ansi -pedantic -Wall -Wextra -O2
LDLIBS=-ldl -lpthread
# directory of SQLite library
SQLITEDIR=sqlite
sqlfun.cgi: sqlfuncgi.o sqlite3.o
$(CC) -o $@ $^ $(CFLAGS) $(LDLIBS)
sqlite3.o: $(SQLITEDIR)/sqlite3.c
$(CC) -o $@ $^ -c -Os
sqlfuncgi.o: sqlfuncgi.c
$(CC) -o $@ $^ -c $(CFLAGS)
.PHONY: clean test
clean:
rm -f sqlfun.cgi *.o
test:
clear
cppcheck --enable=all --inconclusive --std=c89 sqlfuncgi.c
valgrind --leak-check=yes ./sqlfun.cgi test
c sqlite makefile
Please see What to do when someone answers. I have rolled back Rev 3 â 2.
â 200_success
Jan 25 at 21:50
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am developing a CGI program in C on Linux using gcc, GNU make and the SQLite library. How does my makefile look?
# Automatic Variables
# $@ file name of target
# $< name of the first prerequisite
# $? name of all prerequisites newer than target
# $^ names of all prerequisites
# Pattern rule example - complile object files from prerequisites
# %.o: %.c
# $(CC) -c $(CFLAGS) $< -o $@
#
# Predefined Variables
# CC compiler, default gcc
# CFLAGS compiler flags
# LDFLAGS linker flags such as -L (extra directories searched for -l)
# LDLIBS libaries such as -lfoo
CC=gcc
CFLAGS=-ansi -pedantic -Wall -Wextra -O2
LDLIBS=-ldl -lpthread
# directory of SQLite library
SQLITEDIR=sqlite
sqlfun.cgi: sqlfuncgi.o sqlite3.o
$(CC) -o $@ $^ $(CFLAGS) $(LDLIBS)
sqlite3.o: $(SQLITEDIR)/sqlite3.c
$(CC) -o $@ $^ -c -Os
sqlfuncgi.o: sqlfuncgi.c
$(CC) -o $@ $^ -c $(CFLAGS)
.PHONY: clean test
clean:
rm -f sqlfun.cgi *.o
test:
clear
cppcheck --enable=all --inconclusive --std=c89 sqlfuncgi.c
valgrind --leak-check=yes ./sqlfun.cgi test
c sqlite makefile
I am developing a CGI program in C on Linux using gcc, GNU make and the SQLite library. How does my makefile look?
# Automatic Variables
# $@ file name of target
# $< name of the first prerequisite
# $? name of all prerequisites newer than target
# $^ names of all prerequisites
# Pattern rule example - complile object files from prerequisites
# %.o: %.c
# $(CC) -c $(CFLAGS) $< -o $@
#
# Predefined Variables
# CC compiler, default gcc
# CFLAGS compiler flags
# LDFLAGS linker flags such as -L (extra directories searched for -l)
# LDLIBS libaries such as -lfoo
CC=gcc
CFLAGS=-ansi -pedantic -Wall -Wextra -O2
LDLIBS=-ldl -lpthread
# directory of SQLite library
SQLITEDIR=sqlite
sqlfun.cgi: sqlfuncgi.o sqlite3.o
$(CC) -o $@ $^ $(CFLAGS) $(LDLIBS)
sqlite3.o: $(SQLITEDIR)/sqlite3.c
$(CC) -o $@ $^ -c -Os
sqlfuncgi.o: sqlfuncgi.c
$(CC) -o $@ $^ -c $(CFLAGS)
.PHONY: clean test
clean:
rm -f sqlfun.cgi *.o
test:
clear
cppcheck --enable=all --inconclusive --std=c89 sqlfuncgi.c
valgrind --leak-check=yes ./sqlfun.cgi test
c sqlite makefile
edited Jan 25 at 21:50
200_success
123k14143401
123k14143401
asked Jan 25 at 5:16
user2309803
314
314
Please see What to do when someone answers. I have rolled back Rev 3 â 2.
â 200_success
Jan 25 at 21:50
add a comment |Â
Please see What to do when someone answers. I have rolled back Rev 3 â 2.
â 200_success
Jan 25 at 21:50
Please see What to do when someone answers. I have rolled back Rev 3 â 2.
â 200_success
Jan 25 at 21:50
Please see What to do when someone answers. I have rolled back Rev 3 â 2.
â 200_success
Jan 25 at 21:50
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
First impressions
This is clear and easy to read, and follows conventions well.
Use more built-ins
You can use more of Make's built-in rules. For example, this rule can be omitted entirely:
sqlfuncgi.o: sqlfuncgi.c
$(CC) -o $@ $^ -c $(CFLAGS)
If you add $(SQLITEDIR)
to the VPATH, the sqlite3.o
rule becomes simply
sqlite3.o: CFLAGS += -Os
And the link rule can use the built-in LINK.c
variable:
sqlfun.cgi: sqlfuncgi.o sqlite3.o
$(LINK.c) -o $@ $^ $(LDLIBS)
Special targets
Good use of .PHONY
. We probably also want .DELETE_ON_ERROR
to ensure that if any command fails, its partially-written outputs don't hang around and appear to be made
Portability improvement
We can use Make's predefined $(RM)
in place of rm -f
.
Thanks Toby. As you said, I could have omitted the sqlitefuncgi.o rule since it would be implicitly built - but I find it clearer to have it explicitly documented. I didn't know about VPATH, so I have added it. I also added a system include path since I don't want to see compiler warnings from sqlite/sqlite3.h. I also added your suggestions $(RM) and .DELETE_ON_ERROR. I can't find any documentation about LINK.c - what does it do? Is $(CFLAGS) superfluous in the sqlfun.cgi recipe? I assume this rule only does linking not compiling
â user2309803
Jan 25 at 20:52
$(LINK.c)
is one of Make's built-in variables (that can be examined usingmake --print-data-base
- which on my system shows it defined as$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
), and it's used in the default rule for building from C sources. You'd use$(LINK.cc)
instead for C++ code, to link the C++ standard library as well.
â Toby Speight
Jan 26 at 8:35
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
First impressions
This is clear and easy to read, and follows conventions well.
Use more built-ins
You can use more of Make's built-in rules. For example, this rule can be omitted entirely:
sqlfuncgi.o: sqlfuncgi.c
$(CC) -o $@ $^ -c $(CFLAGS)
If you add $(SQLITEDIR)
to the VPATH, the sqlite3.o
rule becomes simply
sqlite3.o: CFLAGS += -Os
And the link rule can use the built-in LINK.c
variable:
sqlfun.cgi: sqlfuncgi.o sqlite3.o
$(LINK.c) -o $@ $^ $(LDLIBS)
Special targets
Good use of .PHONY
. We probably also want .DELETE_ON_ERROR
to ensure that if any command fails, its partially-written outputs don't hang around and appear to be made
Portability improvement
We can use Make's predefined $(RM)
in place of rm -f
.
Thanks Toby. As you said, I could have omitted the sqlitefuncgi.o rule since it would be implicitly built - but I find it clearer to have it explicitly documented. I didn't know about VPATH, so I have added it. I also added a system include path since I don't want to see compiler warnings from sqlite/sqlite3.h. I also added your suggestions $(RM) and .DELETE_ON_ERROR. I can't find any documentation about LINK.c - what does it do? Is $(CFLAGS) superfluous in the sqlfun.cgi recipe? I assume this rule only does linking not compiling
â user2309803
Jan 25 at 20:52
$(LINK.c)
is one of Make's built-in variables (that can be examined usingmake --print-data-base
- which on my system shows it defined as$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
), and it's used in the default rule for building from C sources. You'd use$(LINK.cc)
instead for C++ code, to link the C++ standard library as well.
â Toby Speight
Jan 26 at 8:35
add a comment |Â
up vote
1
down vote
First impressions
This is clear and easy to read, and follows conventions well.
Use more built-ins
You can use more of Make's built-in rules. For example, this rule can be omitted entirely:
sqlfuncgi.o: sqlfuncgi.c
$(CC) -o $@ $^ -c $(CFLAGS)
If you add $(SQLITEDIR)
to the VPATH, the sqlite3.o
rule becomes simply
sqlite3.o: CFLAGS += -Os
And the link rule can use the built-in LINK.c
variable:
sqlfun.cgi: sqlfuncgi.o sqlite3.o
$(LINK.c) -o $@ $^ $(LDLIBS)
Special targets
Good use of .PHONY
. We probably also want .DELETE_ON_ERROR
to ensure that if any command fails, its partially-written outputs don't hang around and appear to be made
Portability improvement
We can use Make's predefined $(RM)
in place of rm -f
.
Thanks Toby. As you said, I could have omitted the sqlitefuncgi.o rule since it would be implicitly built - but I find it clearer to have it explicitly documented. I didn't know about VPATH, so I have added it. I also added a system include path since I don't want to see compiler warnings from sqlite/sqlite3.h. I also added your suggestions $(RM) and .DELETE_ON_ERROR. I can't find any documentation about LINK.c - what does it do? Is $(CFLAGS) superfluous in the sqlfun.cgi recipe? I assume this rule only does linking not compiling
â user2309803
Jan 25 at 20:52
$(LINK.c)
is one of Make's built-in variables (that can be examined usingmake --print-data-base
- which on my system shows it defined as$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
), and it's used in the default rule for building from C sources. You'd use$(LINK.cc)
instead for C++ code, to link the C++ standard library as well.
â Toby Speight
Jan 26 at 8:35
add a comment |Â
up vote
1
down vote
up vote
1
down vote
First impressions
This is clear and easy to read, and follows conventions well.
Use more built-ins
You can use more of Make's built-in rules. For example, this rule can be omitted entirely:
sqlfuncgi.o: sqlfuncgi.c
$(CC) -o $@ $^ -c $(CFLAGS)
If you add $(SQLITEDIR)
to the VPATH, the sqlite3.o
rule becomes simply
sqlite3.o: CFLAGS += -Os
And the link rule can use the built-in LINK.c
variable:
sqlfun.cgi: sqlfuncgi.o sqlite3.o
$(LINK.c) -o $@ $^ $(LDLIBS)
Special targets
Good use of .PHONY
. We probably also want .DELETE_ON_ERROR
to ensure that if any command fails, its partially-written outputs don't hang around and appear to be made
Portability improvement
We can use Make's predefined $(RM)
in place of rm -f
.
First impressions
This is clear and easy to read, and follows conventions well.
Use more built-ins
You can use more of Make's built-in rules. For example, this rule can be omitted entirely:
sqlfuncgi.o: sqlfuncgi.c
$(CC) -o $@ $^ -c $(CFLAGS)
If you add $(SQLITEDIR)
to the VPATH, the sqlite3.o
rule becomes simply
sqlite3.o: CFLAGS += -Os
And the link rule can use the built-in LINK.c
variable:
sqlfun.cgi: sqlfuncgi.o sqlite3.o
$(LINK.c) -o $@ $^ $(LDLIBS)
Special targets
Good use of .PHONY
. We probably also want .DELETE_ON_ERROR
to ensure that if any command fails, its partially-written outputs don't hang around and appear to be made
Portability improvement
We can use Make's predefined $(RM)
in place of rm -f
.
edited Jan 26 at 8:36
answered Jan 25 at 9:30
Toby Speight
17.8k13491
17.8k13491
Thanks Toby. As you said, I could have omitted the sqlitefuncgi.o rule since it would be implicitly built - but I find it clearer to have it explicitly documented. I didn't know about VPATH, so I have added it. I also added a system include path since I don't want to see compiler warnings from sqlite/sqlite3.h. I also added your suggestions $(RM) and .DELETE_ON_ERROR. I can't find any documentation about LINK.c - what does it do? Is $(CFLAGS) superfluous in the sqlfun.cgi recipe? I assume this rule only does linking not compiling
â user2309803
Jan 25 at 20:52
$(LINK.c)
is one of Make's built-in variables (that can be examined usingmake --print-data-base
- which on my system shows it defined as$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
), and it's used in the default rule for building from C sources. You'd use$(LINK.cc)
instead for C++ code, to link the C++ standard library as well.
â Toby Speight
Jan 26 at 8:35
add a comment |Â
Thanks Toby. As you said, I could have omitted the sqlitefuncgi.o rule since it would be implicitly built - but I find it clearer to have it explicitly documented. I didn't know about VPATH, so I have added it. I also added a system include path since I don't want to see compiler warnings from sqlite/sqlite3.h. I also added your suggestions $(RM) and .DELETE_ON_ERROR. I can't find any documentation about LINK.c - what does it do? Is $(CFLAGS) superfluous in the sqlfun.cgi recipe? I assume this rule only does linking not compiling
â user2309803
Jan 25 at 20:52
$(LINK.c)
is one of Make's built-in variables (that can be examined usingmake --print-data-base
- which on my system shows it defined as$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
), and it's used in the default rule for building from C sources. You'd use$(LINK.cc)
instead for C++ code, to link the C++ standard library as well.
â Toby Speight
Jan 26 at 8:35
Thanks Toby. As you said, I could have omitted the sqlitefuncgi.o rule since it would be implicitly built - but I find it clearer to have it explicitly documented. I didn't know about VPATH, so I have added it. I also added a system include path since I don't want to see compiler warnings from sqlite/sqlite3.h. I also added your suggestions $(RM) and .DELETE_ON_ERROR. I can't find any documentation about LINK.c - what does it do? Is $(CFLAGS) superfluous in the sqlfun.cgi recipe? I assume this rule only does linking not compiling
â user2309803
Jan 25 at 20:52
Thanks Toby. As you said, I could have omitted the sqlitefuncgi.o rule since it would be implicitly built - but I find it clearer to have it explicitly documented. I didn't know about VPATH, so I have added it. I also added a system include path since I don't want to see compiler warnings from sqlite/sqlite3.h. I also added your suggestions $(RM) and .DELETE_ON_ERROR. I can't find any documentation about LINK.c - what does it do? Is $(CFLAGS) superfluous in the sqlfun.cgi recipe? I assume this rule only does linking not compiling
â user2309803
Jan 25 at 20:52
$(LINK.c)
is one of Make's built-in variables (that can be examined using make --print-data-base
- which on my system shows it defined as $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
), and it's used in the default rule for building from C sources. You'd use $(LINK.cc)
instead for C++ code, to link the C++ standard library as well.â Toby Speight
Jan 26 at 8:35
$(LINK.c)
is one of Make's built-in variables (that can be examined using make --print-data-base
- which on my system shows it defined as $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
), and it's used in the default rule for building from C sources. You'd use $(LINK.cc)
instead for C++ code, to link the C++ standard library as well.â Toby Speight
Jan 26 at 8:35
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f185933%2fmakefile-for-cgi-program-using-sqlite-library%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Please see What to do when someone answers. I have rolled back Rev 3 â 2.
â 200_success
Jan 25 at 21:50