Pierre Habouzit wrote:
On Sat, Nov 08, 2008 at 02:35:55PM +0000, Andreas Ericsson wrote:
Steve Frécinaux wrote:
Just a random question: is there a reason why you have put all the
.h in a separate includes/ directory instead of relying on the
install target to put the include files at the right place ?
To me it makes it much harder to hack on the files as one is always
required to switch between both directories...
I agree with this, but as I guess Shawn will do roughly 45 times more
work on it than me (according to current commit-count in git.git), I'll
live with it.
I don't, modifying the public includes may break the ABI and the API.
I believe it to be a good practice to put them in a separate directory
so that people modifying them will know this particular header is
public. Yes you can name your private headers differently, but it's not
really the same, it doesn't make editing public headers hard, and it has
to. People modifying them _have_ to thing "err why am I modifying this
specific header in the first place" before doing anything in it.
Well, I suggested putting "src/public/public_header.h" quite early on,
with private headers next to the source. AFAIU, the private and public
headers both are now located in the same directory, and that directory is
separate from the .c files.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
