[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Header file search paths
From: |
John Darrington |
Subject: |
Re: Header file search paths |
Date: |
Fri, 3 Feb 2006 09:04:49 +0800 |
User-agent: |
Mutt/1.5.9i |
On Thu, Feb 02, 2006 at 04:59:41PM -0800, Ben Pfaff wrote:
John Darrington <address@hidden> writes:
> I'm not so sure that I entirely agree. Explicitly #including the path
> could get cumbersome if several levels of directories are used. For
> example, in the structure you suggested, we'd be seeing lines like:
>
> #include "commands/dictionary/value-labels.h":
I'm not sure that's a big deal. You have to dedicate a full line
to each #include in any case.
But potentially that line could be unreasonably long. (and I believe
some older compilers complain if it's too long)
> On the other hand, this does have the advantage that it makes the
> programmer think more carefully about what he's depending upon. Right
> now, I have mixed opinions about which is the better way.
Well, no need to decide right now.
Actually, I'd suggest that for doing initial work on
reorganization, adding an -I for every directory is the easiest
way. That gives you the freedom to move files around without
having to adjust any #include's at all. Then later you can fix
up the include path and adjust #include's to match.
I agree.
I'm preparing a revised proposal with rationale and will pass it
along soon.
I'm also doing some experiments. So we'll see how our ideas differ.
J'
--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.
signature.asc
Description: Digital signature