headers
John P. Hartmann | 7 Mar 13:18
Picon

--skeleton is a bit heavy-handed

Oghtn't it not to respect a leading slash or dot-slash?

I think it worked five years ago on the version 1 level I then used then.

Cheers,

   j.

bison -o ref.c -v -d fplspy.y --skeleton=/home/john/src/specs/bisonhacked.c
/usr/bin/m4: /usr/share/bison//home/john/src/specs/bisonhacked.c: No such
file or directory
bison: subsidiary program `/usr/bin/m4' failed (exit status 1)
gmake: *** [ref.c] Error 1
j /home/john/src/specs: bison --version
bison (GNU Bison) 2.3

j /home/john/src/specs: uname -a
Linux Fedora6 2.6.22.2-42.fc6 #1 SMP Wed Aug 15 11:32:12 EDT 2007 i686 i686
i386 GNU/Linux

j /home/john/src/specs: cc --version
cc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13)
Copyright (C) 2006 Free Software Foundation, Inc.
Permalink | Reply | 1 comment |
headers
Joel E. Denny | 7 Mar 15:16

Re: --skeleton is a bit heavy-handed

On Fri, 7 Mar 2008, John P. Hartmann wrote:

> Oghtn't it not to respect a leading slash or dot-slash?

Thanks for the report.  It's fixed in CVS.
Permalink | Reply | 0 comments |
headers
Paul Hilfinger | 27 Mar 02:26
Picon
Favicon

Bootstrapping issue finally resolved


Back in August, I reported a problem with bootstrapping Bison from the
CVS repository (appended below).  I didn't have any urgent reason to
resolve the problem, so it has languished, but FYI I have finally
resolved the issue.  It had to do with my installation of automake.
Because the Bison maintainers update the autoconf/automake versions
that they use far more frequently than anyone else on earth (:->), I
have to maintain my own local versions of these tools.  Unfortunately,
my usual method of package installation, where I create a separate
subdirectory for each installation, with some symbolic links to it
from a one bin directory, didn't work with these tools.  Specfically,
aclocal (in automake) looks for .m4 files in the directory under which
it is installed, and was therefore not finding the .m4 files
associated with gettext (also locally installed on my system, but in a
separate installation subdirectory).

Thanks to all who suggested fixes.  While it turns out that there was
a problem with my (g)m4 (actually, autom4te) installation, it was not,
in fact, the culprit in this case.

Paul Hilfinger

-------------------------------------------------------------------

>If running ./bootstrap fails with the following messages, what is the
>likely cause?  Using autoconf 2.61, automake 1.9.6, gettext 0.15 on
>Solaris 10, i86pc.
>
>Here is an extract of the warnings and error messages....
>
(Continue reading)

Permalink | Reply | 501 comments |
headers
Paul Hilfinger | 27 Mar 02:29
Picon
Favicon

Bash vs. sh


The bootstrap file is headed

    #! /bin/sh

However, it contains lines such as 

     if ! "$SHA1SUM" -c --status "$cksum_file" < "$new_po" >  /dev/null; then

and 

     if ! test -d "$dst_dir"; then

In a standard Solaris 10 installation, /bin/sh does not recognize the
'!' command.  I had to fix this by changing the shell used by
bootstrap to /bin/bash.

P. Hilfinger
Permalink | Reply | 1 comment |
headers
Hans Aberg | 27 Mar 13:52
Picon
Picon

Re: Bootstrapping issue finally resolved

On 27 Mar 2008, at 02:26, Paul Hilfinger wrote:

> Specfically,
> aclocal (in automake) looks for .m4 files in the directory under which
> it is installed, and was therefore not finding the .m4 files
> associated with gettext (also locally installed on my system, but in a
> separate installation subdirectory).

Exactly where are .m4 files looked for, and what was the workaround?  
- I have experienced some similar problems with some programs (guile,  
certain darcs downloads).

   Hans Aberg
Permalink | Reply | 502 comments |
headers
Paul Hilfinger | 27 Mar 17:36
Picon
Favicon

Re: Bootstrapping issue finally resolved


> > Specfically,
> > aclocal (in automake) looks for .m4 files in the directory under which
> > it is installed, and was therefore not finding the .m4 files
> > associated with gettext (also locally installed on my system, but in a
> > separate installation subdirectory).
> 
> Exactly where are .m4 files looked for, and what was the workaround?  
> - I have experienced some similar problems with some programs (guile,  
> certain darcs downloads).

Hans,

Well, I've appended what the aclocal info pages have to say on the
subject.   In my case, I rearranged my installation directories to be
more orthodox, but probably the 'dirlist' option at the bottom would
do as well or better.

Paul Hilfinger

    Macro search path
=================

       By default, `aclocal' searches for `.m4' files in the following
    directories, in this order:

    `ACDIR-APIVERSION'
	 This is where the `.m4' macros distributed with automake itself
	 are stored.  APIVERSION depends on the automake release used; for
	 automake 1.6.x, APIVERSION = `1.6'.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hans Aberg | 27 Mar 18:42
Picon
Picon

Re: Bootstrapping issue finally resolved

On 27 Mar 2008, at 17:36, Paul Hilfinger wrote:

> Well, I've appended what the aclocal info pages have to say on the
> subject.   In my case, I rearranged my installation directories to be
> more orthodox, but probably the 'dirlist' option at the bottom would
> do as well or better.

Thanks. The error I encountered is reported here, which involvs also  
aclocal in certain blends:
   http://lists.gnu.org/archive/html/bug-autoconf/2008-03/msg00004.html

   Hans Aberg
Permalink | Reply | 0 comments |

Gmane