> Your first impression was better; you missed a provided essential detail.
> The solution isn't to hardcode the path, just the relative path of the
> project tree... which has no need to change.
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.
> But I've never run into the problem you're projecting here. Why would you
> change your project tree structure? And if you do, why wouldn't a simple
> regular-expression replacement rip it out in a matter of seconds?
Let me use one of my projects as an example; pilot-link. The
existing source code tree was very "flat" and monolithic in the past, before
I took over maintaining it. I needed to clean that up a bit (and will be
doing more in future releases as well). This meant moving things into
logical places, directories, etc. and changing the relevant Makefile.am
sources to indicate the new paths. The hardest part was updating the cvs
itself, to retain referntial integrity and historical metadata when the
directories were "pruned" around inside the tree. The end result, it worked
well.
Anything can change in a project, including filenames, directories,
paths, requirements, build tools, etc. so you should never rely on
hard-coded things in the source files themselves. Yes, a simple regex would
have fixed it, but how many people would know to do that? You could regex
and change say, 57 files (in the case of Plucker's ./viewer tree) or you
could change one line in one file, to point to the new include path, or even
export it with $INCLUDES in your environment.
> (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.
> 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.
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.
d.
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
