Ian Lance Taylor wrote:
Rob Hatcherson <rob.hatcherson@xxxxxxxxxxxx> writes:
The problem occurs if I provide a part of this path via a -I option,
and put the remainder inside quotes in the #include. So say I do this:
gcc -E -I C:/d1/d2/d3/d4 blah.c
...with the source file looking notionally like this:
#include "...lots more.../blah.h"
By experimentation (with this particular file I'm having problems
with, so this isn't a general observation) when the total length of
the stuff inside the quotes in the #include statement reaches 82
characters in length I get a "File name too long" error from the
preprocessor. Yet as noted earlier I can include the entire path
inline without a complaint.
What is the exact command line, and what is the exact error message?
Ian
In my sort-of trivial test case - which is just a file that #include's
the offending file - the command line is this for both the case that
works and the case that doesn't:
g++ -E \
-IC:/WorkAreas/BuildOutput/ZedaSoft/Java/CBA/Domain/Physical/Plugin/Entity/F16/1.4.0/native/include
\
blah.cpp
If the only thing in blah.cpp is this:
#include
"com/zedasoft/cba/plugin/entity/platform/air/fighter/f16/view/cockpit/hud/f16hudcore/F16Hud.h"
Then I get this result:
blah.cpp:3:104:
com/zedasoft/cba/plugin/entity/platform/air/fighter/f16/view/cockpit/hud/f16hudcore/F16Hud.h:
File name too long
# 1 "blah.cpp"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "blah.cpp"
If the only thing in blah.cpp is this:
#include
"C:/WorkAreas/BuildOutput/ZedaSoft/Java/CBA/Domain/Physical/Plugin/Entity/F16/1.4.0/native/include/com/zedasoft/cba/plugin/entity/platform/air/fighter/f16/view/cockpit/hud/f16hudcore/F16Hud.h"
...then everything works.
A guy named Dave Korn on the cygwin mailing list suggested that perhaps
the partial path name, when appended onto one of the implicit -I paths,
e.g. the ones the system provides, might be the thing that was too long
rather than the final resolved path. I thought this was a great theory,
but in the end it ended up not being the case because the path against
which the header would be resolved (i.e. the path given above) was the
longest of all the preprocessor would have potentially tried.
This smells like a bug to me, but who knows. It was working on a prior
cygwin release; I'd have to do some digging to see what version of gcc
that was.
Rob
