Re: [Bug-apl] fixes and wishlist

[Dr . Jürgen Sauermann]

Hi,

see below.

Jürgen

On 8/10/19 5:10 PM, address@hidden wrote:

WISHLIST and FIXES

the HOWTOs/Adding-System-Functions.html doesn't seem to be copied to /usr/local/share/doc/apl/ with make install along with the rest of the HOWTOs

This is on purpose. The audience of /usr/local/share/doc/apl is regular users (non-developers) while
the audience for Adding-System-Functions.html GNU APL developers (primarily myself because I
keep forgetting all the places that need to be touched when adding a new system function.

put time stamp into apl.history

The file itself has a time stamp (from the underlying operating system, as shown by ls -l).

A time stamp (per input line?) inside the file would corrupt the file and undermine its
cut-and-paste purpose, e.g. when reporting a problem.

put the date that the https://www.gnu.org/software/apl/apl.html is created near the top - to help people know that there have been changes and a new apl.html
(like on libapl)

done.

add a simple reference in the apl.html to the other dirs of interest that exist in the src
specifically the   html   dir that has gnuapl code layout (doxygen)
and websock and web-home dirs

I suppose apl.html refers to the html version of apl.info. I will look into this, please remind
me if I should forget.

for --with-libapl   the  make install    to only install the  new libs and libapl,h  (and not all the other workspaces etc)  it currently overwrites what is already there
without --with-libapl (making apl) want full install with make install

Different builds override the workspaces but with the same files (unless different SVN versions
are built). The programs that do the actual installation (like /usr/bin/install) are lacking the
sophistication that would be needed to make the installation more "intelligent" (which also has
its own disadvantages).

Therefore the simple rule that GNU APL follows is to override everything with the files in the
chosen SVN version.

Any more complicated handling of install would, IMHO, create more problems than benefits
that it may have in certain situations.

Please also note that the library numbers are clearly split into libraries "owned" by the user (which
will not be touched by install) and those "owned" by GNU APL that will be overridden by install.
If you want to prevent a workspace owned by GNU APL from being overridden, then you can simply
copy it from the system library to a user library. See chapter 1.5 in apl.html or in "info apl".

---