You can do a lot without automake, but I don't recommend it. In some cases it makes sense if you can isolate your work in development to simple lightweight fast code that doesn't have a lot of dependencies.
Also, GNU make is hard to learn without real examples. The GNU suite of tools, GCC included is very steep learning for a beginner. A lot of time is spent on head smashing against grammar errors. Gnu tools are very unforgiving. I have learned by error and pattern more times than not.
So when I do things that are complicated, and use the special rules, I will try to pass on what I know by writing them down.
This code will appear in marrspace in the future. I have off-lined this development in order to make sure this piece works first. Once that's accomplished I will install the working code inside marrspace.
This is a modified version of yesterday's work. Instead of making two programs with all the C object files, I use the AR archive program to make a static library that is linked to the programs. Why static? Because it will be small and you want it to run fast. Why make only? Because this code is agnostic because it references library dependencies that aren't unique apart from protocol buffers that are made generic. Why C? Because the production system needs to run extremely fast. The marrspace library adds vertexes and lines to a rolling real time model of the visual scene. I detest bloated C++ code so I am taking more time to make functions that will execute minimally.
To test the output of the piped message from msg1 to msg2 by using a phony recipe that runs the two programs with a canned set of data.
I use the special $(shell) command to run in the shell's environment. To call it phony means that make won't look for output files from the shell execution. There is a test output .out made so one can review the messages passed and converted. That's all you need for a production library. GNU make is more powerful than people imagine, if only people have the time to read all the documentation.
Also, GNU make is hard to learn without real examples. The GNU suite of tools, GCC included is very steep learning for a beginner. A lot of time is spent on head smashing against grammar errors. Gnu tools are very unforgiving. I have learned by error and pattern more times than not.
So when I do things that are complicated, and use the special rules, I will try to pass on what I know by writing them down.
This code will appear in marrspace in the future. I have off-lined this development in order to make sure this piece works first. Once that's accomplished I will install the working code inside marrspace.
# Makefile for the messages that come out of the visual information message packages
# DRE 2015
# This library makes a C protocol buffers implementation for other code elsewhere.
# This nasty little subdir should be kept isolated as it deals with agnostic elements of a message protocol.
# that does not need localization because it is stripped away from operating system issues.
# It is a self contained message generation folder.
# that can make a library of messages if needed that can be referenced elsewhere.
# The makefile need only append more message types into MESSAGES and
# that will make a longer list of message elements compiled together.
# I made a test application for atof when it didn't convert large double values correctly, to check if you need strtod
#
# Self-contained testing can happen between msg1 that pipes to msg2 a generic message
# If the output looks like the input, the messages are working
MESSAGES = VMessage FMessage GMessage LMessage PMessage MMessage WMessage
# redefine all message types as the final protocol-buffer autogenerated pb-c.c files that might not be present when the folder is spawned
MESSAGES_C = $(MESSAGES:=.pb-c.c)
# redefine all message types as protocol .proto files from the same root. This will tell you if the message is missing as well.
MESSAGES_P = $(MESSAGES:=.proto)
# redefine messages as object files.
MESSAGES_O = $(MESSAGES:=.pb-c.o)
CC = gcc
AR = ar
CFLAGS = -I./
OBJ1 = msg1.o
OBJ2 = msg2.o
LIBS = -lprotobuf-c -lm libmessage.a
msg1: $(OBJ1)
$(CC) -o $@ $^ $(MESSAGES_C) $(CFLAGS) $(LIBS)
msg2: $(OBJ2)
$(CC) -o $@ $^ $(MESSAGES_C) $(CFLAGS) $(LIBS)
libmessage: VisObject.o $(MESSAGES_O)
$(AR) ru libmessage.a VisObject.o $(MESSAGES_O)
test-atof: test-atof.o
$(CC) -o $@ $^ $(CFLAGS) $(LIBS)
.PHONY: clean check
list : $(MESSAGES_P)
echo $(MESSAGES_C)
echo $(MESSAGES_P)
messages : $(MESSAGES_P)
protoc-c --c_out=./ $(MESSAGES_P)
all : messages libmessage msg1 msg2
# tester recipe that creates the test case and sends data through and outputs to file test.out so you can review what was sent.
# we use the special case $(shell command) to send BASH a command line to execute.
check: msg1 msg2
$(shell ./msg1 1 23.44 34.55666 56566 43433.3 4545454.4 444444.5 9999999999999999999993.0 45 -7.777777777777777e1 | ./msg2 2> test.out )
clean :
rm -f *.o
rm -f *.pb-c.c
rm -f *.pb-c.h
rm -fr *~
rm -f msg1 msg2 test-atof
rm -f test.out
rm -f libmessage.a
This is a modified version of yesterday's work. Instead of making two programs with all the C object files, I use the AR archive program to make a static library that is linked to the programs. Why static? Because it will be small and you want it to run fast. Why make only? Because this code is agnostic because it references library dependencies that aren't unique apart from protocol buffers that are made generic. Why C? Because the production system needs to run extremely fast. The marrspace library adds vertexes and lines to a rolling real time model of the visual scene. I detest bloated C++ code so I am taking more time to make functions that will execute minimally.
To test the output of the piped message from msg1 to msg2 by using a phony recipe that runs the two programs with a canned set of data.
I use the special $(shell) command to run in the shell's environment. To call it phony means that make won't look for output files from the shell execution. There is a test output .out made so one can review the messages passed and converted. That's all you need for a production library. GNU make is more powerful than people imagine, if only people have the time to read all the documentation.
