One of the skills I stumbled with being a self-taught Unix programmer, was to uncover all the tricks that Unix style development has.
If you make a makefile, and want to autocreate variables from a pattern, then you can use make's variable substitution to keep a growing list without needing automake.
There are of course many places where the need for many libraries and so on won't make that a portable thing, you will have too many dependencies that creep in and spoil the simplicity.
I was hit with the need to make a simple self-contained message protocol to pass data, and I started with Google's protocol buffers in C.
Since those are simple self-contained protocols that pass data and depend on one library, I thought I could just get away with a Makefile for this subdir:
Here is the reference for substitution:
https://www.gnu.org/software/make/manual/html_node/Substitution-Refs.html#Substitution-Ref
here is the simple Makefile
To explain, I define a message xMessage, and then the variable is subtstituted into $MESSAGES_C which places a .pb-c.c suffix onto the name of every message.
The command
defines a variable that takes every MESSAGES and adds a .pb-c.c variant that will be the autogenerated .c file from 'make messages'. These are generated from the protoc-c command.
The command
One could change it to the other way around but what if I wanted a "ERROR" message as well, they don't have to follow a pattern. The names don't have to be the same to work. The library doesn't care but a human reader might.
Then it defines a dependency xMessage.proto which is the message prototype under the protocol buffers system to package a message.
Those are used as dependencies to make a simple message testing program set of msg1 and msg2.
If you make a makefile, and want to autocreate variables from a pattern, then you can use make's variable substitution to keep a growing list without needing automake.
There are of course many places where the need for many libraries and so on won't make that a portable thing, you will have too many dependencies that creep in and spoil the simplicity.
I was hit with the need to make a simple self-contained message protocol to pass data, and I started with Google's protocol buffers in C.
Since those are simple self-contained protocols that pass data and depend on one library, I thought I could just get away with a Makefile for this subdir:
Here is the reference for substitution:
https://www.gnu.org/software/make/manual/html_node/Substitution-Refs.html#Substitution-Ref
here is the simple Makefile
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)
CC = gcc
CFLAGS = -I./
OBJ1 = msg1.o
OBJ2 = msg2.o
LIBS = -lprotobuf-c
msg1: $(OBJ1)
$(CC) -o $@ $^ $(MESSAGES_C) $(CFLAGS) $(LIBS)
msg2: $(OBJ2)
$(CC) -o $@ $^ $(MESSAGES_C) $(CFLAGS) $(LIBS)
list : $(MESSAGES_P)
echo $(MESSAGES_C);
echo $(MESSAGES_P);
messages : $(MESSAGES)
protoc-c --c_out=./ *.proto
all : messages msg1 msg2
.PHONY: clean
clean :
rm -f *.o
rm -f *.pb-c.c
rm -f *.pb-c.h
rm -fr *~
To explain, I define a message xMessage, and then the variable is subtstituted into $MESSAGES_C which places a .pb-c.c suffix onto the name of every message.
The command
MESSAGES_C = $(MESSAGES:=.pb-c.c)
defines a variable that takes every MESSAGES and adds a .pb-c.c variant that will be the autogenerated .c file from 'make messages'. These are generated from the protoc-c command.
The command
MESSAGES_P = $(MESSAGES:=.proto)makes a similar .proto file variable if the prototype does not exist. Why is this useful? Because what if you hadn't made all the messages first, or they were improperly defined, then your message library would be incomplete and might compile and execute leading to undefined behaviour.
One could change it to the other way around but what if I wanted a "ERROR" message as well, they don't have to follow a pattern. The names don't have to be the same to work. The library doesn't care but a human reader might.
Then it defines a dependency xMessage.proto which is the message prototype under the protocol buffers system to package a message.
Those are used as dependencies to make a simple message testing program set of msg1 and msg2.
No comments:
Post a Comment