Organizing School Workspace/Writing Makefile

Question

I am doing some C programming for school and I have found myself reusing libraries that I have created, over and over again (stacks, user input, error handling, etc).

Right now, my personal SVN directory structure looks like this:

trunk/
|-- 2520
|   `-- assignments
|       |-- A2
|           |-- Makefile
|           |-- README
|           |-- calculator.c
|           |-- calculatorlib.c
|           `-- calculatorlib.h
`-- libs
    |-- misc
    |   |-- errorlib.c
    |   |-- errorlib.h
    |   |-- userinputlib.c
    |   `-- userinputlib.h
    `-- stacks
        |-- stacklib.c
        `-- stacklib.h

Some of these files (userinputlib and errorlib) get used in almost every project I work on for obvious reasons. I want to be able to include these files in a project's workspace (2520/assignments/A2) without having to copy the files because I don't want to manage to copies of a file and I don't want to check in two copies of the same file in SVN.
I would like to have the library files in the project workspace so my Makefile works without having to do to much manual configuration (or hard-coding paths).

At first, I thought about symbolic links (which SVN and tar support) but I can't seem to compile my assignment given my headers in another directory.

I can manually compile each header to an object file and do the final linking, but I'm not sure how to do this in a Makefile automatically.

Any help or any alternative to how I have my environment setup is appreciated.

Thanks!

EDIT: I forgot to mention that I have searched Google and have found a few pages describing automatic dependency generation (perhaps I want this?) using gcc -MM and I have read over the GNU Make manual but nothing jumped out at me.

Answer 1

Why wouldn't you want to (svn) copy the necessary libs into your project? You'll essentially be creating a branch of your lib for use in your project. If you end up discovering a bug in your library code, you can fix it in place, and commit it back (to the copy). Once you're wrapping up, you can merge your fixes back to the library's trunk location.

Answer 2

Use could use subversion's externals feature to link a dynamic copy of the libs tree as a subdirectory of your project.

But in the end it may be better to just use a copy (a subversion copy, so it would effectively be a branch of the library code), so that you don't need to worry about changes to the library affecting existing projects, and can merge changes around as needed.