I'm going to respond (below) to each of the points raised during today's
discussion. (Geez, I'd didn't expect that *this* would be matter for
intense discussion... :-)
First, though, here's what I'm going to do unless somebody screams
really loud, and why. The following is coherent with what Red Hat Linux
and Linux-Mandrake do with the ncurses[-devel]; why reinvent the wheel
if those guys have shipped oodles of working installations...they've
worked through these problems.
However, the ncurses source code package itself does NOT, by default,
install it's header files into <prefix>/include/ncurses/. By default,
it installs into <prefix>/include, but this can be overridden, of
course, by a simple './configure --includedir=' while building ncurses.
/usr/include/ncurses/curses.h
/usr/include/ncurses/form.h
/usr/include/ncurses/ncurses.h -> curses.h
/usr/include/ncurses/term.h
/usr/include/ncurses/unctrl.h
/usr/include/ncurses/eti.h
/usr/include/ncurses/menu.h
/usr/include/ncurses/panel.h
/usr/include/ncurses/termcap.h
/usr/include/ncurses/ncurses_dll.h
/usr/include/ncurses/cursesapp.h
/usr/include/ncurses/cursesf.h
/usr/include/ncurses/cursesm.h
/usr/include/ncurses/cursesp.h
/usr/include/ncurses/cursesw.h
/usr/include/ncurses/cursslk.h
/usr/include/ncurses/etip.h
everything goes in /usr/include/ncurses/, but to help packages build OOB
without "Oh, yeah -- I forgot to say 'CFLAGS=-I/usr/include/ncurses
./configure..." add the following symlinks (this is also consistent with
Red Hat Linux and Linux-Mandrake)
/usr/include/curses.h -> ncurses/curses.h
/usr/include/ncurses.h -> ncurses/curses.h
/usr/include/eti.h -> ncurses/eti.h
/usr/include/form.h -> ncurses/form.h
/usr/include/menu.h -> ncurses/menu.h
/usr/include/panel.h -> ncurses/panel.h
/usr/include/term.h -> ncurses/term.h
(** only if unctrl.h dropped from cygwin-1.1.x-y install **)
/usr/include/unctrl.h -> ncurses/unctrl.h
These headers are the ones used for the C libraries; there are very few
apps that I know of, that use the C++ libraries, so the C++ can stay in
the /ncurses/ "ghetto" without symlinks.
Nice plan. But it won't work. ncurses.h includes <unctrl.h>, but if
the ncurses unctrl.h is ONLY in /ncurses/ and not in /usr/include, AND
you are #including the /usr/include/curses.h file (because you didn't
specify -I/usr/include/ncurses) then /usr/include/curses.h won't find
the correct, ncurses, unctrl.h. It'll get the newlib unctrl.h instead.
So, these symlinks can only be installed if the /usr/include/unctrl.h is
the ncurses one.
BTW, I don't know of any programs that directly include unctrl.h. They
tend to include curses.h, which depends on (it's) unctrl.h. Even newlib
*ITSELF* only uses unctrl.h in two places: libc/misc/unctrl.c (of
course) and libc/misc/dprintf.c. No newlib .h file includes unctrl.h.
Further, no winsup .c, .cc, or .h references unctrl.h or unctrl(). And
finally, cygwin1.dll doesn't export the necessary data structure for the
unctrl() function^W macro in newlib to be useable by any external
program.
Therefore, I believe that cygwin should NOT install the newlib unctrl.h,
and that ncurses should create the symlink 'farm' above (including the
unctrl.h entry).
Okay, now for specific responses to some messages in this thread:
Earnie said:
> I don't know about the rest of this list but I would prefer it be
> /usr/include/ncurses/unctrl.h. It is then obvious as to what it is
> for. If you name it nunctrl.h then it won't be that obvious.
I agree that nunctrl.h is confusing. I was just following the pattern
of renaming termcap.h to termcapn.h -- but that would mean unctrln.h,
not nunctrl.h. So I'm brain dead. Anyway, the original pattern was
just stupid. (It was my idea, so I can say that.) Earnie's right -- if
you want to use the ncurses 'termcap compatibility' then you should say
that during the configure stage of your client program
(CFLAGS=-I/usr/include/ncurses ./configure), and not have to go "rename
termcap.h to termcap.h.old, and then move termcapn.h to ... Blech.)
However, if you just want to use ncurses (not termcap, or the termcap
compat layer of ncurses), it's nice to have it "just work" without
setting extra flags. That's why I like the symlinks.
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. :-)
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.
Later, Dr. Volker Zell said:
> I agree with Earnie. But then the interdependencies of the ncurses header files have
>to be
> solved.
> Actually the Xemacs configure script checks for curses.h and term.h in
>/usr/include/ncurses.
> And there is already another name collision in the ncurses package with the termcap
>package
> (termcap.h).
So, you have to install *all* of the ncurses headers into
/usr/include/ncurses, not just some of them. You can put some of the
into /usr/include, being careful to satisfy the interdependencies.
(Given my arguments above, that means cygwin-1.1.x-y drops unctrl.h, and
ncurses *does* install it along with certain other .h files into
/usr/include. The symlink list above is a self-consistent set).
Concerning the name collision w.r.t. termcap.h: No ncurses header
references termcap.h, so it can stay in /usr/include/ncurses/, safely
separated from the .h file from the termcap package. Use -I... to force
selection of ncurses-termcap.
Then, Mumit chimed in with a bunch of info:
> Newlib has a bunch of stuff thrown in that may be there just for
> historical reasons, or to support certain targets. I don't see any
> other reason for newlib to contain unctrl. I have yet to see a non-
> curses program include unctrl.h, but of course someone must've done
> it for it to be included in newlib. Is there a problem in ncurses
> one overwriting the newlib one? I can't see it offhand, but that's
> untested.
I think newlib itself sometimes needs unctrl() -- in dprintf(). But,
newlib's unctrl.h defines unctrl() as a macro, so there is no runtime
conflict. It's all handled at build time.
Seconding another post, the problem is actually cygwin updates
overwriting the ncurses version, not ncurses overwriting the cygwin
version. The latter case will break while building clients of ncurses.
> Linux does use a slightly different layout (and it varies among the
> various flavors of Linux!), and a lot of that has to do with history
> as well. Historically, all the ncurses includes only went to
> $prefix/include/ncurses/; later on these include files were also
> symlink'd in $prefix/include directory so that configuration utilities
> could find curses.h without having to look in ncurses/curses.h. At
> least true for a few of the more prevalent Linux distributions.
Verified: Red Hat Linux and Linux-Mandrake.
> If there's a difference in Linux layout and what ncurses does out of the
> box, I'd be more comfortable in using a ncurses-directed layout simply
> to avoid gratuitous incompatibility. Lots of other systems use ncurses
> as well, and configuration utilities have no problem finding the right
> headers/libs.
As I mentioned previously, ncurses *by default* installs its headers
into <prefix>/include. However, segregation into /ncurses/ is necessary
(not for the unctrl.h issue; that should be resolved, IMO, by removing
it from the cgywin-1.1.x-y tarball). Rather, the segratation is
necessary to clean up the termcap.h conflict in a more logical way, than
the current, stupid, rename scheme.
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.)
--Chuck
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
