[Info-vax] Making the CRTL version dependency information useful

[Stephen Hoffman]

On 2018-01-13 21:02:51 +0000, John Reagan said:

> Let me know if you'd like me to tweak that in the future.  I'd be 
> willing to provide some other representation as well.  A CSV file or 
> some easily processed?

Pragmatically?   Searching the C PDF has worked fine for local use.  
For the longer-term list?  Update or replace SDL and extend, or 
translate and replace the existing SDL definition files and SDL 
language syntax to allow a single canonical definition of the APIs 
including whether or not the API is documented, the version(s) and 
patch levels involved, and generate a database for inclusion onto the 
system distribution.   The traditional information around to the first 
available OpenVMS version for a particular language function is 
probably headed somewhere different here though, given the approach 
that languages such as Fortran are now following; of shipping the RTLs 
with the upward and downward checks eliminated and new functions.   
(That won't cover everything, as there'll still be dependencies on 
underlying OpenVMS APIs.)   This database-based SDL-like approach all 
avoids having several different data sources that have to be modified 
in parallel when some function call is added; some mix of doc files, 
SDL, C headers, etc.  It can also work across different languages and 
RTLs.   With the API database, tools such as LSEDIT and other IDEs, and 
the documentation, and the compilers, can all access live data, which 
can avoid the "fun" of dealing with install-time translations using SDL 
/NOPARSE and ilk and needing to reinstall language kits to get current 
definition files and download IDE updates for API changes.  The PDF 
generator can embed the latest bits or can potentially link to the live 
definitions hosted locally or at the VSI galactic HQ web server.   
LSEDIT and NetBeans didn't and variously don't update the API 
definitions, and I'd wager that the third-party IDE folks would like to 
avoid reverse-engineering OpenVMS updates to create and distribute 
their own updates to reflect the OpenVMS changes.   AFAICT, this whole 
application-development area — from SDL definitions to TLB files and 
OLB files and IDE integration and documentation integration and the 
rest — really hasn't been looked at from end-to-end in far too many 
years.  The whole of the current implementation — I'd hesitate to use 
the word "design" here — has accreted its share of warts.   Plan on 
decreasing numbers of new folks being interested in the 
OpenVMS-traditional compile-link-debug command line approach and 
the-big-PDF-API-doc-file approach, too.


-- 
Pure Personal Opinion | HoffmanLabs LLC