Re: error: NEED_LIBOPTS does not appear in AM_CONDITIONAL
On Wed, Jul 11, 2018 at 11:11 AM Bruce Korb wrote:
>
> Hi,
>
> "NEED_LIBOPTS" *does* appear in an AM_CONDITIONAL:
>
> > AM_CONDITIONAL([NEED_LIBOPTS], [test -n "${NEED_LIBOPTS_DIR}"])
After reconf-ing with -, I have found:
autoreconf - reveals:
aclocal: found macro LIBOPTS_CHECK_COMMON in sntp/libopts/m4/libopts.m4: 481
aclocal: saw macro LIBOPTS_CHECK_COMMON
and yet:
Makefile.am:49: error: NEED_LIBOPTS does not appear in AM_CONDITIONAL
Since LIBOPTS_CHECK_COMMON contains an AM_CONDITIONAL for NEED_LIBOPTS
and since aclocal sees the use of LIBOPTS_CHECK_COMMON and its definition,
the error message leaves me baffled.
error: NEED_LIBOPTS does not appear in AM_CONDITIONAL
Hi,
"NEED_LIBOPTS" *does* appear in an AM_CONDITIONAL:
> AM_CONDITIONAL([NEED_LIBOPTS], [test -n "${NEED_LIBOPTS_DIR}"])
so I cannot figure out the source of the complaint.
> autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
autoreconf: configure.ac: tracing
autoreconf: configure.ac: adding subdirectory sntp to autoreconf
autoreconf: Entering directory `sntp'
autoreconf: running: libtoolize --copy
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, '../m4'.
libtoolize: copying file '../m4/libtool.m4'
libtoolize: copying file '../m4/ltoptions.m4'
libtoolize: copying file '../m4/ltsugar.m4'
libtoolize: copying file '../m4/ltversion.m4'
libtoolize: copying file '../m4/lt~obsolete.m4'
libtoolize: Consider adding '-I ../m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:69: installing './ar-lib'
configure.ac:62: installing './compile'
configure.ac:53: installing './config.guess'
configure.ac:53: installing './config.sub'
configure.ac:47: installing './install-sh'
configure.ac:47: installing './missing'
Makefile.am:49: error: NEED_LIBOPTS does not appear in AM_CONDITIONAL
AM_CONDITIONAL fails with line break at the end of $2
Hello list,
the following snippet generates invalid shell code (and a cryptic error
message) because of the line break right before the closing parenthesis.
AM_CONDITIONAL([HAVE_LIBXML2],
[test x$with_libxml2 != xno
test x$ac_cv_lib_xml2_xmlFirstElementChild = xyes]
)
Generated code (semi-colon at beginning of line creates problems):
if test x$with_libxml2 != xno
test x$ac_cv_lib_xml2_xmlFirstElementChild = xyes
; then
HAVE_LIBXML2_TRUE=
HAVE_LIBXML2_FALSE='#'
else
HAVE_LIBXML2_TRUE='#'
HAVE_LIBXML2_FALSE=
fi
The attached patch attempts to fix the issue, do you think it is the right
approach?
Thanks in advance,
Dimitris--- cond.m4 2014-07-17 17:46:37.741723897 +0200
+++ cond.2.m4 2014-07-17 17:50:43.456076469 +0200
@@ -13,17 +13,18 @@
[AC_PREREQ([2.52])dnl
m4_if([$1], [TRUE], [AC_FATAL([$0: invalid condition: $1])],
[$1], [FALSE], [AC_FATAL([$0: invalid condition: $1])])dnl
AC_SUBST([$1_TRUE])dnl
AC_SUBST([$1_FALSE])dnl
_AM_SUBST_NOTMAKE([$1_TRUE])dnl
_AM_SUBST_NOTMAKE([$1_FALSE])dnl
m4_define([_AM_COND_VALUE_$1], [$2])dnl
-if $2; then
+if $2
+then
$1_TRUE=
$1_FALSE='#'
else
$1_TRUE='#'
$1_FALSE=
fi
AC_CONFIG_COMMANDS_PRE(
[if test -z ${$1_TRUE} test -z ${$1_FALSE}; then
Re: AM_CONDITIONAL fails with line break at the end of $2
[adding automake]
On 07/17/2014 10:00 AM, Dimitrios Apostolou wrote:
Hello list,
the following snippet generates invalid shell code (and a cryptic error
message) because of the line break right before the closing parenthesis.
AM_CONDITIONAL([HAVE_LIBXML2],
[test x$with_libxml2 != xno
test x$ac_cv_lib_xml2_xmlFirstElementChild = xyes]
)
AM_CONDITIONAL is not an autoconf macro, and your patch is to an
automake file, so you mailed the wrong list. But that's okay, I've
redirected it.
Generated code (semi-colon at beginning of line creates problems):
if test x$with_libxml2 != xno
test x$ac_cv_lib_xml2_xmlFirstElementChild = xyes
; then
HAVE_LIBXML2_TRUE=
HAVE_LIBXML2_FALSE='#'
else
HAVE_LIBXML2_TRUE='#'
HAVE_LIBXML2_FALSE=
fi
The attached patch attempts to fix the issue, do you think it is the
right approach?
I don't know if automake should work around your bad syntax, or if you
should just fix your configure.ac to use correct syntax to begin with. I
also wonder if automake could use AS_IF instead of open-coding the if to
try and take advantage of autoconf's smarts for trying to sanitize
conditions.
However, even autoconf's AS_IF current implementation prefers the 'if
cond; then' rather than 'if cond $newline then', so it is likewise not
robust to conditions ending in a spurious newline. If changing AS_IF to
use newline separator does not increase configure size, I could see
making that change in autoconf. I'll play with the idea.
--- cond.m4 2014-07-17 17:46:37.741723897 +0200
+++ cond.2.m4 2014-07-17 17:50:43.456076469 +0200
@@ -13,17 +13,18 @@
[AC_PREREQ([2.52])dnl
m4_if([$1], [TRUE], [AC_FATAL([$0: invalid condition: $1])],
[$1], [FALSE], [AC_FATAL([$0: invalid condition: $1])])dnl
AC_SUBST([$1_TRUE])dnl
AC_SUBST([$1_FALSE])dnl
_AM_SUBST_NOTMAKE([$1_TRUE])dnl
_AM_SUBST_NOTMAKE([$1_FALSE])dnl
m4_define([_AM_COND_VALUE_$1], [$2])dnl
-if $2; then
+if $2
+then
$1_TRUE=
$1_FALSE='#'
else
$1_TRUE='#'
$1_FALSE=
fi
AC_CONFIG_COMMANDS_PRE(
[if test -z ${$1_TRUE} test -z ${$1_FALSE}; then
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: AM_CONDITIONAL fails with line break at the end of $2
Hi Erik, thank you for forwarding to the appropriate list! On Thu, 17 Jul 2014, Eric Blake wrote: I don't know if automake should work around your bad syntax, or if you should just fix your configure.ac to use correct syntax to begin with. I Is my syntax illegal? Can't I put line-breaks there? If I knew I wouldn't bother with this patch, it's just that I consumed some time to figure out this failure, so I thought it would be helpful to others. also wonder if automake could use AS_IF instead of open-coding the if to try and take advantage of autoconf's smarts for trying to sanitize conditions. However, even autoconf's AS_IF current implementation prefers the 'if cond; then' rather than 'if cond $newline then', so it is likewise not robust to conditions ending in a spurious newline. If changing AS_IF to use newline separator does not increase configure size, I could see making that change in autoconf. I'll play with the idea. Thanks, please keep me posted! Dimitris
Re: AM_CONDITIONAL fails with line break at the end of $2
On 07/17/2014 12:44 PM, Dimitrios Apostolou wrote: Hi Erik, thank you for forwarding to the appropriate list! On Thu, 17 Jul 2014, Eric Blake wrote: I don't know if automake should work around your bad syntax, or if you should just fix your configure.ac to use correct syntax to begin with. I Is my syntax illegal? Can't I put line-breaks there? If I knew I wouldn't bother with this patch, it's just that I consumed some time to figure out this failure, so I thought it would be helpful to others. Not illegal (there's no law prohibiting it), but not typical; and the fact that it is causing a syntax error is a sign that fixing your code is more likely to bring it in line with other packages, than waiting for the tools to be taught to work with your usage as a new pattern, and then waiting for that fix to percolate to the distros you care about. More typical usage looks like one of these: AM_CONDITIONAL([HAVE_LIBXML2], [test x$with_libxml2 != xno test x$ac_cv_lib_xml2_xmlFirstElementChild = xyes]) or AM_CONDITIONAL([HAVE_LIBXML2], [ test x$with_libxml2 != xno test x$ac_cv_lib_xml2_xmlFirstElementChild = xyes]dnl ) (that is, you'll usually see the close ) flush against the close ], or you will see a use of 'dnl' to eat any newlines that were used to visually spot that the closing ) on the start of the next line matches an earlier line above) also wonder if automake could use AS_IF instead of open-coding the if to try and take advantage of autoconf's smarts for trying to sanitize conditions. However, even autoconf's AS_IF current implementation prefers the 'if cond; then' rather than 'if cond $newline then', so it is likewise not robust to conditions ending in a spurious newline. If changing AS_IF to use newline separator does not increase configure size, I could see making that change in autoconf. I'll play with the idea. Thanks, please keep me posted! Sure. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
AM_CONDITIONAL seems failure, help
hi all: I write these lines in configure.in: AC_CHECK_LIB([pcre], [pcre_compile], [build_pcre=true], [build_pcre=false]) AM_CONDITIONAL([BUILD_PCRE],[test $build_pcre = true]) AC_MSG_CHECKING(pcrecpp) AC_COMPILE_IFELSE([ #include pcrecpp.h ], [build_pcrecpp=true; AC_MSG_RESULT(yes)], [build_pcrecpp=false; AC_MSG_RESULT(no)] ) AM_CONDITIONAL([BUILD_PCRECPP],[test $build_pcrecpp=true]) AC_CHECK_LIB([iconv], [libiconv_open], [build_libiconv=yes], [build_libiconv=no]) AM_CONDITIONAL([BUILD_LIBICONV],[test $build_libiconv=yes]) ... AC_CONFIG_FILES([Makefile \ other/Makefile \ performance/Makefile \ posix/Makefile \ stdc/Makefile]) AC_OUTPUT ./configure outputs: ... checking for pcre_compile in -lpcre... no checking pcrecpp... no checking for libiconv_open in -liconv... no ... the content of other/Makefile: bin_PROGRAMS = if BUILD_PCRE bin_PROGRAMS += pcre_test pcre_test_LDADD = -lpcre endif if BUILD_PCRECPP bin_PROGRAMS += pcrecpp_test pcrecpp_test_SOURCES = pcrecpp_test.cpp pcrecpp_test_LDADD = -lpcrecpp endif if BUILD_LIBICONV bin_PROGRAMS += libiconv_test libiconv_test_LDADD = -liconv endif When I make, pcre_test is not to be compiled, but pcrecpp_test and libiconv_test are to be compiled, which generates compiling errors. make -n outputs: ... make[1]: Entering directory `/data1/ad_plus/kimizhang/kimi-tests/other' if g++ -DHAVE_CONFIG_H -I. -I. -I../include-g -Wall -Werror -MT pcrecpp_test.o -MD -MP -MF .deps/pcrecpp_test.Tpo -c -o pcrecpp_test.o pcrecpp_test.cpp; \ then mv -f .deps/pcrecpp_test.Tpo .deps/pcrecpp_test.Po; else rm -f .deps/pcrecpp_test.Tpo; exit 1; fi rm -f pcrecpp_test g++ -g -Wall -Werror-o pcrecpp_test pcrecpp_test.o -lpcrecpp if gcc -DHAVE_CONFIG_H -I. -I. -I../include-g -Wall -Werror -MT libiconv_test.o -MD -MP -MF .deps/libiconv_test.Tpo -c -o libiconv_test.o libiconv_test.c; \ then mv -f .deps/libiconv_test.Tpo .deps/libiconv_test.Po; else rm -f .deps/libiconv_test.Tpo; exit 1; fi rm -f libiconv_test gcc -g -Wall -Werror-o libiconv_test libiconv_test.o -liconv make[1]: Leaving directory `/data1/ad_plus/kimizhang/kimi-tests/other' ... my environment: linux-suse-64 autoconf 2.63 automake 1.11 Help, thanks all!!! ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AM_CONDITIONAL seems failure, help
В Fri, 09 Oct 2009 16:34:38 +0800, 张亚霏 написа: AM_CONDITIONAL([BUILD_PCRECPP],[test $build_pcrecpp=true]) Put spaces around `=' (also for the BUILD_LIBICONV conditional). The test for pcrecpp has to be performed with a C++ compiler, otherwise the conditional will always be false. (You can enclose it in AC_LANG_PUSH/AC_LANG_POP, for example.) ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AM_CONDITIONAL seems failure, help
On Fri, Oct 9, 2009 at 09:34, 张亚霏 zhangyafeik...@gmail.com wrote: hi all: I write these lines in configure.in: AC_CHECK_LIB([pcre], [pcre_compile], [build_pcre=true], [build_pcre=false]) AM_CONDITIONAL([BUILD_PCRE],[test $build_pcre = true]) AC_MSG_CHECKING(pcrecpp) AC_COMPILE_IFELSE([ #include pcrecpp.h ], [build_pcrecpp=true; AC_MSG_RESULT(yes)], [build_pcrecpp=false; AC_MSG_RESULT(no)] ) AM_CONDITIONAL([BUILD_PCRECPP],[test $build_pcrecpp=true]) AC_CHECK_LIB([iconv], [libiconv_open], [build_libiconv=yes], [build_libiconv=no]) AM_CONDITIONAL([BUILD_LIBICONV],[test $build_libiconv=yes]) ... AC_CONFIG_FILES([Makefile \ other/Makefile \ performance/Makefile \ posix/Makefile \ stdc/Makefile]) AC_OUTPUT ./configure outputs: ... checking for pcre_compile in -lpcre... no try checking the result with: grep build_pcre ./config.status it's a bit more deterministic than checking your Makefiles, which may involve other typos and errors. -- all...@chickenandporn.com 金鱼 http://linkedin.com/in/goldfish please, no proprietary attachments (http://tinyurl.com/cbgq) ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
AM_CONDITIONAL
Hi, In configure.in, i have: AM_CONDITIONAL(ENABLE_GTK_DOC, test x$enable_gtk_doc = xyes) and it gets turned into: if test x$enable_gtk_doc = xyes; then ENABLE_GTK_DOC_TRUE= ENABLE_GTK_DOC_FALSE='#' else ENABLE_GTK_DOC_TRUE='#' ENABLE_GTK_DOC_FALSE= fi Isn't this backward? When enable_gtk_doc = yes, then this will be *false* in the makefile: if ENABLE_GTK_DOC_TRUE ... ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AM_CONDITIONAL
Hi Russell, * Russell Shaw wrote on Sun, Aug 14, 2005 at 07:21:43PM CEST: In configure.in, i have: AM_CONDITIONAL(ENABLE_GTK_DOC, test x$enable_gtk_doc = xyes) and it gets turned into: if test x$enable_gtk_doc = xyes; then ENABLE_GTK_DOC_TRUE= ENABLE_GTK_DOC_FALSE='#' *snip* Isn't this backward? When enable_gtk_doc = yes, then this will be *false* in the makefile: Nope. It may seem so, but it's not, because this: if ENABLE_GTK_DOC_TRUE | bla | else | blubb | endif will turn into | @[EMAIL PROTECTED] | @[EMAIL PROTECTED] in Makefile.in. However, strictly speaking this is an implementation detail you should not have to worry about at all (and should not rely on either). Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Please, help with AM_CONDITIONAL
* Jose Roman Bilbao wrote on Tue, Oct 19, 2004 at 03:43:22PM CEST: I am having a problem when trying to build a program conditionally. It is a problem with the macro that detects a specific library (TIFF). This macro makes a definition of HAVE_LIBTIFF: AC_DEFINE(HAVE_LIBTIFF) AM_CONDITIONAL(AM_TIFF, test $have_tiff = yes) Those lines are within an m4 macro and my question is... Will AM_TIFF be usable from my Makefile.am?: Yes. Have you tried it and found it nonfunctional? BTW, this is an Automake question and is better discussed on its mailing list. Regards, Ralf ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Please, help with AM_CONDITIONAL
Hi all, I am having a problem when trying to build a program conditionally. It is a problem with the macro that detects a specific library (TIFF). This macro makes a definition of HAVE_LIBTIFF: AC_DEFINE(HAVE_LIBTIFF) AM_CONDITIONAL(AM_TIFF, test $have_tiff = yes) Those lines are within an m4 macro and my question is... Will AM_TIFF be usable from my Makefile.am?: OPTIONAL_PROGS = if BUILD_MPI OPTIONAL_PROGS += MPIArt MPI_WBP endif if BUILD_OGL OPTIONAL_PROGS += Phan3D endif if AM_TIFF OPTIONAL_PROGS += Tiff2Raw endif Or, on the other hand, should I make another AM_OPTIONAL in my configure.ac source? In this case, what should I write? I am using this and does not work at all (Changing BUILD_TIFF for AM_TIFF in Makefile.am): #Checking for TIFF library as well as some of its capabilities AC_CHECK_LIBTIFF AM_CONDITIONAL(BUILD_TIFF, HAVE_LIBTIFF ) Thanks in advance ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
/usr/share/automake-1.8/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL
Hi, I'm getting the following error on Fedora Core 2 (it used to work but no longer). /usr/share/automake-1.8/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL I see many posting on the google with the same error message.Can you describe the actual reason why?The most of the goole reply was to update the version.I'd like to know the reason. Here are the versions on this Fedora Core2 PC: autoconf (GNU Autoconf) 2.59 automake (GNU automake) 1.8.3 ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Thank you. Tosa -- Yasunari Tosa, Ph.D. Email: [EMAIL PROTECTED] NMR Ctr, Mass. General HospitalTEL: 617-726-4050 Building 149, 13th Street Charlestown, MA 02129 USA ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: /usr/share/automake-1.8/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL
You have posted to the autoconf list. Why are you posting an automake error message to the autoconf list rather than the automake list? Bob On Fri, 1 Oct 2004, Yasunari Tosa wrote: Hi, I'm getting the following error on Fedora Core 2 (it used to work but no longer). /usr/share/automake-1.8/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL I see many posting on the google with the same error message.Can you describe the actual reason why?The most of the goole reply was to update the version.I'd like to know the reason. Here are the versions on this Fedora Core2 PC: autoconf (GNU Autoconf) 2.59 automake (GNU automake) 1.8.3 ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Thank you. Tosa -- Yasunari Tosa, Ph.D. Email: [EMAIL PROTECTED] NMR Ctr, Mass. General HospitalTEL: 617-726-4050 Building 149, 13th Street Charlestown, MA 02129 USA ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
