Re: makes which break with `silent-rules'
On Sunday 2009-05-24 15:24, Thomas Dickey wrote: > On Sun, 24 May 2009, Bruno Haible wrote: > >>> - 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 expansion, >> >> We are talking about constructs like this: >> >> == Makefile == >> all : >> echo $(XY_V) >> >> XY_V = $(XY_$(V)) >> XY_0 = silent >> XY_1 = verbose >> XY_ = unknown >> == >> >> I think this is supported by POSIX. POSIX [1] says: "Macros can appear >> anywhere >> in the makefile.". > > POSIX says that; however different implementations of 'make' treat > forward-references differently. Well that's when you would put XY_V last, just to be sure: XY_ = unknown XY_0 = silent XY_1 = verbose XY_V = $(XY_$(V)) then there is no forward reference.
Re: KDE linking problem with automake projects
Hello Erwin, * Erwin Brandenberger wrote on Wed, May 27, 2009 at 09:33:49AM CEST: > > OS: Ubuntu 9.04 > IDE: KDE > > Project HC is Program and not a Library. Why it uses libtool ? Any help ? > > Making all in HC > /bin/bash ../../libtool --tag=CXX --mode=link g++ -DRUN_UNIX -DRUN_LINUX -g > -O2 -o HC HCApp.o HCDocument.o HCGridMDIChild.o HCImages.o HCMainWindow.o > HCPpSimulationSheet.o HCPpSimulationSimulationPage.o > HCPrefDirectoriesDialog.o ../../src/HCRw/libHCRw.a ../../src/HCDb/libHCDb.a > ../../libtool: line 835: X--tag=CXX: command not found > ../../libtool: line 868: libtool: ignoring unknown tag : command not found The libtool script is generated from the ltmain.sh file and some configure tests. These tests come from the libtool.m4 file and some others, and are integrated into configure by the autoconf program, typically after being added to aclocal.m4 by the aclocal program. The error you are seeing happens when the ltmain.sh and the macros do not come from the same Libtool version. I do not know whether you run the libtoolize, aclocal, autoconf etc. programs yourself or you have some IDE do it for you. In the former case, you need to rerun them, after letting aclocal point to the right macro files; in the latter case, you should report this bug to the IDE maintainers. Hope that helps. It would be nice if you could post a solution to this issue here (or on the libtool list), once you've found it, because users come here more often to ask about this, but never to report whether and how they got their problem solved. And if there is something special to be done with some IDE, then we'd like to know about it. Cheers, Ralf
Re: Multiple Lexer Solution
Hello Philip, * Philip Herron wrote on Wed, May 27, 2009 at 01:51:36PM CEST: > I think i see the portable solution to the multiple lexer problem we > have been having, i think i will just put in a test case and update > the documentation on whats the best way to use automake to handle it > for you. Great! > The solution is correct on the automake documentation but its quite > unclear because the %option prefix i was using in flex is probably a > flex only option but what is does is exactly what happens in the > current automake documentation but its awkward to setup with automake > well its more just its unclear. I'm not sure I understand this paragraph. Are you saying that the bits that are currently documented in the Automake manual are correct but not clear or not sufficient? And they basically have the same effect as the %option prefix has, but the difference being that the list of #defines is also portable to non-flex lexers? That would be good. > If i start to update some documentation etc + a test case to automake > master git, do i just send the patch on the mailing list? Yes. Ideally you would send a patch against the git master tree of Automake; but sending one against 1.11 would be fine, too. > And do i need gcc copyright approval or however is it called? For nontrivial changes, the FSF needs a copyright assignment, yes. Details will follow off-list. Cheers, Ralf
Re: KDE linking problem with automake projects
On Wed, 27 May 2009, Erwin Brandenberger wrote: OS: Ubuntu 9.04 IDE: KDE Project HC is Program and not a Library. Why it uses libtool ? Any help ? It seems that the libtool used has a bug on your system or the libtool has been delivered improperly (e.g. mixing files from multiple libtool versions). What does './libtool --version' (using the libtool the package is using) say? Regardless, this appears to be a libtool problem rather than an automake problem so it should be discussed on the libtool list. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
KDE linking problem with automake projects
OS: Ubuntu 9.04 IDE: KDE Project HC is Program and not a Library. Why it uses libtool ? Any help ? Making all in HC /bin/bash ../../libtool --tag=CXX --mode=link g++ -DRUN_UNIX -DRUN_LINUX -g -O2 -o HC HCApp.o HCDocument.o HCGridMDIChild.o HCImages.o HCMainWindow.o HCPpSimulationSheet.o HCPpSimulationSimulationPage.o HCPrefDirectoriesDialog.o ../../src/HCRw/libHCRw.a ../../src/HCDb/libHCDb.a ../../libtool: line 835: X--tag=CXX: command not found ../../libtool: line 868: libtool: ignoring unknown tag : command not found ../../libtool: line 835: X--mode=link: command not found ../../libtool: line 1002: *** Warning: inferring the mode of operation is deprecated.: command not found ../../libtool: line 1003: *** Future versions of Libtool will require --mode=MODE be specified.: command not found gcc: no input files gcc: no input files gcc: no input files gcc: no input files ../../libtool: line 2240: X-DRUN_UNIX: command not found ../../libtool: line 2240: X-DRUN_LINUX: command not found ../../libtool: line 2240: X-g: command not found ../../libtool: line 2240: X-O2: command not found ../../libtool: line 2409: XHC: command not found X: user not authorized to run the X server, aborting. ../../libtool: line 2421: XHC: command not found ../../libtool: line 2429: mkdir /.libs: No such file or directory mkdir: cannot create directory `/.libs': Permission denied make[3]: *** [HC] Error 1 make[3]: Target `all' not remade because of errors. Making all in HCDb make[3]: Nothing to be done for `all'. Making all in HCRw make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. make[2]: *** [all-recursive] Error 1 make[2]: Target `all' not remade because of errors. make[2]: Nothing to be done for `all-am'. make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 *** Exited with status: 2 *** -- View this message in context: http://www.nabble.com/KDE-linking-problem-with-automake-projects-tp23737527p23737527.html Sent from the Gnu - Automake - General mailing list archive at Nabble.com.
Multiple Lexer Solution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey I think i see the portable solution to the multiple lexer problem we have been having, i think i will just put in a test case and update the documentation on whats the best way to use automake to handle it for you. The solution is correct on the automake documentation but its quite unclear because the %option prefix i was using in flex is probably a flex only option but what is does is exactly what happens in the current automake documentation but its awkward to setup with automake well its more just its unclear. If i start to update some documentation etc + a test case to automake master git, do i just send the patch on the mailing list? And do i need gcc copyright approval or however is it called? Thanks guys :-) - --Phil -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkodKUgACgkQAhcOgIaQQ2EcXQCbBdeNyseaEjR/hljGT9cDsh/V ok8AnRKZGC0SuXbMg+CNYvINH1zfKCj5 =NPaE -END PGP SIGNATURE-
