Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com X-Apparently-From: Message-ID: <3A65A76E.7DE1007E@yahoo.com> Date: Wed, 17 Jan 2001 09:08:46 -0500 From: Earnie Boyd Reply-To: Earnie Boyd X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Charles S. Wilson" CC: cygwin AT cygwin DOT com Subject: Re: two differents version of unctrl.h, one in cygwin-1.1.7 and one in ncurses-5.2 References: <3A652D69 DOT 4F824705 AT ece DOT gatech DOT edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "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