"Charles S. Wilson" wrote:
>
> Earnie later said:
> > To
> > configure a program you would
> > CC='gcc -I/usr/include/ncurses' ../configure ...
> > and the configure script would find the available headers.
> >
> > The rule of thumb to use is, if a package footprint steps on the
> > OS/runtime footprint the package footprint needs to be segregated in a
> > recognizable manner. My suggestion to use /usr/include/ncurses fits
> > that rule.
>
> 1. I think you should use CFLAGS in this instance, not CC. :-)
We've hashed this out already and although it might not be architecture
dependent it is environment dependent and has the same affect. If you
don't set CC='gcc -I/usr/include/ncurses' then you're likely to
misconfigure. Otherwise, when configure tries to figure out what you
have, it might not find the ncurses headers.
> 2. the rule of thumb is ok -- except when the OS/runtime file is
> nonfunctional, and *should* be replaced by ncurses' working version. We
> just have to insure that the working version is not re-overwritten by
> another broken one from the next cygwin tarball.
>
I agree.
>
> To accomodate client apps that expect the default installation behavior,
> without imposing the requirement that the builder set
> "-I/usr/include/ncurses" while ./configure-ing, I propose the symlink
> farm -- for certain .h files -- in /usr/include. (I suspect this is the
> same line of reasoning that led Red Hat, and later Mandrake, to their
> similar decisions.)
>
This sounds feasible, I support your decision.
Cheers,
Earnie.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
