Re: My project can't use `silent-rules'

On Mon, 18 May 2009, Ralf Wildenhues wrote: You can use AM_SILENT_RULES Worked! Thanks! Unfortunately, it does not silence the warnings from my code. I should open a new discussion thread on the autoconf list regarding the ability to obtain version and other package information from outsi

Re: My project can't use `silent-rules'

Hi Bob, * Bob Friesenhahn wrote on Sun, May 17, 2009 at 10:43:51PM CEST: > I see that the only way to request the new `silent-rules' feature is by > using the new form of AM_INIT_AUTOMAKE to pass the option. Since my > package can not use the new form of AM_INIT_AUTOMAKE, then it can not > req

Re: automake 1.11 self test failure: vala5

Hi Simon, thanks for the bug report. * Simon Josefsson wrote on Sun, May 17, 2009 at 09:47:50PM CEST: > Hi! I installed automake 1.11 without any problems except that one > self-test failed, see snippet from tests/test-suite.log below. Is a > pkg.m4 missing? Yes. Rather, the testsuite test is

automake-1.11 test failure on darwin9 - instmany-python.test

Hi, The instmany-python test is failing for me on Mac OS X 10.5.7. Looks like it is trying to install things into /Library/Python, and as I did not run make check as the superuser, can't. Also, I wonder if it is worth checking for bsd''s 'jot' utility in these tests that use seq? Thanks, Peter --

Re: makes which break with `silent-rules'

Hi Bob, * Bob Friesenhahn wrote on Sun, May 17, 2009 at 09:59:17PM CEST: > Is anyone aware of specific vendor make programs which fail with > automake 1.11's new `silent-rules' option? I don't know of any. Cheers, Ralf

Re: My project can't use `silent-rules'

On Sun, 17 May 2009, Bob Friesenhahn wrote: I still owe you large quantities of beer. However, in order to clarify, I would like to be able to execute configure script shell script code (more like a configure test) and not generate a new configure script just because the version has changed.

Re: My project can't use `silent-rules'

On Sun, 17 May 2009, Peter O'Gorman wrote: Hi Bob, You can use m4_easycmd to run your scripts at autoconf time. E.g. (from autoconf itself): AC_INIT([GNU Autoconf], m4_esyscmd([build-aux/git-version-gen .tarball-version]), [bug-autoc...@gnu.org]) I still owe you large quantities o

Re: My project can't use `silent-rules'

On Sun, 17 May 2009, NightStrike wrote: On Sun, May 17, 2009 at 4:43 PM, Bob Friesenhahn wrote: I see that the only way to request the new `silent-rules' feature is by using the new form of AM_INIT_AUTOMAKE to pass the option.  Since my package can not use the new form of AM_INIT_AUTOMAKE, the

Re: My project can't use `silent-rules'

Bob Friesenhahn wrote: > It does not make sense to manually edit configure.ac each time a new > package needs to be produced. > > Is there a way that some of my own script code can be executed prior to > AC_INIT and a way to pass this information in a shell variable to > AC_INIT? If so, then I c

Re: My project can't use `silent-rules'

On Sun, May 17, 2009 at 4:43 PM, Bob Friesenhahn wrote: > I see that the only way to request the new `silent-rules' feature is by > using the new form of AM_INIT_AUTOMAKE to pass the option.  Since my package > can not use the new form of AM_INIT_AUTOMAKE, then it can not request > `silent-rules'.

Re: My project can't use `silent-rules'

On Sun, 2009-05-17 at 15:43 -0500, Bob Friesenhahn wrote: > The reason why my package can not use AC_INIT is that the package > version information is (often) computed by shell script code based on > the last entry in the project ChangeLog or other information. It is > (apparently) not possibl

Re: My project can't use `silent-rules'

Bob Friesenhahn writes: > The reason why my package can not use AC_INIT is that the package > version information is (often) computed by shell script code based on > the last entry in the project ChangeLog or other information. It is > (apparently) not possible for user-provided script code to b

Re: Testing for GSL

On Sunday 17 May 2009 2:52:17 pm Ralf Wildenhues wrote: > Hello Gerald, > > * Gerald I. Evenden wrote on Sun, May 17, 2009 at 08:40:46PM CEST: > > Has anyone successfully written a configure.ac that successfully tests > > for the Gnu Scientific Library (aka GSL)? > > AFAIK the GSL package distribut

My project can't use `silent-rules'

I see that the only way to request the new `silent-rules' feature is by using the new form of AM_INIT_AUTOMAKE to pass the option. Since my package can not use the new form of AM_INIT_AUTOMAKE, then it can not request `silent-rules'. The reason for this limitation is that using the new form o

makes which break with `silent-rules'

Is anyone aware of specific vendor make programs which fail with automake 1.11's new `silent-rules' option? " - The `silent-rules' option enables Linux kernel-style silent build output. This option requires the widely supported but non-POSIX `make' feature of recursive variable expansio

Re: invoke pkg-config with --static

Ralf Wildenhues wrote: * Lorenzo Bettini wrote on Sun, May 17, 2009 at 12:27:32PM CEST: Ralf Wildenhues wrote: * Lorenzo Bettini wrote on Sun, May 17, 2009 at 09:07:16AM CEST: Bob Friesenhahn wrote: On Sat, 16 May 2009, Lorenzo Bettini wrote: when ./configure is run with --disable-shared, is

Re: Testing for GSL

Hello Gerald, * Gerald I. Evenden wrote on Sun, May 17, 2009 at 08:40:46PM CEST: > Has anyone successfully written a configure.ac that successfully tests > for the Gnu Scientific Library (aka GSL)? AFAIK the GSL package distributes a macro for checking for its library. Have you tried it? Cheers,

Testing for GSL

Has anyone successfully written a configure.ac that successfully tests for the Gnu Scientific Library (aka GSL)? I would appreciate knowing how you did it? Additional comment: GSL requires an additional library so that the traditional test by compiling a test routine fails because there is no m

Re: Problems with linking multiple lex/yacc parsers into one executable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey guys I just made a quick test project there its not pretty but the src/Makefile.am bin_PROGRAMS = test noinst_LIBRARIES = libparser_a.a libparser_b.a test_SOURCES = main.c test_LDADD = libparser_a.a libparser_b.a libparser_a_a_YFLAGS = -d -p pr

GNU Automake 1.11 released

We're pleased to announce the release of Automake 1.11. Automake is a tool for automatically generating `Makefile.in's suitable for use with Autoconf, compliant with the GNU Makefile standards, and portable to various make implementations. This release contains a bunch of new features and a bunch

Re: Problems with linking multiple lex/yacc parsers into one executable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey > > To be completely portable (not depending on flex options) I don't > think either the prefix/outfile options or the prefix commandline > option can be given to lex (they are not mentioned in lex(1p) at > least). > Yeah your right about that! The

Re: Problems with linking multiple lex/yacc parsers into one executable

On Sun, 2009-05-17 at 13:46 +0200, Ralf Wildenhues wrote: > Hello, > > * Philip Herron wrote on Sun, May 17, 2009 at 12:49:32PM CEST: > > > > I solved this problem a while back! > > > > http://lists.gnu.org/archive/html/automake/2009-04/msg00095.html > > > > The trick is in each of your lexers(

Re: improve INSTALL contents

can you please also read, and follow ? I'm sure you must have missed it because I failed to spam it to three mailing lists. But your repetitions are just as boring as those from everyone else. And get bug-coreutils a

Re: Problems with linking multiple lex/yacc parsers into one executable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: > * Philip Herron wrote on Sun, May 17, 2009 at 02:00:45PM CEST: >> But i'll maby play with this. If i find a more standard solution >> what should i do? > > Write a patch (preferably against git master of Automake) that > fixes

Re: Problems with linking multiple lex/yacc parsers into one executable

* Philip Herron wrote on Sun, May 17, 2009 at 02:00:45PM CEST: > But i'll maby play with this. If i find a more standard solution what > should i do? Write a patch (preferably against git master of Automake) that fixes the Automake manual to document this precisely, and add a test to the test suit

Re: Problems with linking multiple lex/yacc parsers into one executable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: > Hello, > > * Philip Herron wrote on Sun, May 17, 2009 at 12:49:32PM CEST: >> I solved this problem a while back! >> >> http://lists.gnu.org/archive/html/automake/2009-04/msg00095.html >> >> The trick is in each of your lexers(f

Re: Problems with linking multiple lex/yacc parsers into one executable

Hello, * Philip Herron wrote on Sun, May 17, 2009 at 12:49:32PM CEST: > > I solved this problem a while back! > > http://lists.gnu.org/archive/html/automake/2009-04/msg00095.html > > The trick is in each of your lexers(flex .l) add this: > %option prefix="prefix" outfile="lex.yy.c" I don't see

Re: Problems with linking multiple lex/yacc parsers into one executable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Ahh interesting, I did stumble upon your mail before but I missed > the bit about the "outfile" option, so I got stuck with that. I > guess this option is flex-specific but at this point I just want it > to work, portability is less important since o

Re: Problems with linking multiple lex/yacc parsers into one executable

On Sun, 2009-05-17 at 11:49 +0100, Philip Herron wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hey > > I solved this problem a while back! > > http://lists.gnu.org/archive/html/automake/2009-04/msg00095.html > > The trick is in each of your lexers(flex .l) add this: > %option pre

Re: invoke pkg-config with --static

* Lorenzo Bettini wrote on Sun, May 17, 2009 at 12:27:32PM CEST: > Ralf Wildenhues wrote: >> * Lorenzo Bettini wrote on Sun, May 17, 2009 at 09:07:16AM CEST: >>> Bob Friesenhahn wrote: On Sat, 16 May 2009, Lorenzo Bettini wrote: > when ./configure is run with --disable-shared, is ther

Re: Problems with linking multiple lex/yacc parsers into one executable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey I solved this problem a while back! http://lists.gnu.org/archive/html/automake/2009-04/msg00095.html The trick is in each of your lexers(flex .l) add this: %option prefix="prefix" outfile="lex.yy.c" Dont change the outfile ylwrap needs it to be

Re: invoke pkg-config with --static

Ralf Wildenhues wrote: Hi Lorenzo, * Lorenzo Bettini wrote on Sun, May 17, 2009 at 09:07:16AM CEST: Bob Friesenhahn wrote: On Sat, 16 May 2009, Lorenzo Bettini wrote: when ./configure is run with --disable-shared, is there a way to invoke the pkg-config macro with --static (so that it does

Re: invoke pkg-config with --static

Hi Lorenzo, * Lorenzo Bettini wrote on Sun, May 17, 2009 at 09:07:16AM CEST: > Bob Friesenhahn wrote: >> On Sat, 16 May 2009, Lorenzo Bettini wrote: >> >>> when ./configure is run with --disable-shared, is there a way to >>> invoke the pkg-config macro with --static (so that it does not select

Re: improve INSTALL contents

Alfred, can you please also read, and follow ? I'm sure you must have missed it because I failed to spam it to three mailing lists. But your repetitions are just as boring as those from everyone else. And get bug-coreutils and aut

Re: Problems with linking multiple lex/yacc parsers into one executable

Hans Nieser wrote: On Sat, 2009-05-16 at 23:06 +0200, Hans Nieser wrote: Hi list, I recently started using lex/yacc and I'm having some trouble figuring out how to make it possible to link two parsers into the same executable using automake. <...> I did some more googling and it turns out th

Re: invoke pkg-config with --static

Bob Friesenhahn wrote: On Sat, 16 May 2009, Lorenzo Bettini wrote: when ./configure is run with --disable-shared, is there a way to invoke the pkg-config macro with --static (so that it does not select private libraries in the .pc file)? It seems that LT_INIT has been executed, the shell env

Re: invoke pkg-config with --static

Robert Collins wrote: On Sat, 2009-05-16 at 19:04 -0500, Bob Friesenhahn wrote: On Sat, 16 May 2009, Lorenzo Bettini wrote: when ./configure is run with --disable-shared, is there a way to invoke the pkg-config macro with --static (so that it does not select private libraries in the .pc file)