lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV Update code and patches "RFC" :)


From: Foteos Macrides
Subject: Re: LYNX-DEV Update code and patches "RFC" :)
Date: Mon, 21 Oct 1996 10:29:11 -0500 (EST)

Thanh Ma <address@hidden> wrote:
>[...]
>As far as I know, under m88k, there are sysv3, svr4, bsd, etc... and there
>are quite a few m88k-sysv3 dialects out there. UMAXV is one and is Encore
>specific.  Are you looking at along the line of the below ?
>
>sysv3-> m88k -> UMAXV
>             -> ???
>     -> intel
>     -> ???
>
>svr4 -> m88k ->
>     -> intel
>     -> ???
>
>Also what is the case with apollo in the top level Makefile ?
>
>apollo:
>        cd WWW/Library/apollo_m68k; $(MAKE) LYFLAGS="$(SITE_LYDEFS)"

        It's an issue of design principles, which have become progressively
more unclear for Unix makes, in part because the principles weren't clear in
the first place, but mostly because no one who might incorporate new targets
or modify existing targets based on contributed patches knows enough about
all the supported flavors, or new ones, to do more than just stick them in
as contributed.  There's the additional problem that such contributions
offen include new #ifdef'ing which may or may not be consistent with the
logic of current #ifdef'ing as a function of platform and flavor.

        I used to be able to look at the newer versions of vanilla libwww's
to see if a new flavor for Lynx is supported for that, and tweak the
contributed patches based on what was done there, but the W3C Reference
Library is now changed too much to still be really useful in that way, with
the design principles we have in Lynx.  That become a juggling act, anyway,
because the libwww-FM is so different now from its libwww "starting code",
after all the modifications and enhancements I've made over the years, but
I generally tried to make the libwww-FM mods in ways that would allow
upgrading to a newer libwww without too much "pain", someday.

        If the makes and new #ifdef'ing aren't done optimally, you then
have the problem that contributed patches of code for enhancements or new
features (as opposed to new targets) might not work as intended across all
of the "supported" platform/flavors, and the contributors of such patches
often know very little, if anything, about platform/flavors beyond the
ones they actually use themselves.

        So, we could use some help improving the logic of the Makefile
target names and Library/foo subirectory names, and the tcp.h #ifdef'ing,
as well as in spelling out just what are the design principles underlying
them.  There's also the issue of native curses versus ncurses versus
slang variants of targets, which may or may not be reflected in the
current target names, tcp.h #ifdef'ing, and Library/foo subdirectory
names, and seems not adequately reflected in the LYCurses.h #ifdef'ing.

        Plus there's the utmp issue which seems to depend on something
other than what is being tested for, and which header to include for
support of it, or whether to include -DNO_UTMP for the target.

        etc., etc.
                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;



reply via email to

[Prev in Thread] Current Thread [Next in Thread]