All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: "xuyang2018.jy@fujitsu.com" <xuyang2018.jy@fujitsu.com>
Cc: "ltp@lists.linux.it" <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH 1/1] m4: Fix warnings
Date: Thu, 9 Dec 2021 12:19:35 +0100	[thread overview]
Message-ID: <YbHmRwf6ibQC5f0Q@pevik> (raw)
In-Reply-To: <61B1CFC8.6060305@fujitsu.com>

Hi Xu, all,


[Cc also Sagi, who is auctually using ltp-pan [1],
Sagi: could you please test this patch [2] or in patchwork [3]

> Hi Petr


> > from autoconf 2.71:

> > * s/AC_HELP_STRING/AS_HELP_STRING/

> > Similar replace was done in autoconf commit 5958ce17 ("*
> > doc/autoconf.texi: Replace AC_HELP_STRING AS_HELP_STRING.")
> > from 2.58.

> > * s/AC_TRY_LINK/AC_COMPILE_IFELSE([AC_LANG_PROGRAM/
>    * s/AC_TRY_LINK/AC_LINK_IFELSE([AC_LANG_PROGRAM/
>    * s/AC_TRY_COMPILE/AC_COMPILE_IFELSE([AC_LANG_PROGRAM/

thanks!

...
> > +++ b/configure.ac
> > @@ -24,7 +24,7 @@ AC_PROG_CC
> >   # 2.62.
> >   AC_DEFUN([AC_PROG_AR], [AC_CHECK_TOOL(AR, ar, :)])
> >   AC_PROG_AR
> > -AC_PROG_LEX
> > +AC_PROG_LEX(yywrap)
>  From this autoconf commit message, If $1 is `yywrap',
> and we don't find a library that provides yywrap, we fail.

FYI we have yywrap(void) in pan/scan.l
To be honest, I'm a bit lost in docs [4]:

	yywrap
	Indicate that the library in LEXLIB needs to define the function yywrap. If
	a library that defines this function cannot be found, LEX will be reset to
	‘:’.

	noyywrap
	Indicate that the library in LEXLIB does not need to define the function
	yywrap. configure will not search for it at all.

	Prior to Autoconf 2.70, AC_PROG_LEX did not take any arguments, and its
	behavior was different from either of the above possibilities: it would
	search for a library that defines yywrap, and would set LEXLIB to that
	library if it finds one. However, if a library that defines this function
	could not be found, LEXLIB would be left empty and LEX would not be reset.
	This behavior was due to a bug, but several packages came to depend on it,
	so AC_PROG_LEX still does this if neither the yywrap nor the noyywrap option
	is given.

	Usage of AC_PROG_LEX without choosing one of the yywrap or noyywrap options
	is deprecated. It is usually better to use noyywrap and define the yywrap
	function yourself, as this almost always renders the LEXLIB unnecessary.

=> using yywrap leads for *new* autoconf 2.71 to
1) LEX := :, instead of LEX := flex in include/mk/config.mk
2) missing #define YYTEXT_POINTER 1 in include/config.h

i.e. AC_PROG_LEX(noyywrap) leads to the same behavior as with AC_PROG_LEX
without argument on 2.71 (or any setup on *old* 2.69 autoconf).

But I'm not really expert on flex (and instead of spending time with ltp-pan I'd
prefer work on upstreaming runltp-ng [5]).

Kind regards,
Petr

[1] https://lore.kernel.org/ltp/20211127121609.26837-1-saginakash@gmail.com/
[2] https://lore.kernel.org/ltp/20211208082625.26324-1-pvorel@suse.cz/
[3] https://patchwork.ozlabs.org/project/ltp/patch/20211208082625.26324-1-pvorel@suse.cz/
[4] https://www.gnu.org/software/autoconf/manual/autoconf-2.70/html_node/Particular-Programs.html
[5] https://github.com/metan-ucw/runltp-ng

> I see other projects that they use AC_PROG_LEX(yywrap) or 
> AC_PROG_LEX(noyywrap), but don't get why.

> [1]https://github.com/search?q=%E2%80%9DAC_PROG_LEX%28yywrap%29%E2%80%9C&type=commits
NOTE: I tried to search on Debian distro based search https://codesearch.debian.net/ :
https://codesearch.debian.net/search?q=AC_PROG_LEX%28yywrap%29&literal=1&perpkg=1
https://codesearch.debian.net/search?q=AC_PROG_LEX%28noyywrap%29&literal=1
But I got actually less results than on github.

> Best Regards
> Yang Xu

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2021-12-09 11:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-08  8:26 [LTP] [PATCH 1/1] m4: Fix warnings Petr Vorel
2021-12-09  9:42 ` xuyang2018.jy
2021-12-09 11:19   ` Petr Vorel [this message]
2022-01-24 15:11   ` Cyril Hrubis
2022-01-25  1:27     ` xuyang2018.jy
2022-01-24 15:16 ` Cyril Hrubis
2022-01-24 17:18   ` Petr Vorel
2022-01-25 17:09   ` Petr Vorel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YbHmRwf6ibQC5f0Q@pevik \
    --to=pvorel@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=xuyang2018.jy@fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.