[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev bloating binaries (was clue)
From: |
Klaus Weide |
Subject: |
Re: lynx-dev bloating binaries (was clue) |
Date: |
Thu, 25 Feb 1999 22:43:30 -0600 (CST) |
On Fri, 26 Feb 1999, Henry Nelson wrote:
> > Do you have a list of "features" you want to see as compile time options
>
> Because of the total commercialization of the WWW, I can see no use
> for the send a C)omment function. If it were my ball game, I wouldn't
> even waste a compile time option on it; I would unravel it and trash
> it forever. In this day and age, any webmaster who really wants to
> get comments will have a link on his page. The C)omment function is
> a nuisance to people teaching novices how to use Lynx. Anyone with
> enough expertise to make a valid comment on a page would know how
> to effectively use the P)rint function. Getting rid of the C)omment
> function would free a key for much more important functions.
Not much code savings to be had from this though - the bulk of mailto
handling is in the same function, whether it is invoked by 'C' or
following a mailto: link.
> To mention this is unfair since Jim is already working on it, but as
> an example of the humongous amount of debugging code, there needs to
> be a way to turn off CTRACE and TRACE. The saving in binary size is
> significant. In _release_ (production-level) code sets, the toggle to
> turn trace on/off should not be compiled in as the default.
I disagree with that. Many questions to this list would have to be replied
to with "First get a version that has the TRACE feature, then...", instead
of just "Turn TRACE on".
That isn't to say that it shouldn't be *possible* to disable TRACE code
at compilation.
> There are dozens of examples like the "discovery" by Klaus of the WWW
> rules code. Be honest people, how many of you are going to use that
> code? My guess is 10 or 20 max, worldwide. NO_RULE doesn't work as far
^S
> as I can see (see appended patch).
Yes, I overlooked the HTTranslate call there, sorry.
As far as I can see, the function HTAA_checkAuthorization() and maybe
the whole of HTAAServ.c isn't being used - I haven't tested it.
But maybe you could extend the range if the #ifndef to cover basically
the whole file.
That may not result in any improvement in binary size - a decent linker
should not include code from HTAAServ.o in the final executable at all
if no function from it is referenced.
> Anyway, I could see lumping these
> tiny snippets of _expendable_ code into one group of NO_FRILLS, switched
> from off as the default (meaning active code) during development to on
> by default in the (pre-)release code set.
[...]
> > >> The real problem is that the code only grows. In the last two
> > That is an obvious consequence of adding new features with
> > keeping a compatibility.
>
> This is so true, and the very reason I have to retract much of what
> I said. My only concern is that (no offense at all meant to Brian or
> anyone else), for example with the cookies code, is 100% of this not in
> the binary when configured for no-cookies? (Again, only asking; I don't
> know.)
I Can't answer that currently.
> Unless you are using shared libraries
Why would one not?? (I assume you mean libc etc., not libwww)
> I don't know how you do it. On
> Solaris2.6, linking to slang (so the only direction to configure is
> --with-screen=slang) the plain vanilla default binary after running
> strip is:
> -rwxr-xr-x 1 nelsonhe 1207848 Feb 26 09:30 lynx-default
>
> removing only the rules code:
> -rwxr-xr-x 1 nelsonhe 1203624 Feb 26 09:30 lynx-norules
>
> removing only the CTRACE debugging code:
> -rwxr-xr-x 1 nelsonhe 1161864 Feb 26 09:30 lynx-nodebug
Jim seems to have reported much bigger savings from removing CTRACE.
[ patch snipped ]
Klaus
- Re: lynx-dev bloating binaries (was clue), Henry Nelson, 1999/02/25
- Re: lynx-dev bloating binaries, Philip Webb, 1999/02/25
- Re: lynx-dev bloating binaries (was clue),
Klaus Weide <=
- Re: lynx-dev bloating binaries (was clue), Webmaster Jim, 1999/02/26
- Re: lynx-dev bloating binaries (was clue), Webmaster Jim, 1999/02/27
- Re: lynx-dev bloating binaries (was clue), mattack, 1999/02/27
- Re: lynx-dev bloating binaries (was clue), Webmaster Jim, 1999/02/27
- lynx-dev --disable-gopher flag (was: bloating binaries), Klaus Weide, 1999/02/28
- Re: lynx-dev --disable-gopher flag (was: bloating binaries), mattack, 1999/02/28
- Re: lynx-dev --disable-gopher flag (was: bloating binaries), Webmaster Jim, 1999/02/28
- Re: lynx-dev --disable-gopher flag (was: bloating binaries), Webmaster Jim, 1999/02/28