From: Eric S. <sun...@su...> - 2000-04-30 23:46:43
|
On Sun, 30 Apr 2000 18:59:44 -0400 (EDT), Thomas Riemer wrote: > The dungeon problem actually has to do with the way the compilation > happens. The compilation happens relative to the CS root. > There is no change directory to plugins/dungeon. There is also > no -Iplugins/dungeon hence #include "dninput.h" won't work. > It tries to look for dninput.h in the root CS location. Note that it is perfectly correct for a file to include another file within the same directory without specifying any extra -I directives or other special search path information. In other words, the C-preprocessor's search rules always first check the directory in which the file resides which is including the other file whenever the #include "..." form is used (as opposed to #include <...>). Unfortunately, in this case, the #line directives emitted by Bison into dnp_tab.cpp caused the GNU C-preprocessor to become confused when it encountered the #include "..." form, thus it was unable to locate the dninput.h file which resided in the same directory. We might want to call this a bug in the preprocessor, or at least a bizarre and unexpected behaviour. > If the include were "#include "dungeon/dninput.h" everything would > work magically. The problem is now fixed, and this is indeed the solution which I chose to use. There is a slight possibility that this might break compilation of 'dungeon' on Windows, but it can be easily fixed by adding 'plugins' to the include file search list within the 'dungeon' project. (This is the same thing which is done for other plugins such as 'cscon', so there is precedence as such.) -- ES |