This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


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

Re: #includes not being processed across network (revised)


Larry:

> 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 
idea  
>  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.

Thanks,
John

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


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