The term "no need to change" isn't a good thing to rely on, however. Anything can happen in the source code tree, things can move around, get deleted, pushed into subdirectories, etc. and if you hard-code the relative path into the source files themselves, you complicate the process of compiling. The proper way is to use the -I../path/includes directive instead, which is much easier to maintain, and self-healing. Hard-coding paths to includes in the files themselves is a nightmare waiting to explode.
Your example is certainly compelling. I would hope that such initial organizations are rare though; I would expect the initial designer who set it up that way probably screwed up a lot of other things simultaneously.
> (Your text editor should support such a thing. If it doesn't, I'm sure > most of us could suggest better tools for you.)
Come on, we were doing so well, there's no need to stoop this low.
Aw, come on! After he made that crack about paid-by-the-hour? Sheesh. <g>
> Yes, broadly, but it can be awfully difficult to foresee what names will > wind up being used in another platform. Or across many different > libraries for different purposes. That's why you have the option of > giving a path or partial path.
Or you change the filenames when you find that they conflict.
Unfortunately, as I said, I deal with a very large number of libraries and platforms. That's not always an option. I really wish it were.
I can check the C99 spec, but I'm pretty sure hard-coding paths to the include files and directories is not POSIX-compliant anyway.
That must make very complex systems that utilize may suppliers of libraries difficult. Suppose there are two libraries/directories that have two name collisions, and you need one of them from the first and one from the second? Unfortunately I have three projects with that situation currently.
If Posix doesn't allow relative directories, that could cause compatibility issues. K&R states the search "begins from the current directory". The C++ draft standard I found has both forms entirely implementation-defined, which is remarkably unhelpful, but did state " The Standard intends that the rules which are eventually provided by the implementor correspond as closely as possible to the original K&R rules. " The lack of a more detailed implementation definition is stated as being due to the lack of a portable file structure.
_______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
