On Tue, Feb 25, 2003, Fringe Ryder wrote: > In such an environment, it would be understood that plucker/viewer > shouldn't be in the include path. That's a project file; inclusions of it > would look something like: > #include "../viewer/font.h"
At first, I thought I should be nice and not say what I think about the "professional development environment" you seem to work in...
However, hardcoding the path in the source code must be one of the most braindead things I have heard of.
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.
A month from now, you suddenly decide you want to reorganize the file structure; while we "lousy" open-source developers only have to change a '-I' compiler directive, you "professionals" will go through all your source code making these changes (maybe you are paid by the hour:)
You said "lousy", I was noting the different standards of the environments, not the quality of developers. 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? (Your text editor should support such a thing. If it doesn't, I'm sure most of us could suggest better tools for you.)
Still, I think we should avoid using filenames that are similar to system header files.
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.
_______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
