GCC Include Paths

GCC Include Paths

[Allan Crook]

Help,

We're trying to make GCC automatically search for required header
files, unforunately if we use the C_INCLUDE_PATH environment variable or
-I you need to enter every single search directory. For our current
project this results in a line over 2000chars long (too long for windows
or GCC to handle. Can we somehow tell GCC to search subfolders or is
there some other way to do this???

thanks,
Allan.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: GCC Include Paths

[Shankar Unni]

Vijay Sampath wrote:
> I just tried out a line with 20000 characters and it works fine on bash
> as an input to GCC. 

I think that direct Cygwin-to-Cygwin invocation has a higher limit. If 
you're calling a Cygwin program from a non-Cygwin program (e.g. 
CMD.EXE), you're still stuck with Windows limits.




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: GCC Include Paths

[Randall R Schulz]

Vijay,

I guess I was misled by this:

/usr/include/limits.h:#define _POSIX_ARG_MAX 4096
/usr/include/sys/syslimits.h:#define ARG_MAX 65536 /* max bytes for an exec 
function */

Furthermore, "/usr/include/limits.h" bears a Red Hat copyright and is 
specifically marked as a "part of Cygwin," while 
"/usr/include/sys/syslimits.h" bears a "Regents of the University of 
California" copyright. Thus I assumed the former was more authoritative.

Sorry (again) for the misinformation.

Randall Schulz
Mountain View, CA USA


At 10:53 2002-12-12, Vijay Sampath wrote:
>Randall,
>
>I just tried out a line with 20000 characters and it works fine on bash
>as an input to GCC. At this point I gave up trying to increase the
>length to find out the limit. Whatever the bash limit is, it is
>definitely greater than a windows shell. Of course, if you are invoking
>a bat file or some such thing from a cygwin shell then you will be
>bounded by the windows limit. Therefore Allan, I suggest trying to move
>to a "pure" cygwin enviroment, if there is such a thing.
>
>Thanks,
>
>Vijay


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: GCC Include Paths

[Vijay Sampath]

Randall, 

I just tried out a line with 20000 characters and it works fine on bash
as an input to GCC. At this point I gave up trying to increase the
length to find out the limit. Whatever the bash limit is, it is
definitely greater than a windows shell. Of course, if you are invoking
a bat file or some such thing from a cygwin shell then you will be
bounded by the windows limit. Therefore Allan, I suggest trying to move
to a "pure" cygwin enviroment, if there is such a thing.

Thanks,

Vijay

> -----Original Message-----
> From: Randall R Schulz [mailto:rrschulz@cris.com] 
> Sent: Thursday, December 12, 2002 10:43 AM
> To: cygwin@cygwin.com
> Subject: RE: GCC Include Paths
> 
> 
> Vijay, Allan,
> 
> Cygwin is similarly limited. All Unix / POSIX systems have 
> such a limit, 
> but Cygwin's limit is much smaller than the typical limit on 
> a Unix (-like) 
> system. I don't know it for a fact, but I'm pretty sure this 
> limit is not 
> imposed by Cygwin itself (why would it?) but is a Windows limitation.
> 
> Most of the time "xargs" resolves this, but obviously that's 
> not the case 
> for -I arguments to gcc or in general when the argument 
> overload originates 
> in auxiliary arguments that name file system entities and 
> which must all be 
> present concurrently.
> 
> I suggest that you create a separate directory containing 
> links (symbolic 
> links or, if feasible (*), hard links) to all the (required) 
> include files 
> in all the include directories. Then you can side-step the 
> argument list limit.
> 
> (*) Hard links are an option (the preferred option, actually) 
> if the file 
> systems are NTFS and the "target" of the link is on the same 
> file system 
> volume as the link. If the latter does not hold, Cygwin will copy the 
> files, so this approach will still work, but you won't be 
> using actual 
> links. Lastly, in keeping with the pedantic theme of which 
> I'm so fond, I 
> put "target" in quotes since hard links are all co-equal and 
> there is no 
> "original" or "target" vs. "link" distinction, just alternate 
> names for the 
> same underlying file.
> 
> Good luck.
> 
> Randall Schulz
> Mountain View, CA USA
> 
> 
> At 10:29 2002-12-12, Vijay Sampath wrote:
> >Yes, we have faced a similar problem. The problem is with 
> the windows 
> >command shell which limits a line to 2048 characters. I 
> don't know how 
> >to make that problem go away. But you shouldn't get the same problem 
> >from a cygwin shell.
> >
> >Thanks,
> >
> >Vijay
> >
> > > -----Original Message-----
> > > From: Allan Crook [mailto:Allan.Crook@zytek.co.uk]
> > > Sent: Thursday, December 12, 2002 10:10 AM
> > > To: cygwin@cygwin.com
> > > Subject: GCC Include Paths
> > >
> > >
> > > Help,
> > >
> > > We're trying to make GCC automatically search for required header 
> > > files, unforunately if we use the C_INCLUDE_PATH environment 
> > > variable or -I you need to enter every single search 
> directory. For 
> > > our current project this results in a line over 2000chars 
> long (too 
> > > long for windows or GCC to handle. Can we somehow tell 
> GCC to search 
> > > subfolders or is there some other way to do this???
> > >
> > > thanks,
> > > Allan.
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: GCC Include Paths

[Randall R Schulz]

Vijay, Allan,

Cygwin is similarly limited. All Unix / POSIX systems have such a limit, 
but Cygwin's limit is much smaller than the typical limit on a Unix (-like) 
system. I don't know it for a fact, but I'm pretty sure this limit is not 
imposed by Cygwin itself (why would it?) but is a Windows limitation.

Most of the time "xargs" resolves this, but obviously that's not the case 
for -I arguments to gcc or in general when the argument overload originates 
in auxiliary arguments that name file system entities and which must all be 
present concurrently.

I suggest that you create a separate directory containing links (symbolic 
links or, if feasible (*), hard links) to all the (required) include files 
in all the include directories. Then you can side-step the argument list limit.

(*) Hard links are an option (the preferred option, actually) if the file 
systems are NTFS and the "target" of the link is on the same file system 
volume as the link. If the latter does not hold, Cygwin will copy the 
files, so this approach will still work, but you won't be using actual 
links. Lastly, in keeping with the pedantic theme of which I'm so fond, I 
put "target" in quotes since hard links are all co-equal and there is no 
"original" or "target" vs. "link" distinction, just alternate names for the 
same underlying file.

Good luck.

Randall Schulz
Mountain View, CA USA


At 10:29 2002-12-12, Vijay Sampath wrote:
>Yes, we have faced a similar problem. The problem is with the windows
>command shell which limits a line to 2048 characters. I don't know how
>to make that problem go away. But you shouldn't get the same problem
>from a cygwin shell.
>
>Thanks,
>
>Vijay
>
> > -----Original Message-----
> > From: Allan Crook [mailto:Allan.Crook@zytek.co.uk]
> > Sent: Thursday, December 12, 2002 10:10 AM
> > To: cygwin@cygwin.com
> > Subject: GCC Include Paths
> >
> >
> > Help,
> >
> > We're trying to make GCC automatically search for required
> > header files, unforunately if we use the C_INCLUDE_PATH
> > environment variable or -I you need to enter every single
> > search directory. For our current project this results in a
> > line over 2000chars long (too long for windows or GCC to
> > handle. Can we somehow tell GCC to search subfolders or is
> > there some other way to do this???
> >
> > thanks,
> > Allan.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: GCC Include Paths

[Vijay Sampath]

Yes, we have faced a similar problem. The problem is with the windows
command shell which limits a line to 2048 characters. I don't know how
to make that problem go away. But you shouldn't get the same problem
from a cygwin shell.

Thanks,

Vijay

> -----Original Message-----
> From: Allan Crook [mailto:Allan.Crook@zytek.co.uk] 
> Sent: Thursday, December 12, 2002 10:10 AM
> To: cygwin@cygwin.com
> Subject: GCC Include Paths
> 
> 
> Help,
> 
> We're trying to make GCC automatically search for required 
> header files, unforunately if we use the C_INCLUDE_PATH 
> environment variable or -I you need to enter every single 
> search directory. For our current project this results in a 
> line over 2000chars long (too long for windows or GCC to 
> handle. Can we somehow tell GCC to search subfolders or is 
> there some other way to do this???
> 
> thanks,
> Allan.
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/