LYNX-DEV organisation of the sources

[Klaus Weide]

On Mon, 21 Oct 1996, Foteos Macrides wrote:

> Thanh Ma <address@hidden> wrote:
> >[...]
> [ about some specific systems, omitted ]

Now Fote:
>       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.

It seems that the organisation of the Lynx code, or at least the libwww
part of it, has tried to stay true to some principles that originally
existed, but were later given up by their original propagators.  (i.e.
the makers of the Reference Library.)  [Kind of a recurring theme we have
here...]  However, those principles of organisation were never applied 
to the "application" part of the source (i.e. mostly what's in the src/
directory).  What I mean is, system dependent flags, compiler names,
binary locations are all spelled out in one big Makefile, there aren't
lots of different subdirectories for different systems.  The whole idea
of how the WWW/... part of the source is organised looks kind of foreign
to the rest of the code.  Most of the stuff in .../Implementation/Makefile
seems relevant to how the original Library would be organized on a
distribution site with lots of different binaries (cern.ch or w3.org),
but has no relevance for compiling in application program, like Lynx,
which used the library.

Well, the creators and maintainers of the W3C Library have moved on,
from their somewhat elaborate scheme to GNU configure.  No need for
lots of different subdirectories any more with just one minimal
Makefile in them to distinguish them.  Should work on most (all?) 
Unix-like systems.  I don't know where, exactly, that leaves VMS,
but weren't there always some special procedures needed, and it never
fit in well with the Makefiles-centric structure for the rest?
The new libwww distribution now has just two system-specific directories
left (in the .../Library/... tree), one for vms and one for windows.
So these are still/newly supported, although not via GNU configure.

Well I don't know whether this still has much to do with what Fote
is saying (he is talking about design principles, I am talking about
how to organize files, there seems to be some difference here... )
Anyway, there doesn't seem to be much point in maintaining and clarifying
or even formalizing rules for new system names in the .../Library/...
part of the source tree.

But the best person to talk on this list about the original design
principles is Fote - and he says they were unclear from the beginning...
("for Unix makes", he says, so there's hope for VMS users :-) ) 

>       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.  

I am not sure at whom this is directed.  Who is supposed to give that
help, and what kind of help is needed?

Would moving to GNU configure (maybe obly for the libwww part) help?

My own attempt at moving the handling of the system dependencies
towards GNU configurability is still available at 
<URL: http://www/~kweide/lynxhacks/2.6plus/>.  It was meant as a 
drop-in replacement for the current (as of official-2.6) tcp.h+HTUtils.h,
that should work *now* for all currently supported system, but would
make going to GNU configure determined #include files very easy. 
(No, there is not ./configure script there yet, I don't speak autoconf
or whatever is needed to create them.)  I went to some effort to capture
all the current system dependent #includes and #defines exactly in the
new structure, for all those systems to which I have no access, including
VMS.  If no-one comments (that probably means, try whether it works on
your system) I won't know whether that was successful and makes sense or
was a waste of time.


>        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.

GNU configure should be able to handle most of that automatically.

  Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;