DIY Static Library

[masoug]

Cool thanks!

Originally Posted by taichichuan

# source files.
SRC = CANJaguar.cpp

OBJ = $(SRC:.cpp=.o)

OUT = CANJaguarLib.a

# include directories
INCLUDES = -I. -I$(WIND_BASE)/target/h -IC:/Team_116_2010/Jaguar -IC:/windriver/
vxworks-6.3/target/h/WPIlib

# C++ compiler flags (-g -O2 -Wall)
CCFLAGS = -g

# compiler
CCC = ccppc

# library paths
LIBS = -LC:/Team_116_2010/lib -lm

# compile flags
LDFLAGS = -g
.SUFFIXES: .cpp

default: dep $(OUT)

.cpp.o:
$(CCC) $(INCLUDES) $(CCFLAGS) -c $< -o $@

$(OUT): $(OBJ)
arppc rcs $(OUT) $(OBJ)

depend: dep

dep:

clean:
rm -f $(OBJ) $(OUT) Makefile.bak

Do you use Windows or Linux? I found out that Makefiles are different on different operating systems...

THANKS!!!

-Masoug

[taichichuan]

Actually, I use both. But, the Makefile approach used by WRS *is* the same as you find in Linux right down to the whitespace (e.g., tabs *not* spaces). Both use the GNU make facility and the binutils from GNU.

It's just that WRS puts a wrapper around the tools that check the license before allowing you to compile/link code. So, the easiest approach is to use the "host shell" option in the WRS Workbench tool to get to a command line and then invoke the make from there. That shell sets up the environment variables and paths needed for the WRS build system to work.

HTH,

Mike

[virtuald]

An interesting thing with our build environment is that since we're compiling as kernel modules, your robot program is actually its own dynamic library (as opposed to a static *.a library).

My development pattern is that I tend to make a lot of little projects to test various things, and setting up linkage to a set of libraries each time would get annoying. So instead of setting up a static library, I compile it as a regular project, and then FTP the object file (*.out) to the robot and edit ni-rt.ini to load the library before it loads FRC_UserProgram.out. Then my installation program for the library copies the header files to the wind river include directory, and I just include the header files and it all magically works.

The other reasoning for this is that my library uses boost, and setting up that is a pain, so I'd rather just have a quick installer that installs the relevant header files and object files on our other development computers instead of trying to do it on each machine.

Of course, if your library changes a lot, then this is a bad approach. Its more suited to something that you are going to redistribute to other teams. See my project website for more information: http://code.google.com/p/webdma/