[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev lynx2.8.1dev.26
From: |
dickey |
Subject: |
Re: lynx-dev lynx2.8.1dev.26 |
Date: |
Sun, 13 Sep 1998 12:51:58 -0400 (EDT) |
>
> to follow up on what address@hidden said:
> > * remove install-log makefile target, generate cfg_defs.h file directly
> > from
> > lynx_cfg.h and config.cache, to compile-in the configuration-definitions
> > rather than rely on external file lynx_site.txt - TD
>
> At times we have talked about capturing compile-time decisions in
> some way that they can be recovered for diagnosing problems with
> a compiled image (as when binaries are distributed). Would this
> cfg_defs.h file serve as documentation of all the configure
> switches used?
yes (more/less). It's everything that's saved: a few variables are derived
at configuration time, but neither cached nor put into #define's. (But only
a few, and we can regard that as a bug).
> What I am thinking about is something like:
>
> the job that creates a distributable binary does the following
> three things:
>
> 1) a record of all compile-time decisions suitable for diagnostic
> use is packaged up for distribution. This is distributed
> separately from the binary, not in the same .zip IMHO.
>
> 2) This package is signed (e.g. MD5 of cfg_defs.h) for error
> control.
I'm not sure - why do you want a checksum against the configuration?
> 3) An URI for retrieving this package is defined and compiled
> into the image from where it can be retrieved in a standard way.
> For example, this could combine a BASE URL from the job input
> stream and the hash key defined in 2) above.
>
> Al
>
> PS: Nothing in these questions is intended to gate a release.
> I am trying to understand where we stand on the objective
> of having a recoverable record of all the things the end user
> can't tell us about how their lynx was compiled.
--
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey