Re: lynx-dev lynx2.8.1dev.26

[dickey]

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