This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: #import future (summary and proposed solutions)


Paul Schlie <schlie@attbi.com> wrote:
All that should be necessary to support the intent of #import, is to
reasonably inhibit the inclusion of a uniquely named file multiple times,
under reasonably typical conditions (i.e. inhibit the multiple inclusion
of files which resolve to the same absolute path and name, where it's the
responsibility of the author of the build environment to establish such
conditions, if #import is desired to behave as expected).
Nicola Pero wrote:
I guess your `reasonably typical conditions' would be something like `all
headers must be on the same linux filesystem, and you must not be using
anything "complex" [such as links], else GCC won't be guaranteed to be
able to compile your (correct) ObjC source code' ?

It doesn't sound like a serious option.
I don't understand why not. Why are we obsessing about obscure corner cases for a deprecated feature? I suspect the people who favor #import
don't understand these corner cases, and they're not going to appreciate
any work we put into solve these cases, so why bother?

If somebody has set up their system so that #import "foo.h" may
resolve to two different fully-expanded filenames that (through
symlinks or whatever) end up pointing at the same actual file
and thus gets screwed, well I'm sorry, but I don't understand
why we should care.

Give me a *real* example of something that should work but would
break under under this simple filename-only model. If somebody
has, I'm sorry but I missed it.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]