backlog repost: I sent this before I did the branch to explain the changes

[synthesizer patel]

Hey Chris,

I've checked in a branch called 'synthesizerpatel', I reworked src/
Makefile up a bit.

Items of note:

* I've removed the precompiled headers stuff as it was causing
problems with individual file compiles -- in a nutshell, I think the
precompiled headers eliminated the need to get header includes in the
right order (and in some cases, in some files at all) so they could
build correctly on their own. The speed loss is negligible.

* I fixed up a bunch of *.cpp files so that they included the correct
support file headers that I believe the precompiled header was
providing surreptitiously.

* I removed the 'lin', 'osx' 'win32' file extension stuff since it's
somewhat redundant. The ifdefs just manage the top levels and that
trickles down into the OS specific stuff.

* I moved LGL.module/(LGL.cpp|LGL.h) into the main source directory.
The '.c.o:' magic in the Makefile will notice if any source file has
been modified and rebuild it automatically and it seemed unnecessary
to have a whole seperate directory for it.

* You will notice that we only have a couple make targets in the src
tree, for instance ctags aren't being built. That's my bad and I'll
get it fixed unless you want to add it.

* I verified that it built on OSX correctly and ran, everything looks
good.

If you feel comfortable with these changes can you do a code-review to
make sure I didn't butcher your project? :D Beyond that, I'm unsure of
how you want to proceed, if you like the changes I can merge them into
trunk, if you don't like the changes we can have a dance-off or
something? Or if you want to retain control over trunk and just have
me merge from trunk into my branch, make changes, then check in for
you to merge in later.. So many options!

-nar

[interim_descriptor]

Ah, I see this is one of the messages you sent, that didn't make it to dvj.

I believe this would've answered a number of questions I had when you submitted that code review request. Added thanks for explaining your changes before I had those questions, even though the email didn't make it to me.

Since most things in this email were addressed, shall we discuss the merge-to-trunk dance?

How about we do it like this:

• You work on your branch, merging in code from the trunk as frequently as you care to
  
• When you're ready for your changes to be merged to trunk, do one more merge from the trunk to your branch, and send me an email.
• I'll then take your branch, and merge it into the trunk.

My reasons for doing it this way:

• By virtue of being the person that merges your code into the trunk, I'll necessarily remain familiar with 100% of the code.
• By being the trunk-merger, if anything happens to break in the trunk, it's my responsibility alone. As such, this ensures that your branch will always get a complete and detailed code review, to ensure correctness.
  

We can revisit this later, but for now, does that sound OK to you? Any reasons you can think of to do otherwise?

-Chris