• Show log

    Commit

  • Hash : 3099097d
    Author : Mike Frysinger
    Date : 2022-02-17T03:50:55

    rm: handle -f w/no arguments gracefully
    
    Fixes automake bug https://bugs.gnu.org/10828.
    
    Delete the configure check that would abort if `rm -f` does not work,
    and delete the plans to make this a hard requirement in the future.
    
    Instead, test to see if `rm -f` fails w/out arguments.  If it does,
    define am__rm_f such that it always passes at least the "" argument
    when deleting files.  If it doesn't fail, then we can omit the "".
    
    Then go through lib/am/ and update places where we use the pattern
    `test -z ... || rm -f ...` and replace with $(am__rm_f).
    
    * NEWS: Mention support for `rm -f` w/out arguments.
    * PLANS/rm-f-without-args.txt: Remove.
    * lib/am/check.am: Use new $(am__rm_f) helper.
    * lib/am/clean.am: Likewise.
    * lib/am/header-vars.am: Likewise.
    * lib/am/inst-vars.am: Likewise.
    * lib/am/libs.am: Likewise.
    * lib/am/ltlib.am: Likewise.
    * lib/am/progs.am: Likewise.
    * lib/am/texinfos.am: Likewise.
    * m4/init.m4: Delete `rm -f` checks and call _AM_PROG_RM_F.
    * m4/rmf.m4: Define new _AM_PROG_RM_F macro.
    * t/rm-f-probe.sh: Update test.
    

  • README

  • "Plans" for future or on-going Automake development.
    
    The contents is meant to help ensure a more controlled and smooth
    development and evolution for Automake, in several ways.
    
     - Having the plans clearly spelled out should will avoid messy
       roadmaps with no clear way forward or with muddy or ill-defined
       aims or purposes; a trap this is too easy to fall into.
    
     - Keeping planned changes cooking and re-hashed for a while should
       ensure rough edges are smoothed up, transitions are planned in a
       proper way (hopefully avoiding debacles like the AM_MKDIR_PROG_P
       deprecation and the AM_CONFIG_HEADER too-abrupt removal), and
       "power users" have more chances of getting informed in due time,
       thus having all the time to prepare for the changes or raise
       objections against them.
    
     - Having the plans clearly stated and registered in a "centralized"
       location should make it more difficult to them to slip through
       the cracks, getting forgotten or (worse) only half-implemented.
    
     - Even for discussions and plans registered on the Bug Tracker
       as well, a corresponding entry in the PLANS directory can help
       in keeping main ideas summarized, and consensus and/or objections
       registered and easily compared.