Re: Macro to select c++ as default compiler for c files.
On Mon, Nov 03, 2014 at 03:58:14PM +0530, Lakshmi M wrote: Can anyone please let me know how to use c++ compiler as default for compiling my c files. One way would be to have, anywhere in your makefiles: CC = $(CXX) That would compile *all* C as C++. signature.asc Description: Digital signature
Re: Newbie question: Changelog not found
On Wed, Aug 13, 2014 at 04:17:51PM -0700, Arthur Schwarz wrote: I ran automake --add-missing then autoreconf and automake failed to find Changelog. No, it failed to find ChangeLog. Makefile.am: error: required file './ChangeLog' not found autoreconf-2.69: automake failed with exit status: 1 Changelog (AUTHORS, NEWS ..) all exist in the directory that autoreconf is run in. What directory is Makefile looking for? If Changelog exists, that doesn't mean that ChangeLog exists. What am I missing? Where should the GNU required files be located? In the project root, where your Changelog file is. Hint: look at the casing of your file name. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: How to run TESTS automatically on each source code change?
On Thu, Jul 24, 2014 at 4:48 PM, Steffen Dettmer steffen.dett...@gmail.com wrote: Hi, I have a test that generates a log file, which I can manually run via make check. Is there a simple way to automate that? For the moment I just created a pragmatic target autotest, but I think it is ugly (and too specific). Hi, You may want to look into inotify-tools, in particular inotifywait. You can use it to monitor a list of files or optionally recursive directories for changes and do something like: while true; do inotifywait file ...; make check; done If the list of files is very large, the set-up can take a long time (several seconds for tens of thousands of files). In that case, you may want to write a smarter script with inotifywatch that has the set-up cost only once, and then you just monitor inotifywatch's standard output. If your list of files is extremely large, then you may run out of kernel memory or the user limit on inotify watches. In the latter case, you can increase the limit in /etc/sysctl.conf (the relevant variable is fs.inotify.max_user_watches). In the former case, you really have a very large file list and you may want to restrict it to your current working set. I hope this helps. Pippijn signature.asc Description: Digital signature
Re: libtool relink problem
On Wed, Jun 29, 2011 at 05:14:19PM +0200, Emmanuel Engelhart wrote:
From: Pippijn van Steenhovenpip8...@gmail.com
Date: Mon, Jun 20, 2011 at 4:55 PM
Subject: Re: libtool relink problem
To: automake@gnu.org
On Sun, Jun 19, 2011 at 03:40:06PM +0530, Santhosh Thottingal wrote:
Hi,
I am facing a problem with libtool. While installing it complains a
relink required and while doing so it tries to link against the
shared library instead of static library.
Well, the problem is better explained in this thread
http://sourceware.org/ml/automake/2004-07/msg00127.html with example
code.
I am facing exactly the same problem.
I saw a similar problem in this thread also
http://www.mail-archive.com/libtool@gnu.org/msg00782.html
Is there a solution available for this?
Thanks
Santhosh
Hi Santhosh,
I suggest writing your *_LTLIBRARIES with a comment in front, perhaps
with # to differ between disabled and enabled libraries. Then using
grep(1) to extract the names and the same tools to extract the
dependencies. You can then use tsort(1) to topologically sort the
libraries and write the actual ${dir}_LTLIBRARIES to an included .am
file. Semantically, this is what I do. In reality, I wrote a preprocessor
for automake that does this, but I don't suggest using it, as it's beta
and very much tailored to my needs.
Hi Pippijn
Thank you for taking time and trying to help us... because we really get
stucked.
I tried to understand your answer but I honestly think I'm not good
enough with automake to be able to understand and apply your
methodology. I also doubt that the other cases given by Santhosh are the
same as our, although the symptom is.
From my understanding the previously described issues occur if the
dependences are not compiled in the right order. I think this is not our
problem because at the moment the error occurs, I know the dependence is
already compiled.
The issue occurs if the dependencies are not _installed_ in the right
order.
So, I'm sure the file $(top_builddir)/src/ctpp2/src/libctpp2.la exists.
As you noted, the dependency has been compiled and linked, but for
installation, it has to be relinked:
libtool: relink: g++ -shared -nostdlib
^^
The above occurs in make install.
So my question is why automake replaces the path with libcttp2.la in
-lctpp2, replacing a static linking with a dynamic one?
It's related to rpath linking. The resulting binaries are relinked to
include $(libdir) as rpath, so that installed binaries can be called and
libraries loaded without listing $(libdir) in LD_LIBRARY_PATH or
ld.so.conf.
It looks like you are using a recursive make, in your project. Are you
sure that libcttp2.la exists in $(libdir)? As an experiment, try make
install in libctpp2's $(builddir) and then make install in
$(top_builddir).
Regards,
--
Pippijn van Steenhoven
signature.asc
Description: Digital signature
Re: libtool relink problem
On Sun, Jun 19, 2011 at 03:40:06PM +0530, Santhosh Thottingal wrote:
Hi,
I am facing a problem with libtool. While installing it complains a
relink required and while doing so it tries to link against the
shared library instead of static library.
Well, the problem is better explained in this thread
http://sourceware.org/ml/automake/2004-07/msg00127.html with example
code.
I am facing exactly the same problem.
I saw a similar problem in this thread also
http://www.mail-archive.com/libtool@gnu.org/msg00782.html
Is there a solution available for this?
Thanks
Santhosh
Hi Santhosh,
I suggest writing your *_LTLIBRARIES with a comment in front, perhaps
with # to differ between disabled and enabled libraries. Then using
grep(1) to extract the names and the same tools to extract the
dependencies. You can then use tsort(1) to topologically sort the
libraries and write the actual ${dir}_LTLIBRARIES to an included .am
file. Semantically, this is what I do. In reality, I wrote a preprocessor
for automake that does this, but I don't suggest using it, as it's beta
and very much tailored to my needs.
Cheers,
--
Pippijn van Steenhoven
signature.asc
Description: Digital signature
flex header file
Hi, in some of my projects, I use (reentrant) flex with the header-file option. This causes flex to generate a .h file in addition to the usual lex.yy.c file. However, ylwrap doesn't know about this. What would be the correct way to use flex with header files? Regards, -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: GSoC project idea: non-recursive automake project
On Sat, Mar 19, 2011 at 10:38:39AM +0100, Pippijn van Steenhoven wrote: On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? Being a student, I'd be willing to prove it ;) -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: GSoC project idea: non-recursive automake project
On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: GSoC project idea: non-recursive automake project
On Sat, Mar 19, 2011 at 10:38:39AM +0100, Pippijn van Steenhoven wrote: On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? Ok, having taken a glance at the NTP Makefiles, I have to correct that. It's trivial to do it, but a little less so to do it right, making sure it works just like before. I'm still willing to do the project. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: make -j1 fails
On Thu, Jan 13, 2011 at 07:22:20PM +0100, Ralf Wildenhues wrote: Thanks for the bug report. Which version of Automake are you using? If older than v1.10b-62-g0e411a0, then please update to 1.11.1 and retry. It may be possible that we overlooked one case in the above-mentioned commit, but I don't see where that should be. I am using automake (GNU automake) 1.11.1 from Debian squeeze. If the failure persists, please post short configure.ac and Makefile.am which expose the problem for you. You can start with what I show below, and adjust that if it doesn't expose it. The code didn't trigger the bug and I couldn't easily reproduce it by modifying it. It involves considerable effort to modify my existing project and upload it to the FreeBSD build machine and I don't have time to do that, now. GNU make does not misbehave this way, so for now I'll use that. Does the failure happen reliably, i.e., every time, or only sometimes? It happens reliably with any N in make -jN. Does 'make -B -jN' work for you reliably? Yes, that works as expected and executes the right command (the one also executed without -jN). Which exact FreeBSD version are you using? I'm kind of suspecting a bug in the make implementation, or we're overlooking something with one-shell issues. I am using FreeBSD 8.0-RELEASE-p4. -- Pippijn van Steenhoven signature.asc Description: Digital signature
make -j1 fails
Hi, I am using the FreeBSD make utility to build an automake based distribution. When I run make with a -j option (even -j1), it fails. Running make with a -j option makes the utility behave differently. The issue only arises with built sources (in my case, yacc generated C code), since those trigger the inference rule .c.lo. Perhaps a solution would be to also generate explicit rules for built sources. I have attached the output of running make with and without -j1. Regards, Pippijn van Steenhoven make V=1 axl.lo /bin/sh ../autoconf/ylwrap `test -f 'src/compiler/phases/parse/axl.y' || echo '../'`src/compiler/phases/parse/axl.y y.tab.c axl.c y.tab.h axl.h y.output axl.output -- byacc -d axl.h is unchanged /bin/sh ./libtool --tag=CC--mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I./include/config -I../include -I./include -I../include -I./include -D_DEBUG -DPREFIX='/usr/local' -I../`echo axl.c | grep -o 'src/library/\w\+'`/include -g -O2 -pipe -ggdb3 -pedantic -ansi -fvisibility=hidden -MT axl.lo -MD -MP -MF .deps/axl.Tpo -c -o axl.lo axl.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./include/config -I../include -I./include -I../include -I./include -D_DEBUG -DPREFIX=\/usr/local\ -I..//include -g -O2 -pipe -ggdb3 -pedantic -ansi -fvisibility=hidden -MT axl.lo -MD -MP -MF .deps/axl.Tpo -c axl.c -fPIC -DPIC -o .libs/axl.o mv -f .deps/axl.Tpo .deps/axl.Plo make V=1 axl.lo -j1 /bin/sh ../autoconf/ylwrap `test -f 'src/compiler/phases/parse/axl.y' || echo '../'`src/compiler/phases/parse/axl.y y.tab.c axl.c y.tab.h axl.h y.output axl.output -- byacc -d axl.h is unchanged /bin/sh ./libtool --tag=CC--mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I./include/config -I../include -I./include -I../include -I./include -D_DEBUG -DPREFIX='/usr/local' -I../`echo axl.c | grep -o 'src/library/\w\+'`/include -g -O2 -pipe -ggdb3 -pedantic -ansi -fvisibility=hidden -MT axl.lo -MD -MP -MF .deps/src/compiler/phases/parse/axl.Tpo -c -o axl.lo axl.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./include/config -I../include -I./include -I../include -I./include -D_DEBUG -DPREFIX=\/usr/local\ -I..//include -g -O2 -pipe -ggdb3 -pedantic -ansi -fvisibility=hidden -MT axl.lo -MD -MP -MF .deps/src/compiler/phases/parse/axl.Tpo -c axl.c -fPIC -DPIC -o .libs/axl.o axl.c:3626: fatal error: opening dependency file .deps/src/compiler/phases/parse/axl.Tpo: No such file or directory compilation terminated. *** Error code 1 1 error signature.asc Description: Digital signature
Re: comments in make variable definition
On Wed, Dec 22, 2010 at 06:17:47PM +0100, Stefano Lattarini wrote: On Tuesday 21 December 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Tue, Dec 21, 2010 at 01:55:39PM CET: On Sunday 19 December 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Fri, Dec 17, 2010 at 12:19:40PM CET: xmandir = $(mandir) # we want info files installed in $(mandir) because ... xman_TEXINFOS = foo.texi (And the inline comment is of course not ok ;-) (Maybe it's time to deprecate them too in the manual ...) I don't see how they were ever not problematic. Well, at least given the autoconf.texi general warnings about comments in makefiles. Ah, but AFAIK, make comments are problematic only in makefile *rules*, not in variable definitions: VAR = foo bar # a probably portable comment tgt:; touch $@ # a bad unportable commen Try also to search: ^[^\t#].*=.*\s# file:^Makefile\.am$ with google code search (not many entries, luckily, but still). Regards, Stefano Actually it is not always ok. FreeBSD's make chokes on it in some instances: VAR = foo # this comment is ok VAR = foo \ # this is also ok VAR = foo \ # this is ok \ # - Unassociated shell command Also, it will break $(am__append*) variables, but that is not relevant in this case. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: User extensions
On Mon, Nov 01, 2010 at 08:18:44PM +0100, Ralf Wildenhues wrote: 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. Hi, not having followed the code discussion very closely (just hoping it will be in git, soon, so I can start using it, as I have been waiting for something like this for a long time), I just wonder what you mean by branch coverage. If this is execution graph node coverage, then I agree, but if you mean edge coverage, I don't know how you want to achieve this. Any O(x) where x1 algorithm anywhere in the code makes it impossible. If I'm wrong, I'd like to know how Stefano produces it. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: User extensions
On Mon, Nov 01, 2010 at 08:18:44PM +0100, Ralf Wildenhues wrote: 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. Hi, not having followed the code discussion very closely (just hoping it will be in git, soon, so I can start using it, as I have been waiting for something like this for a long time), I just wonder what you mean by branch coverage. If this is execution graph node coverage, then I agree, but if you mean edge coverage, I don't know how you want to achieve this. Any O(x) where x1 algorithm anywhere in the code makes it impossible. If I'm wrong, I'd like to know how Stefano produces it. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: execvp: /bin/sh: Argument list too long
On Thu, Nov 11, 2010 at 09:54:35PM +0100, Ralf Wildenhues wrote: In other words, I can't make dist even with GNU make 3.82? What do you suggest, then? Well, you could try my patch from http://article.gmane.org/gmane.comp.gnu.make.bugs/4219 (append /raw to the URL to get it unmangled). I still think letting GNU make avoid the issue on Linux systems would be the easiest way out here. As already written, alternative workarounds include reorganizing your code a bit to have a bit more recursive makefile setup, so that each makefiles' list would remain below the limit. Hi Ralf, I was able to reduce the number of files sufficiently so I am currently not hitting the limit. In the future, when more tests are added, I will go for your second suggestion. The testsuite/ directory won't suffer much from a recursive setup. I just need to move out the .as - .c build rule to a common rules file included in all the testsuite makefiles as well as the main build makefile. Thanks, Pippijn signature.asc Description: Digital signature
Re: execvp: /bin/sh: Argument list too long
On Tue, Nov 09, 2010 at 10:37:24AM -0700, Bob Proulx wrote: Pippijn van Steenhoven wrote: I am root on my (Linux) system and I set the stack size to unlimited. The libtool macro reported a few billion (or something other really large) for maximum argument list length, bash also agreed (it easily executed the distdir target when copied into a bash script), but make doesn't. Both gnu make and pmake abort with the too long message. What Linux kernel version are you using? Note that linux-2.6.23 and later kernels have changed how this is handled. I'm using a new enough kernel. Like I said, copy/pasting the lines executed by make distdir into a shell script and executing that works fine, it's just in make that it doesn't work. To be more explicit: http://paste.xinu.at/WzKP/ works (shell script) http://paste.xinu.at/h7kj/ does not work (makefile) max_cmd_len is 3458764513820540925, which should suffice. It's just that linux still has a 128K per-argument limit, which is apparently what chokes make. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: execvp: /bin/sh: Argument list too long
On Mon, Nov 08, 2010 at 10:11:20PM +0100, Pippijn van Steenhoven wrote: make distdir fails. The Makefile.am is not a single file. A combined file is here: http://paste.xinu.at/ou4jy/, but I'm not sure that is very useful. A tarball with all .am files is here: http://paste.xinu.at/TzadQ/ In case the paste site will delete the tarball. Here it is again: http://xinutec.org/~pippijn/files/up/makefiles.tar.gz -- Pippijn van Steenhoven signature.asc Description: Digital signature
execvp: /bin/sh: Argument list too long
Hi, I looked through the mailing list archives and found several questions and proposed solutions related to this problem: - Split up file lists so several rules are generated: http://lists.gnu.org/archive/html/automake/2004-11/msg00106.html - What is your env's size? http://lists.gnu.org/archive/html/automake/2009-08/msg00027.html - It will fail. In other words Sorry, can't fix? http://lists.gnu.org/archive/html/automake/2007-02/msg00013.html My problem is that I can not make dist in one project and not make check in another project. Both have a large number of tests. The one where make check fails has a few more tests, but make dist will fail there, as well. What are the plans on fixing this? Are there any? Autoconf already checks for the maximum argument length, but since by that time, Makefile.in is already generated, it can't help. Maybe storing the list of dist files and check files in a different file and reading this with xargs $file would help. Any other ideas? -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: execvp: /bin/sh: Argument list too long
On Mon, Nov 08, 2010 at 08:03:06PM +0100, Ralf Wildenhues wrote:
* Pippijn van Steenhoven wrote on Mon, Nov 08, 2010 at 04:55:45PM CET:
I looked through the mailing list archives and found several questions
and proposed solutions related to this problem:
- Split up file lists so several rules are generated:
http://lists.gnu.org/archive/html/automake/2004-11/msg00106.html
- What is your env's size?
http://lists.gnu.org/archive/html/automake/2009-08/msg00027.html
- It will fail. In other words Sorry, can't fix?
http://lists.gnu.org/archive/html/automake/2007-02/msg00013.html
Also, we wrote a short section in the manual about this (in recent
versions):
info Automake Length Limitations
I hadn't seen that, before. Now I read it, I noticed something:
Automake itself employs a couple of strategies to avoid long command
lines. For example, when ‘${srcdir}/’ is prepended to file names, as
can happen with above $(data_DATA) lists, it limits the amount of
arguments passed to external commands.
Why doesn't it do that, always? Is the performance hit too large?
My problem is that I can not make dist in one project and not make check
in another project. Both have a large number of tests. The one where make
check fails has a few more tests, but make dist will fail there, as well.
One workaround is to put tests in more than one directory, with more
than one Makefile.am. Yes, it is ugly, I know. Another is to require
non-VPATH builds on those systems with the most severe restrictions,
such as MSYS and IRIX (if you can't convince root to increase the
limit).
I am root on my (Linux) system and I set the stack size to unlimited. The
libtool macro reported a few billion (or something other really large)
for maximum argument list length, bash also agreed (it easily executed
the distdir target when copied into a bash script), but make doesn't.
Both gnu make and pmake abort with the too long message.
What are the plans on fixing this?
We'll fix what we can fix. Without GNU make-specifics, that is hard.
One thing I'd definitely like to see done is allowing multiple
parallel-tests test suites in one Makefile.am, so you can still have a
nonrecursive setup. That may mean that 'make dist' still fails, but
my hope is that is not needed to work on every platform.
Would that be sufficient for your needs?
I'd be happy if make dist worked on my system, but it doesn't and I
didn't find a way to make it work, yet (any suggestions here?).
but since by that time, Makefile.in is
already generated, it can't help. Maybe storing the list of dist files
and check files in a different file and reading this with xargs $file
would help.
One problem is that with many constructs, automake would like to know
the exact set of files it deals with. We can try to deviate from that
in some places but my guess is that will always look like a hack that
avoids some but not all issues.
Automake can know the maximum set of files it deals with. Wouldn't that
help, already?
One other strategy we maybe could implement is alternative GNU
make-specific rules that avoid limitations by dealing with files with
make functions. That is usually doable, but doing this consistently
will be quite some work and cause quite some duplication in the
Makefile.in. I don't have current plans to pursue this;
I would definitely prefer no GNU make stuff in the generated makefiles.
you can see
e.g., the write_entries_to_file macro in the gcc/Makefile.in file in the
GCC tree for how this can be done in principle.
I'll take a look at it.
--
Pippijn van Steenhoven
signature.asc
Description: Digital signature
Re: execvp: /bin/sh: Argument list too long
On Mon, Nov 08, 2010 at 09:56:52PM +0100, Ralf Wildenhues wrote: [1] On some systems this is not true; e.g., GNU make evades the limit on MSYS for this particular point, IIRC using a response file. Can automake do something similar? The dist files are always the same (well, they should be), so they can be written to an extra file, which is then piped into xargs or something. I'd be happy if make dist worked on my system, but it doesn't and I didn't find a way to make it work, yet (any suggestions here?). You need to specify exactly where it fails if my previous suggestions were not enough. Showing the Makefile.am in question would help too. make distdir fails. The Makefile.am is not a single file. A combined file is here: http://paste.xinu.at/ou4jy/, but I'm not sure that is very useful. A tarball with all .am files is here: http://paste.xinu.at/TzadQ/ What version of GNU make are you using? There was an issue in GNU make 3.81 related to setting stack limits, that I believe is resolved in GNU make 3.82. I can't recall the details. I don't think it's that. It's that GNU make also requires the per-argument limit to be large, and IIRC that is still 128K on Linux (yes, speaking about the kernel only). I wrote about this before: http://thread.gmane.org/gmane.comp.gnu.make.bugs/4219 but my proposed hack back then was (understandably) not too popular, and I haven't gotten back to anything better yet. ;-) In other words, I can't make dist even with GNU make 3.82? What do you suggest, then? -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: execvp: /bin/sh: Argument list too long
On Mon, Nov 08, 2010 at 03:03:59PM -0500, Paul Smith wrote: On Mon, 2010-11-08 at 21:01 +0100, Pippijn van Steenhoven wrote: I am root on my (Linux) system and I set the stack size to unlimited. The libtool macro reported a few billion (or something other really large) for maximum argument list length, bash also agreed (it easily executed the distdir target when copied into a bash script), but make doesn't. What version of GNU make are you using? There was an issue in GNU make 3.81 related to setting stack limits, that I believe is resolved in GNU make 3.82. I can't recall the details. You might try that if you're not already using it. Ah, I'm using 3.81. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: Bison and automake together
On Sat, Nov 06, 2010 at 04:37:26PM +, Paulo J. Matos wrote: Does someone confirm that there is a bug here? Bison in C++ mode with -y compatibility mode generates a file which includes y.tab.h. ylwrap _cannot_ rename the file or compilation will fail. If C++ is supported there's a problem with ylwrap. If it's not supported then Yacc shouldn't display the error and abort the build. In my opinion, ylwrap should gain knowledge about the used yacc implementation and pass a -o to it if the implementation supports it. That way, line numbers will be correct (aids debugging), header file inclusions will be correct (solves your problem) and it automatically allows for multiple yacc files to coexist in one project. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: Bison and automake together
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
Re: User extensions
On Wed, Oct 27, 2010 at 02:13:00PM +0200, Valentin David wrote: On Sat, Oct 23, 2010 at 5:27 PM, Ralf Wildenhues ralf.wildenh...@gmx.de 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
Hi, On Sat, Oct 30, 2010 at 11:46:25AM +0100, Paulo J. Matos wrote: However, bison generated parser scgparser.cc includes y.tab.h (which was the name known to bison when the file was generated). This results in an error during compilation since there is no y.tab.h anymore when the scgparser.cc is compiled. What am I missing here? I solved this problem by adding my own y.tab.h which does nothing but #include scgparser.h. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: ylwrap - flex filename weirdness
On Sun, Oct 31, 2010 at 11:54:04AM +0100, Jan Engelhardt wrote: Hi, While trying to utilize Autotools in a preexisting project that previously just relied on Makefiles, I came across ylwrap failing for some absurd, unknown reason. I couldn't help but run sh -x and debug it piecewise. So what's ultimately done is running flex inside a temp directory, flex /home/jengelh/code/iproute2/tc/emp_ematch_lex.l It turns out flex produces a file called lex.ematch_.c, which is something ylwrap so does not expect at all - it only checks for what's in pairlist=yy.lex.c emp_ematch_lex.c. I can use AM_LFLAGS = -o yy.lex.c to work around it, but that feels like an ugly hack. What's up with flex here? You added a prefix ematch_ in your flex source file. ylwrap doesn't like that. In fact, ylwrap doesn't like multiple parsers in one project, at all... and it doesn't bother renaming flex-generated header files, either. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: Bison and automake together
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. -- Pippijn van Steenhoven signature.asc Description: Digital signature
