#includes not being processed across network (revised)
Wed Jan 3 13:38:00 GMT 2001
> If you're saying that this problem occurs if you move all the source to a
> UNIX machine and that the source is local on that machine (i.e. it doesn't
> somehow involve using the VisionFS file server stuff at all - I have no
> what this does for you), then I would say this is an issue with gcc tools
> (well cpp to be exact). If you only see the problems when using the file
> server, then something about that setup/software is probably to blame. In
> the former case, you could send email to the gcc list. In the latter, you
> need to consult the providers of VisionFS.
Pardon my ignorance, but isn't this the list that deals with gcc as it
applies to Cygwin? The problem is, by definition, environment-dependant. The
gcc, cpp and other Cygwin binaries are the "run side" of that environment;
the "read side" is a common network-drive mapped onto H: (and served by
VisionFS on the Unix box). If there is better list I'd gladly follow it, but
starting at gnu.org and going to "Windows->gcc->binaries" leads me back here.
That being said, can you suggest a test that would better define exactly
where the breakdown is occuring? Remember that we are NOT getting any sort
of error message: the #included file is being found but not processed. The
Unix side of the net has been exhaustively diag'ed and reconfigured in every
way imaginable, with the same results. If you'll forgive the term, it
"smells" like there's a loss of syncronization somewhere in cpp.
BTW: My arrangement of sources and headers across several different OSs is
not that unusual. We have C source code for libraries and apps under Unix,
and are preparing Windows console executables using Cygwin's gcc. This
requires that the source code stay on the Unix box and #includes may be found
on either machine as needed to orient the different compilers to their native
OS. We will expand this to lynix, etc., as needed across the network, but
never disturbing the Unix-resident source. It's basically using a network
instead of a cross-compiler.
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin