Re: PATCH RFA: Add Go support

[Ian Lance Taylor]

Ralf Wildenhues  writes:

> OK.  So IIUC one example dependency graph would be something like this:
>
>   ( sin.go cos.go exp.go ) -> math.OBJEXT -> libfem.so
>   ( grid.go solver.go )-> sub/pdesolve.OBJEXT ---^
>
> where the sets of .go files are distinct, the sets of object files
> ("packages") cannot be derived from their inputs (neither their names
> nor their contents?) but rather specified only in the makefile, and
> objects are subsumed in (static or shared) libraries or in programs
> as usual.  OBJEXT may be o or obj (for w32) or lo (for libtool).

That is essentially correct.  The source file does include the name of
the package.  E.g., your example, each of sin.go, cos.go, and exp.go
would start with "package math".  There is no necessary connection
between the name used in the source file and the name of the object
file.  But it would certainly be conventional to use the same name for
the package name and the object file name.

> We need a bit of new notation for this, and we need to teach automake
> about languages that shouldn't have renamed objects even in the presence
> of per-object flags.

Hmmm, no, the objects can be renamed.  The agreement between source
level package name and file level package name is by convention only.


>> > What if files reside in subdirs (of the current directory, or of
>> > $srcdir), will objects be created in subdirs or in the current directory
>> > (and how would we avoid creation of files below $srcdir in a VPATH
>> > build, given that $srcdir is a concept not known to the compiler a
>> > priori)?  Or maybe it has no objects at all?
>> 
>> Only one object file is created for each package.  It can go wherever.
>
> Should a package be an installable entity?  At that point we should
> think about using a separate new _PRIMARY for it.

A package can be installable by itself, sure.

>
>> > Can the user split up large projects into multiple pieces, either by
>> > separate Makefile.am files for separate directories, or somehow
>> > separately compiling the set of sources in one directory, maybe by
>> > library or by program compiled?
>> 
>> Sure.
>> 
>> > If the latter is to be supported, then
>> > things like overlapping sources become a problem (i.e., both libfoo and
>> > libbar use baz.o).
>> 
>> That can not happen, because baz.go can only be in one package.
>
> Setups like the following are not possible in theory?
>
> if WANT_FEATURE_IN_FOO
> foo_lo_SOURCES += baz.go
> else
> if WANT_FEATURE_IN_BAR
> bar_lo_SOURCES += baz.go
> endif
> endif

Right, that is not possible, unless foo.lo and bar.lo define the same
package, which would be very odd.

Ian

Re: PATCH RFA: Add Go support

[Ian Lance Taylor]

Ralf Wildenhues  writes:

> [ dropping libtool@ ]
>
> * Ian Lance Taylor wrote on Mon, Nov 01, 2010 at 09:48:03PM CET:
>> Ralf Wildenhues  writes:
>> 
>> > We need a bit of new notation for this, and we need to teach automake
>> > about languages that shouldn't have renamed objects even in the presence
>> > of per-object flags.
>> 
>> Hmmm, no, the objects can be renamed.  The agreement between source
>> level package name and file level package name is by convention only.
>
> Misunderstanding; sorry.  What I meant was that automake shouldn't by
> itself rename object file names.  It currently does that for example
> with setups like
>
> foo_SOURCES = foo.c
> bar_SOURCES = foo.c
> bar_CPPFLAGS = -Dbar

Ah, I see.  Yes, it would not make sense to do this for Go.


>> A package can be installable by itself, sure.
>
> Would that then be in the form of an object, or would you make an
> archive out of it?

It could be either way.  If there is only the one object, it might as
well just be a .o file.


>> >> > If the latter is to be supported, then
>> >> > things like overlapping sources become a problem (i.e., both libfoo and
>> >> > libbar use baz.o).
>> >> 
>> >> That can not happen, because baz.go can only be in one package.
>> >
>> > Setups like the following are not possible in theory?
>> >
>> > if WANT_FEATURE_IN_FOO
>> > foo_lo_SOURCES += baz.go
>> > else
>> > if WANT_FEATURE_IN_BAR
>> > bar_lo_SOURCES += baz.go
>> > endif
>> > endif
>> 
>> Right, that is not possible, unless foo.lo and bar.lo define the same
>> package, which would be very odd.
>
> Why?  With system-dependent differences that doesn't seem too remote
> (the conditionals don't both have to be true on the same system).
> Generally, Automake users will eventually come up with some use case
> even for pretty remote cases ...

It's normal to have a single package which had conditionally included
source files.  But what you are describing seems to be the case of the
same source file going into two different packages.  I don't know why
that would ever be useful or interesting.  But, yes, it could be done,
if both of the two different packages used the same name at the source
code level.

Ian

Re: Bison and automake together

[Philip Herron]

Yeah this all seems like a bug to me, i dont do much C++ i prefer to
use C so i havent used C++ bison parsers et'al . But yeah i have a few
work arounds to get multiple bison and flex working i have some work i
want to do to ylwrap to help it all but i really haven't got the time
at the moment. Basically it could all be fixed with automake had more
control over ylwrap or make ylwrap more dumb just makes things easier.

--Phil

On 1 November 2010 23:17, Paulo J. Matos  wrote:
> Pippijn van Steenhoven  writes:
>
>> I solved this problem by adding my own y.tab.h which does nothing but
>> #include "scgparser.h".
>
> But unfortunately each time bison is ran, the file is overwritten it
> seems. :(
>
> --
> PMatos
>
>
>

Re: Bison and automake together

[Paulo J. Matos]

Pippijn van Steenhoven  writes:

> I solved this problem by adding my own y.tab.h which does nothing but
> #include "scgparser.h".

But unfortunately each time bison is ran, the file is overwritten it
seems. :(

-- 
PMatos

Re: Bison and automake together

[Paulo J. Matos]

Pippijn van Steenhoven  writes:

> On Sun, Oct 31, 2010 at 10:55:53PM +, Philip Herron wrote:
>> Your bison file shouldnt generate any code with includes y.tab.h. You
>> must have it in your field delcarations for bison. Its only your lexer
>> needs to see these bison definitions.
>
> It does for GLR parsers.

Also for C++ parsers, with
,
| %skeleton "lalr1.cc"
`

or with same results using
,
| %language "C++"
`

This is an annoying issue that automake should strive to either solve or
document since currently automake is not compatible with C++ bison
generated parsers it seems.

-- 
PMatos

Re: [coreutils] debbugs

[Glenn Morris]

> > 1) Change the automake maintainer to bug-automake
> > 
> > 2) Activate a router rule for bug-automake, that would redirect
> > messages to debbugs.gnu.org. This should happen automatically once I
> > add an entry to the appropriate config file on debbugs.gnu.org (has not
> > been tested yet, but should work).
> 
> Please do that.  Thanks!

OK, done. In theory the router rule should take effect in the next hour.

heads-up: bug-automake will be bug-tracked

[Ralf Wildenhues]

Hello Automake bug reporters, and sorry for the cross post,

starting pretty soon, the bug-automake mailing list will be used to
drive the GNU Bug Tracker for Automake, http://debbugs.gnu.org/automake
so new messages to this list will automatically open new bug reports
and replies to existing threads will be added to existing bug reports.

Bug reporting instructions have been updated at


Thanks for your attention and your interest in GNU Automake,
Ralf

Re: [coreutils] debbugs

[Ralf Wildenhues]

Hello Glen, all, and sorry for the long delay,

* Glenn Morris wrote on Thu, Oct 14, 2010 at 01:54:45AM CEST:
> Ralf Wildenhues wrote (on Wed, 13 Oct 2010 at 22:46 +0200):
> 
> > There is one question I haven't seen addressed yet, that I think should
> > be documented: is it possible to easily export the bug database to some
> > other format?  Are there maybe any converters that do this already?
> > (I'm thinking that it should be possible, but if one has to completely
> > invent it anew, that would at least be some work.)
> 
> Hmm. I don't know - there might be some Debian tools to do that?
> 
> The bugs can be retrieved as mbox folders via the web-interface, eg:
> http://debbugs.gnu.org/cgi/bugreport.cgi?mboxmaint=yes;mbox=yes;bug=7209
> 
> Internally, they are all stored as basically mbox mail folders with
> some extra sections inbetween the messages. There are two extra files
> that summarize the status. Everything is plain text.

Let's ignore all of this, I don't think it warrants delaying the switch.

> > I think we want this.  Does bug-coreutils operate in Exclusive mode?
> 
> Yes, it does. By the way, that is just a term I made up. :)

Fine with me.

> > I think that is what would be easiest for bug-automake as well.
> 
> I agree.

OK then.

> > You can use my email address as maintainer and debbugs-submit moderator
> > for now. 
> 
> Done. "automake" exists as a package now, and I filed a test bug:
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7209
> 
> You should get a mail about it. You can play around with replying,
> setting severity, closing, etc.

That's all good.  Thanks.

> When you are ready to go ahead, the final steps would be to:
> 
> 1) Change the automake maintainer to bug-automake
> 
> 2) Activate a router rule for bug-automake, that would redirect
> messages to debbugs.gnu.org. This should happen automatically once I
> add an entry to the appropriate config file on debbugs.gnu.org (has not
> been tested yet, but should work).

Please do that.  Thanks!

> > My current plan is to apply the patch below to the tree, create the HTML
> > page from it and upload it to
> > 
> > (where it will appear for the next release anyway), so you could use
> > that as "Specific help" link on .
> 
> > +...@uref{http://debbugs.gnu.org/@/cgi/@/pkgreport.cgi?package=automake;max-bugs=100;base-order=1;bug-rev=1,
> > +bug tracker}.
> 
> May be better to simply use http://debbugs.gnu.org/automake there.

Good idea.  I've uploaded the fixed text to above URL now, will push the
commit soon.

Thanks,
Ralf

Re: PATCH RFA: Add Go support

[Ralf Wildenhues]

[ dropping libtool@ ]

* Ian Lance Taylor wrote on Mon, Nov 01, 2010 at 09:48:03PM CET:
> Ralf Wildenhues  writes:
> 
> > We need a bit of new notation for this, and we need to teach automake
> > about languages that shouldn't have renamed objects even in the presence
> > of per-object flags.
> 
> Hmmm, no, the objects can be renamed.  The agreement between source
> level package name and file level package name is by convention only.

Misunderstanding; sorry.  What I meant was that automake shouldn't by
itself rename object file names.  It currently does that for example
with setups like

foo_SOURCES = foo.c
bar_SOURCES = foo.c
bar_CPPFLAGS = -Dbar

> >> > What if files reside in subdirs (of the current directory, or of
> >> > $srcdir), will objects be created in subdirs or in the current directory
> >> > (and how would we avoid creation of files below $srcdir in a VPATH
> >> > build, given that $srcdir is a concept not known to the compiler a
> >> > priori)?  Or maybe it has no objects at all?
> >> 
> >> Only one object file is created for each package.  It can go wherever.
> >
> > Should a package be an installable entity?  At that point we should
> > think about using a separate new _PRIMARY for it.
> 
> A package can be installable by itself, sure.

Would that then be in the form of an object, or would you make an
archive out of it?

> >> > Can the user split up large projects into multiple pieces, either by
> >> > separate Makefile.am files for separate directories, or somehow
> >> > separately compiling the set of sources in one directory, maybe by
> >> > library or by program compiled?
> >> 
> >> Sure.
> >> 
> >> > If the latter is to be supported, then
> >> > things like overlapping sources become a problem (i.e., both libfoo and
> >> > libbar use baz.o).
> >> 
> >> That can not happen, because baz.go can only be in one package.
> >
> > Setups like the following are not possible in theory?
> >
> > if WANT_FEATURE_IN_FOO
> > foo_lo_SOURCES += baz.go
> > else
> > if WANT_FEATURE_IN_BAR
> > bar_lo_SOURCES += baz.go
> > endif
> > endif
> 
> Right, that is not possible, unless foo.lo and bar.lo define the same
> package, which would be very odd.

Why?  With system-dependent differences that doesn't seem too remote
(the conditionals don't both have to be true on the same system).
Generally, Automake users will eventually come up with some use case
even for pretty remote cases ...

Cheers,
Ralf

Re: PATCH RFA: Add Go support

[Ralf Wildenhues]

Hello Ian,

let's move this part of the discussion to the automake@ list.
And sorry for delays, I cannot help that ATM.

* Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 09:58:49PM CEST:
> Ralf Wildenhues writes:
> > * Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 07:31:04PM CEST:
> >> Ralf Wildenhues writes:
> >> > Do you have, or are working on, an Automake patch for Go support?
> >> 
> >> I do not have an automake patch, although that is a logical next step.
> >> I've been using libtool with a Makefile.am which uses this definition:
> >> 
> >> LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GCCGO) $(INCLUDES) \
> >>$(AM_GOFLAGS) $(GOFLAGS)
> >> 
> >> and then runs $(LTGOCOMPILE) as needed.  Adding Go support to automake
> >> may be a little tricky as Go requires a slightly different compilation
> >> model: you must pass all files that are in the same package to the
> >> compiler at once.  You can't compile them separately.
> >
> > That is not a big problem per se.  However, how would you implement
> > build parallelism?  Inside gccgo?  Should it eventually have jobserver
> > support, received from make?
> 
> Note that when I say a package I don't mean an entire program.  A
> package in Go is like a single library, or what some languages call a
> module.  E.g., the standard Go library has a fmt package, an os package,
> a math package, etc.  When compiling Go, you must pass all files in a
> package to the compiler at the same time.  In principle part of the
> compilation of a single package could be parallelized, but not in any
> simple or straightforward way.  You can group many different Go packages
> together into a single .a or .so file.

OK.  So IIUC one example dependency graph would be something like this:

  ( sin.go cos.go exp.go ) -> math.OBJEXT -> libfem.so
  ( grid.go solver.go )-> sub/pdesolve.OBJEXT ---^

where the sets of .go files are distinct, the sets of object files
("packages") cannot be derived from their inputs (neither their names
nor their contents?) but rather specified only in the makefile, and
objects are subsumed in (static or shared) libraries or in programs
as usual.  OBJEXT may be o or obj (for w32) or lo (for libtool).

We need a bit of new notation for this, and we need to teach automake
about languages that shouldn't have renamed objects even in the presence
of per-object flags.

With libtool, naming wouldn't sound so hard, one could just go with
something like:

lib_LTLIBRARIES = libfem.la
libfem_la_LIBADD = math.lo sub/pdesolve.lo  # yes, _LIBADD
math_lo_SOURCES = sin.go cos.go exp.go
sub_pdesolve_lo_SOURCES = grid.go solver.go

Without libtool, we could canonify $(OBJEXT) as _o:

bin_PROGRAMS = fem
fem_LDADD = math.$(OBJEXT) sub/pdesolve.$(OBJEXT)
math_o_SOURCES = sin.go cos.go exp.go
sub_pdesolve_o_SOURCES = grid.go solver.go

but that looks fairly ugly to me already.  Better ideas?

I'm sure users will ask to generalize the scheme for other languages,
where Automake operates differently now.  I'm not yet sure whether that
is a reason to worry or a good thing.  ;-)


> > What if files reside in subdirs (of the current directory, or of
> > $srcdir), will objects be created in subdirs or in the current directory
> > (and how would we avoid creation of files below $srcdir in a VPATH
> > build, given that $srcdir is a concept not known to the compiler a
> > priori)?  Or maybe it has no objects at all?
> 
> Only one object file is created for each package.  It can go wherever.

Should a package be an installable entity?  At that point we should
think about using a separate new _PRIMARY for it.

> > Can the user split up large projects into multiple pieces, either by
> > separate Makefile.am files for separate directories, or somehow
> > separately compiling the set of sources in one directory, maybe by
> > library or by program compiled?
> 
> Sure.
> 
> > If the latter is to be supported, then
> > things like overlapping sources become a problem (i.e., both libfoo and
> > libbar use baz.o).
> 
> That can not happen, because baz.go can only be in one package.

Setups like the following are not possible in theory?

if WANT_FEATURE_IN_FOO
foo_lo_SOURCES += baz.go
else
if WANT_FEATURE_IN_BAR
bar_lo_SOURCES += baz.go
endif
endif

Thanks,
Ralf

Re: User extensions

[Ralf Wildenhues]

* Pippijn van Steenhoven wrote on Mon, Nov 01, 2010 at 12:43:57PM CET:
> On Wed, Oct 27, 2010 at 02:13:00PM +0200, Valentin David wrote:
> > On Sat, Oct 23, 2010 at 5:27 PM, Ralf Wildenhues wrote:
> > > I haven't looked at the patch in detail yet, but will, now that
> > > the assignment papers are done (thanks!).
> > 
> > It is done.
> 
> Does this mean the feature will soon be in git?

Let's see; it would be nice indeed.

Ralf

Re: User extensions

[Ralf Wildenhues]

Hi Valentin,

let's move to the -patches list.  And sorry for the long delay.

* Valentin David wrote on Fri, Sep 03, 2010 at 06:56:53PM CEST:
> I propose a patch as attached.
> 
> * The lang_*_rewrite are added to the Language structure. The default
> is lang_sub_obj. They do not return anymore the object extension
> because the field 'output_extensions' already computes it.

As Stefano already suggested, this change is fine for master in a patch
by itself, and when it passes 'make check', regardless of the rest.

Please format patches in the way that is done throughout Automake
history (see HACKING), with ChangeLog entries, test suite additions,
and commit including modifications induced by ./bootstrap (given the
most recent stable Autoconf version in $PATH).  Thanks.  Generated files
need not be listed in the log.

> * Compilers that generate source files might still generate dependency files.
> 
> * --libdir= can be called several times, the arguments can also have a
> list of paths separated by a colon. Empty paths correspond to the
> original libdir.

Due to the colon/semicolon issues, how about we just ignore the issue
for now and require one --libdir argument per directory?

Also, the version issues can end up fairly intricate: we cannot really
expect automake 1.13 to successfully load the same Perl modules that
were meant for 1.12; there are *lots* of things that can go wrong, and
we just opened a can of API worms.  Still, I would really like to see
progress here, so let's for the moment not yet settle on a system-wide
(set of) directory(ies) where such additional third-party files should
end up at.  Another issue is overriding Automake's own .am files; we've
always treated them as requiring to be in sync with the automake.in
version and it could end up being pretty tricky to specify their API as
public in any way.

Also, I like the approach of calling the whole feature experimental and
at the same time asking users to tell us which features from automake.in
they need so we can document them and add testsuite coverage for them so
we can be sure to not break them in the future.

> * For all libdir, all libdir/lang/*.pm are loaded. This happens right
> after parsing the options.
> 
> The test tests/user_def_lang.test should show how the feature works.
> 
> I can understand that loading perl files is not really nice because
> there easily can be problems of backward compatibility.

Exactly.


Ideally, I would like to see testsuite coverage for each code path
("branch coverage") for new code.  I understand that only Stefano is
able to produce this in reasonable amount of time, so whatever you guys
can manage is better than nothing.  The new code should have a NEWS
entry and at least some documentation in the manual.  You can target
a new branch that is meant for eventual inclusion into master, let's
name it user-ext, and whether you base patches off of maint or of master
I don't care.  The latter might be easier for you.

Some nits below, in addition (or in contrast ;-) to Stefano's.

> --- a/automake.in
> +++ b/automake.in

> @@ -1858,17 +1871,15 @@ sub handle_single_transform ($%)
> }
> }
>  
> - # Note: computed subr call.  The language rewrite function
> - # should return one of the LANG_* constants.  It could
> - # also return a list whose first value is such a constant
> - # and whose second value is a new source extension which
> - # should be applied.  This means this particular language
> - # generates another source file which we must then process
> - # further.
> - my $subr = \&{'lang_' . $lang->name . '_rewrite'};
> - my ($r, $source_extension)
> - = &$subr ($directory, $base, $extension,
> + # The language rewrite function should return one of the
> +# LANG_* constants.
> + my $r
> + = &{$lang->rewrite} ($directory, $base, $extension,
> $nonansi_obj, $have_per_exec_flags, $var);
> +
> + my $output_extension
> + = (&{$lang->output_extensions} ($extension))[0];
> +
>   # Skip this entry if we were asked not to process it.
>   next if $r == LANG_IGNORE;
>  
> @@ -1876,9 +1887,9 @@ sub handle_single_transform ($%)
>   $linker = $lang->linker;
>  
>   my $this_obj_ext;
> - if (defined $source_extension)
> + if ($output_extension ne '.$(OBJEXT)')

Why this?  This looks wrong, but I cannot judge because I don't
understand why your patch would need this.

>   {
> - $this_obj_ext = $source_extension;
> + $this_obj_ext = $output_extension;
>   $derived_source = 1;
>   }
>   elsif ($lang->ansi)
> @@ -2056,10 +2067,19 @@ sub handle_single_transform ($%)
>   $lang->target_hook ($aggregate, $object, $full, %transform);
>   }
>  
> + # Transform .o or $o file into .P file (for 

Re: using autoconf with ppuxlc++,spuxlc++

[Ralf Wildenhues]

* John Wohlbier wrote on Wed, Oct 27, 2010 at 06:08:47PM CEST:
> On Wed, Oct 27, 2010 at 12:24 AM, Ralf Wildenhues wrote:
> > How exactly do you invoke configure, what does configure output as
> > dependency mechanism for these two compilers, where are the manpages
> > for the compilers?

> 1) I'm not exactly sure what you're asking about invoking configure. We have
> 3 configure.acs, and the first one uses AC_CONFIG_SUBDIRS to run the
> configures for the PPE and SPE. Those configures are done as cross compiles
> using configure.gnu. I can give you more detail about this if it's needed.
> 
> 3) I've attached the output of ppuxlc++ >& manpage. Let me know if you need
> anything else from this.
> 
> 2) I think you've found the thread to pull on. I see this:
> 
> checking dependency style of ppuxlc... (cached) gcc3
> 
> The fact that it's cached makes me nervous, b/c if I scan up the output I
> find the dependency style listed a couple times.
> 
> checking dependency style of gcc... gcc3
> checking dependency style of g++... gcc3

If I'm guessing correctly then the last lines happen during toplevel
configure, and the ppuxlc checking one in a sub configure?  If yes, then
you need to ensure to unset the respective cache variable before the
later checks (am_cv_{CC,CXX}_dependencies_compiler_type).  If no, you
need to ensure $CC/$CXX are set to the right compilers before
AC_PROG_{CC,CXX}.

> It seems like it's possible that the "boiler plate" kind of checks
> (including dependency style) are being made with gcc/g++ before I'm able to
> change to the cross compiler and it's using the previously cached value.

Yep, that's one of the possibilities.

> Either that, or depcomp really does think ppuxlc++ has gcc3 dependency
> style.

Unlikely.

> Here's a few lines from my configure.ac where CCS_WITH_PPU_COMPILER,
> CCS_TUNE_PCC, CCS_TUNE_PCXX are macros that set CC and CXX to be ppuxlc and
> ppuxlc++ respectively (I didn't originally write those macros, but I think
> they were written since AC_PROG_CC and AC_PROG_CXX don't support these
> compilers). With this ordering, should those "boiler plate" checks be
> performed with the ppuxlc(++)? Is there a way I can specifically call
> "checking dependency style"?

No.  Can you share the CCS_* macros though (including other non-public
macros they require or invoke)?  From what you posted I cannot tell what
is happening.

> AC_INIT
> AC_CONFIG_AUX_DIR(config)
> AM_INIT_AUTOMAKE
> AC_PROG_LIBTOOL
> AC_PROG_LN_S
> AC_DISABLE_SHARED
> CCS_WITH_PPU_COMPILER
> CCS_TUNE_PCC
> CCS_TUNE_PCXX

Cheers,
Ralf

Re: Bison and automake together

[Philip Herron]

On 1 November 2010 10:08, Pippijn van Steenhoven  wrote:
> On Mon, Nov 01, 2010 at 02:14:49AM +, Philip Herron wrote:
>> Then thats probably a bug although i havent played with GLR prarsers
>> in bison you may want to post this to bison-help and see what they
>> say.
>
> The thing is that bison does produce the y.tab.h header, which it then
> assumes to exist and #includes. It doesn't know ylwrap renamed it. You
> are supposed to say %defines "myparser.h" or pass bison a -o option so it
> produces myparser.c and myparser.h in the first place.
>

Yep thing is though just like normal parsers with bison it doesn't
have any hard-coded includes, and with GLR i _think_ it should be the
same no? its for your bison head/field declarations section to do the
include no? And since this breaks automake compatibility it sounds
like a bug. Even though a work around exists.

--Phil

Re: User extensions

[Pippijn van Steenhoven]

On Wed, Oct 27, 2010 at 02:13:00PM +0200, Valentin David wrote:
> On Sat, Oct 23, 2010 at 5:27 PM, Ralf Wildenhues  
> wrote:
> > I haven't looked at the patch in detail yet, but will, now that
> > the assignment papers are done (thanks!).
> 
> It is done.

Does this mean the feature will soon be in git?

-- 
Pippijn van Steenhoven


signature.asc
Description: Digital signature

Re: Bison and automake together

[Pippijn van Steenhoven]

On Mon, Nov 01, 2010 at 02:14:49AM +, Philip Herron wrote:
> Then thats probably a bug although i havent played with GLR prarsers
> in bison you may want to post this to bison-help and see what they
> say.

The thing is that bison does produce the y.tab.h header, which it then
assumes to exist and #includes. It doesn't know ylwrap renamed it. You
are supposed to say %defines "myparser.h" or pass bison a -o option so it
produces myparser.c and myparser.h in the first place.

-- 
Pippijn van Steenhoven


signature.asc
Description: Digital signature