autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: simple autoconf question


From: Nick Bowler
Subject: Re: simple autoconf question
Date: Tue, 20 Dec 2011 15:49:57 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On 2011-12-20 15:35 -0500, Eric Gorr wrote:
> On Dec 20, 2011, at 2:57 PM, Nick Bowler <address@hidden> wrote:
[...]
> > On 2011-12-20 14:28 -0500, Eric Gorr wrote:
> >>   # EG_MY_MACRO
> >>   # -----------------------------
> >>   AC_DEFUN( [EG_MY_MACRO],
> >>   m4_warn( [all], [hello world] )
> >>   ) # EG_MY_MACRO
> > 
> > Assuming that it actually worked, this m4_warn is not quoted so it will
> > be executed (and the warning printed) _before_ the AC_DEFUN is.  This is
> > probably not what you want, since this means the warning will be printed
> > unconditionally (whether or not the script actually uses EG_MY_MACRO
> > anywhere else).
> 
> Ok. I have changed my code to
> 
> AC_DEFUN( [EG_MY_MACRO],
>   [m4_warn( [obsolete], [hello world] )]
>   ) # EG_MY_MACRO

Yup, this looks fine.

> With the intent of defining and then calling the macro. You are
> correct, using a category other then 'all' allows the file to be
> processes without error and I do get a configure script. However,
> running this configure script does not result in "hello world" being
> printed.

Most warnings appear to be disabled by default (it seems that only
"syntax" warnings are enabled).  If you run autoconf on the above with
-Wall or -Wobsolete, you should see hello world printed.

> However, it is possible I am using an out-of-date version of autoconf
> and this bug has already been fixed...the version I am using is 2.61
> according to 'autoconf --version'.

I see the same behaviour on 2.68 (the latest official release).  No idea
if it's fixed in the development versions.

> 
> >> Furthermore, what prompted this question is one I posted to
> >> stackoverflow...if you know the answer to this, I would be interested.
[...]
> >> I can then execute autoconf from the command line and it does produce
> >> a configure script. However, when I run the configure script, I get
> >> the following error:
> >> 
> >>   ./configure: line 1618: syntax error near unexpected token `libusbmuxd,'
> >>   ./configure: line 1618: `PKG_CHECK_MODULES(libusbmuxd, libusbmuxd >= 
> >> 0.1.4)'
> > 
> > The problem here is that the PKG_CHECK_MODULES macro is not defined at
> > autoconf time.  Perhaps aclocal needs to be run with an appropriate -I
> > option to find the macro (maybe it's installed in a nonstandard path, or
> > not installed at all?).
[...]
> What appears to work is the
>  following...
> 
>     aclocal -I /usr/local/share/aclocal
>     autoconf
> 
> What I am not sure of is how to confirm just what directories will be
> searched for autoconf macros...? 'aclocal --print-ac-dir' still only
> outputs '/usr/bin/../share/aclocal'
> 
> What is the appropriate way to make my additional search location
> perminant? Add the call to one of the bash init files, like .bashrc?

I think doing something with your shell startup scripts is probably the
best approach in the short term.  As I understand it, some future
automake version should feature improved aclocal search path handling.

However, many tools invoke aclocal directly and won't get your changes
easily.  Tools like autoreconf will use the ACLOCAL environment
variable, if set, so you can probably do something like this (untested):

  ACLOCAL='aclocal -I/usr/local/share/aclocal'
  export ACLOCAL

  alias aclocal=$ACLOCAL

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]