helpAutoconf - Support: sr #108879, Add m4_forbid_pattern for...

 
 

sr #108879: Add m4_forbid_pattern for autoconf-archive macros

Submitter:  Philip Withnall <drbob>
Submitted:  Wed 09 Sep 2015 03:20:51 PM UTC
 
Category:  None Priority:  1 - Later
Severity:  1 - Wish Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

Fri 10 Jul 2020 04:03:06 PM UTC, comment #3: 

I think this is a legitimate feature request, but we need to talk to the maintainers of the autoconf archive, and probably also gnulib, and work out a coordinated plan across all these projects for how best to handle it.  We're not going to be able to do that before the 2.70 release so I am marking this bug "later".

Zack Weinberg <zackw>
Project Administrator
Fri 11 Sep 2015 01:01:17 PM UTC, comment #2: 

> I'm reluctant to have autoconf exclude a namespace that it is not in charge of itself. After all, autoconf documents how to warn about the lack of pkg-config, but does not exclude it itself (so I'm okay with expanding the documentation in autoconf to also mention how to warn about lack of Autoconf Archives).


I see your point — this would be a layering violation. I can’t see many alternatives though.

> I'd rather see Autoconf Archives do a better job of explaining that any configure.ac that wants to take advantage of an AX_ macro should also add the appropriate m4_pattern_forbid(), or possibly even automate it whenever you use an Archive macro. Autoconf Archives could use gnulib as an example (it installs its own pattern ignore as part of running gnulib-tool).


The problem is that makes people’s configure.ac files horrendous — it turns a single macro invocation into two. Some kind of autoconf-archive-tool like gnulib-tool would make this easier to apply, but the m4_pattern_* invocations would still be cluttering up configure.ac.

I guess my argument hinges on the size of autoconf-archive — I would say it’s popular enough now to have a solid claim to the AX_ namespace, to the extent that it’s worth more than a mention in the autoconf documentation. However, I understand you might disagree.

Philip Withnall <drbob>
Wed 09 Sep 2015 03:30:11 PM UTC, comment #1: 

I'm reluctant to have autoconf exclude a namespace that it is not in charge of itself.  After all, autoconf documents how to warn about the lack of pkg-config, but does not exclude it itself (so I'm okay with expanding the documentation in autoconf to also mention how to warn about lack of Autoconf Archives).

I'd rather see Autoconf Archives do a better job of explaining that any configure.ac that wants to take advantage of an AX_ macro should also add the appropriate m4_pattern_forbid(), or possibly even automate it whenever you use an Archive macro.  Autoconf Archives could use gnulib as an example (it installs its own pattern ignore as part of running gnulib-tool).

Eric Blake <ericb>
Project Administrator
Wed 09 Sep 2015 03:20:51 PM UTC, original submission:  

autoconf-archive (http://www.gnu.org/software/autoconf-archive/) is quite big now, but the error messages generated by autoconf/m4 when trying to process a configure.ac without some of the necessary autoconf-archive macros installed are not very helpful.

Would it be possible for autoconf to specify something like
   m4_pattern_forbid([^_?AX_[A-Z_]+$])
to forbid all un-expanded autoconf-archive macros; and for autoconf-archive to add the necessary m4_pattern_allow() calls for macros it installs?

Philip Withnall <drbob>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by zackw (Posted a comment)
  • -email is unavailable- added by ericb (Posted a comment)
  • -email is unavailable- added by drbob (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-07-10 zackw Priority5 - Normal 1 - Later
        Severity3 - Normal 1 - Wish
        StatusNone Confirmed

    Back to the top


    Powered by Savane 3.9