Re: ac_ (Was: Remove -fPIC -DPIC under DJGPP)

[Gary V. Vaughan]

On Fri, Dec 15, 2000 at 11:44:31AM +0100, Akim Demaille wrote:
> >>>>> "Alexandre" == Alexandre Oliva <address@hidden> writes:
> 
> Akim> Aaaaaah!  Libtool uses the ac_ name space???  That's quite risky...
> Alexandre> Indeed.  Feel free to clean it up (I really mean it :-)
> 
> Here is my proposal for the regular branch, I'm now looking into mlt.

Thanks.  Applied.  Well, actually I redid the substitutions in your
Changelog entry for fear of what you say below...

> There are things I don't understand too well: why is there frequently
> the comment ``should be a separate macro'', and indeed why aren't
> they?  It looks like a simple operation, so I must miss something.

It is relatively mechanical, and thisgs are only that way for
historical reasons.  I recently ported the entire contents of
ltconfig.in (written in raw shell) to _LTCONFIG_HACK in libtool.m4
(written in terms of autoconf macros).  There are some wierd
interdependencies between some of the parts that need to be split out
into individual macros, and I haven;t had time to analyse them all
yet, so I simply put the comments in incase anyone else feels an urge
to separate them for me =)O|

> Also, I find that
> 
> | # AC_PATH_TOOL_PREFIX - find a file program which can recognise shared 
> library
> | AC_DEFUN([AC_PATH_TOOL_PREFIX],
> | [AC_MSG_CHECKING([for $1])
> | AC_CACHE_VAL(lt_cv_path_MAGIC_CMD,
> | [case "$MAGIC_CMD" in
> |   /*)
> |   lt_cv_path_MAGIC_CMD="$MAGIC_CMD" # Let the user override the test with a 
> path.
> |   ;;
> |   ?:/*)
> |   lt_cv_path_MAGIC_CMD="$MAGIC_CMD" # Let the user override the test with a 
> dos path.
> |   ;;
> 
> is a weird name and documentation for what this macro seems to be
> actually doing.

It used to be lt_cv_path_MAGIC, which holds the full path to a program
that examines the magic of a file (e.g. /usr/bin/file on most UNIX
systems), which is eventually stored in the shell variable MAGIC (like
lt_cv_path_LD and LD, or lt_cv_path_NM and NM), but it turns out that
the MAGIC variable is used to hold the location of the /etc/magic file
on some systems, so I ran s/MAGIC/MAGIC_CMD/g to fix it.

> There is something I don't understand well: is it normal that make
> check fails, but make check VERBOSE=yes works fine?

Nope.  That is pretty wierd!  Have you tried a freshly bootstrapped
clean source tree?  I get occasional spurious failures if there is any
cruft in the demo directories.  On all the boxes I have access to
(except cygwin support which has bittrotted since I last looked) cvs
HEAD passes all tests, from a freshly bootstrapped checkout.  Oh, I am
still using autoconf-2.13 and automake-1.4 (patched according to
libtool's README)... maybe that is the cause of our different
observations?

> This patch removes all the trailing spaces, be sure to keep spaces.

Are you referring to the space in '^# ' lines for extracting embedded
files?  I fixed the grep expression to accept '^#$' too.  If not, I
don't really understand what you mean.

I think it should be safe to strip trailing whitespace, but you have
me worried now, so I didn't do that part of your patch =)O|

> I have no more failures than without this patch.

What failures do you have?

Cheers,
        Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc