Vitaliy wrote:
> How do you guys organize code that you intend to share between projects?

My solution is fairly Subversion-specific, but I think it should 
generalize to other modern revision control systems.

I have a "reuse" project in Subversion, containing reusable modules (.c 
and .h).  New projects have a Subversion "external" link in the source 
folder, so each project's tree looks like this:

MyNewProject/
   source/
     MyNewProject.c
     reuse/
       buttons.c
       buttons.h

When I start a new project, I usually do an SVN Copy from an existing 
similar project, then modify things from there.  This is a handy way to 
set up the folders, external link, etc.  MPLAB source paths are now 
relative to the containing folder (MyNewProject/), and they'll never 
break no matter where you move it.

You can then edit stuff in reuse/ all you like, and commit it with the 
project-specific changes.

> To make things even more complicated, how do you avoid breaking old projects 
> when you, for example, add parameters to a function? Is there a way to make 
> a "snapshot" of a project, given that my_uart, my_leds, and 
> my_uart_led_blinker each live in their own repositories?

I use a Subversion tag for this, when a project is released.  It 
captures the version information for the reuse folder, so if you 
Checkout the tag, you get the old version of that as well.

Then when I resuscitate a dormant project, I Update it, which pulls the 
most recent version of the reuse/ folder.  I then do a full regression 
test to ensure any changes in shared modules didn't break anything.

Beyond that...  One helpful habit is to always add parameters at the 
end, with defaults (BoostC includes the default parameter feature from 
C++), so existing calls don't need to be changed.  (Similarly for enum 
values and struct members - always add at the end, initialize all to 
zero based on sizeof(TheStruct), etc.)  Another is to never change 
existing functions (except for bug fixes which are always harmless - a 
ha!!) but instead add additional functions with disambiguated names. 
Beyond that, perfect design, clairvoyance, and general brilliance are 
necessary.  :)  (Or instead, grumbling and swearing.)
-- 
Timothy J. Weber
http://timothyweber.org
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist