Hi,
After my 1st-year experience of programming stuff for the robot, I thought it might be a good idea start a library archive.
So is there a way I can use WindRiver to make our own “lib.a” libraries and use it?
THANKS!!!
-Masoug
Hi,
After my 1st-year experience of programming stuff for the robot, I thought it might be a good idea start a library archive.
So is there a way I can use WindRiver to make our own “lib.a” libraries and use it?
THANKS!!!
-Masoug
Absolutely. I’ve created two libraries for our team. Although I sure that you can create them from the Workbench environment, I find it is easier from the command line. I’ve included the Makefile, but if you don’t speak Makefile, then ask questions and I’ll try to answer them.
Here is the Makefile that I used to create the CANJaguarLib.a:
SRC = CANJaguar.cpp
OBJ = $(SRC:.cpp=.o)
OUT = CANJaguarLib.a
INCLUDES = -I. -I$(WIND_BASE)/target/h -IC:/Team_116_2010/Jaguar -IC:/windriver/
vxworks-6.3/target/h/WPIlib
CCFLAGS = -g
CCC = ccppc
LIBS = -LC:/Team_116_2010/lib -lm
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
Alternatively, you can write the method body right into the class definition in the .h file. I found this easier for development when I still need to change the library code quite often. Compile it to separate library module take several more steps if you need to change it.
Cool thanks!
Do you use Windows or Linux? I found out that Makefiles are different on different operating systems…
THANKS!!!
-Masoug
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
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/