Re: two differents version of unctrl.h, one in cygwin-1.1.7 and one in ncurses-5.2

[Earnie Boyd <earnie_boyd at yahoo dot com>]

"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