.o naming seems strange

2007-08-09 Thread Jan Engelhardt
Hi, I observe that automake gives programs inconsistent .o names. For example: Result when running make (beautified here): Expected result: CC fifo-unblock.o CCLD fifo-unblock CC fifo.o CC launch.o CCLD ccgfs-fifo CC

directory prefix on .o

2007-08-09 Thread Jan Engelhardt
Hi again :) in a different project, I have a number of files that have the same filename, but live in different directories, for example project/module1/hooks.c project/module1/m1.c project/module2/hooks.c project/module2/m2.c etc.

Re: directory prefix on .o

2007-08-09 Thread Jan Engelhardt
On Aug 9 2007 19:08, NightStrike wrote: Unfortunately, it does not seem like the directory is encoded into the object file, hence automake will fail on me since it wants to use hooks.o for both hooks.c files. Is it currently possible to make the directory part of the object name, e.g.

${} and $()

2007-08-17 Thread Jan Engelhardt
Hi, is there any real difference between $(var) and ${var}, and is the latter as much POSIX as the first? thanks, Jan --

library was not installed

2007-08-23 Thread Jan Engelhardt
Hi, in the testcase at http://jengelh.hopto.org/f/am.tar.bz2 , liba.la does not get installed. What is the cause of this and how could I fix it? thanks, Jan == $ ./configure --prefix=$PWD/rt $ make install CC a.lo CC b.lo CCLD libb.la CCLD liba.la CC

Subdir prerequisites

2007-12-25 Thread Jan Engelhardt
Hi, in a simple Makefile.am with SUBDIRS = foo bin_PROGRAMS = bar how can I achieve that bar will be compiled before operation descends into foo/? thanks, Jan

Re: Subdir prerequisites

2007-12-25 Thread Jan Engelhardt
On Dec 25 2007 17:58, Jan Engelhardt wrote: in a simple Makefile.am with SUBDIRS = foo bin_PROGRAMS = bar how can I achieve that bar will be compiled before operation descends into foo/? Nevermind, just found it in the info pages :) Something as simple as SUBDIRS = . foo

make automake less verbose (try 2)

2008-10-23 Thread Jan Engelhardt
. Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] # All rights are handed to the automake team. --- automake.in | 91 ++-- lib/am/depend2.am |6 +++ lib/am/library.am |5 +- lib/am/ltlibrary.am |1 lib/am/program.am |1

Re: make automake less verbose (try 2)

2008-10-23 Thread Jan Engelhardt
On Thursday 2008-10-23 19:20, Ralf Wildenhues wrote: Anyway, when we use nonconforming constructs then it's probably safer if they are default-off, so the developer can choose to enable it and knows the limitation. I suppose we can have an Automake option 'silent' or so (better name suggestions

Re: cyclic dependancy

2008-10-27 Thread Jan Engelhardt
On Monday 2008-10-27 08:19, Neel Basu wrote: On Sunday 26 Oct 2008 11:41:26 pm Ralf Wildenhues wrote: $(top_builddir)/cgi++/libcgixx.la: cd $(top_builddir)/cgi++ $(MAKE) $(AM_MAKEFLAGS) libcgixx.la in the Makefile.am files that need it. If the cgi++ directory has BUILT_SOURCES,

Re: make automake less verbose (try 2)

2008-11-04 Thread Jan Engelhardt
On Friday 2008-10-24 03:19, Jan Engelhardt wrote: On Thursday 2008-10-23 19:20, Ralf Wildenhues wrote: [...] I noticed that AM_VERBOSE_YACC is not used when in the .l.c and .y.c rules. Do you know why? ## In fast-dep mode, we can always use -o. ## For non-suffix rules, we must emulate

automake less verbose (iter 3)

2008-11-05 Thread Jan Engelhardt
=level` Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] --- automake.in | 134 lib/am/depend2.am | 21 lib/am/lex.am |3 - lib/am/library.am |4 - lib/am/ltlibrary.am |2 lib/am/program.am |2

Using nonstandard (static) lib name

2008-11-10 Thread Jan Engelhardt
Hi, for shared libraries, it is possible to use myshared_so_LDFLAGS = -module to tell automake not to warn about the missing lib prefix. For static libraries however, something like that does not work since there is no ld involved, and automake warns about the missing lib prefix. Is

Re: Using nonstandard (static) lib name

2008-11-10 Thread Jan Engelhardt
On Monday 2008-11-10 20:53, Bob Friesenhahn wrote: On Mon, 10 Nov 2008, Jan Engelhardt wrote: for shared libraries, it is possible to use myshared_so_LDFLAGS = -module to tell automake not to warn about the missing lib prefix. For static libraries however, something like that does

automake manual: distclean

2008-11-26 Thread Jan Engelhardt
Hi, the automake info page has this to say about distcleancheck: If you want `distcleancheck' to ignore built files that have not been cleaned because they are also part of the distribution, add the following definition instead: distcleancheck_listfiles = \ find -type f -exec

simple distcheck fails

2008-11-27 Thread Jan Engelhardt
Hi, here's a problem I just cannot figure out on my own -- distcheck always fails on data using the following test files: ---8--- Makefile.am AUTOMAKE_OPTIONS = foreign subdir-objects noinst_DATA = foo.txt ---8--- ---8--- configure.ac AC_INIT([foo], [0]) AM_INIT_AUTOMAKE([-Wall])

Re: lzip support

2008-11-28 Thread Jan Engelhardt
On Friday 2008-11-28 17:21, Bob Friesenhahn wrote: Since LZIP support has appeared apparently out of the blue (no prior discussion on this list), and Automake already had LZMA support, can someone please explain LZIP vs LZMA and why we now have at least two LZMA compressed targets? See

Re: lzip support

2008-11-28 Thread Jan Engelhardt
On Friday 2008-11-28 19:38, Bob Friesenhahn wrote: On Fri, 28 Nov 2008, Jan Engelhardt wrote: It was my impression that Automake adopted LZMA utils without fully evaluating the impact. My own package is now distributing .lzma packages. It's only great until something better comes up

Re: simple distcheck fails

2008-11-28 Thread Jan Engelhardt
On Friday 2008-11-28 20:05, Ralf Wildenhues wrote: 14:04 yaguchi:../test/obj make distcheck V=2 [...] make[1]: Entering directory `/dev/shm/test/obj/foo-0/_build' depbase=`echo foo.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`;\ gcc -DPACKAGE_NAME=\foo\ -DPACKAGE_TARNAME=\foo\

Re: lzip support

2008-11-28 Thread Jan Engelhardt
On Friday 2008-11-28 21:37, Bob Friesenhahn wrote: If an archive format was ever offered before, the feeling is that it must continue to be offered for the rest of time. *sigh* well, everybody is entitled to do his own liking and if that's providing all formats just because. Currently

Re: lzip support

2008-11-29 Thread Jan Engelhardt
On Saturday 2008-11-29 10:06, Jim Meyering wrote: Jan Engelhardt [EMAIL PROTECTED] wrote: On Friday 2008-11-28 17:21, Bob Friesenhahn wrote: Since LZIP support has appeared apparently out of the blue (no prior discussion on this list), and Automake already had LZMA support, can someone please

Re: lzip support

2008-11-29 Thread Jan Engelhardt
On Saturday 2008-11-29 17:04, Bob Friesenhahn wrote: On Sat, 29 Nov 2008, Jim Meyering wrote: I have been following lzma-utils development closely for some time, and my impression is that xz obviates lzip. I would not want to encourage use of lzip without a convincing argument to the

Re: lzip support

2008-11-29 Thread Jan Engelhardt
On Saturday 2008-11-29 17:30, Ralf Wildenhues wrote: On Friday 2008-11-28 21:37, Bob Friesenhahn wrote: It makes sense to me that periodically Automake maintainers make an evaluation (and with the blessing of the FSF) intentionally deprecate generation of certain archive types as new

Re: Multilib sources and variables

2008-11-29 Thread Jan Engelhardt
On Sunday 2008-11-30 01:52, NightStrike wrote: Is the following kosher? It will produce two 32-bit libraries on all architectures where gcc defaults to a 32-bit output. shell32src=libsrc/shell32.c lib32_LIBRARIES += lib32/libshell32.a lib32_libshell32_a_SOURCES = $shell32src

Re: Multilib sources and variables

2008-11-30 Thread Jan Engelhardt
On Sunday 2008-11-30 02:24, Jan Engelhardt wrote: On Sunday 2008-11-30 01:52, NightStrike wrote: Is the following kosher? It will produce two 32-bit libraries on all architectures where gcc defaults to a 32-bit output. (In other words, you are missing -m64. And perhaps some logic so that lib64

Re: Multilib sources and variables

2008-11-30 Thread Jan Engelhardt
On Sunday 2008-11-30 18:07, NightStrike wrote: Is the following kosher? It will produce two 32-bit libraries on all architectures where gcc defaults to a 32-bit output. (In other words, you are missing -m64. And perhaps some logic so that lib64 is not built in pure 32-bit environments.)

Re: automake less verbose (iter 3)

2008-12-05 Thread Jan Engelhardt
On Wednesday 2008-11-05 09:38, Jan Engelhardt wrote: third round here of the automake-tranquility patch from me. Updates from previous attempts: 1. using am__ prefix 2. removed the strange find_link_verbose() function 3. verbosity selectable in configure.ac too defaulting to maximum

Building static library with PIC

2008-12-08 Thread Jan Engelhardt
Hi, at the moment, the pam_mount project uses the following hack to workaround a libtool warning message: # Makefile.am (abridged) bin_PROGRAMS = mount.crypt mount_crypt_SOURCES = nlt-loop.c ... lib_LTLIBRARYES = pam_mount.la

rfe: Direct -fPIE support

2008-12-08 Thread Jan Engelhardt
Hi, is there a chance automake and/or libtool would support -fPIE for executables, much like libtool unconditionally turns on -fPIC for shared libraries?

Re: rfe: Direct -fPIE support

2008-12-09 Thread Jan Engelhardt
Hi Ralf, On Tuesday 2008-12-09 07:15, Ralf Wildenhues wrote: * Jan Engelhardt wrote on Tue, Dec 09, 2008 at 12:11:52AM CET: is there a chance automake and/or libtool would support -fPIE for executables, much like libtool unconditionally turns on -fPIC for shared libraries? Just using

Re: rfe: Direct -fPIE support

2008-12-09 Thread Jan Engelhardt
On Tuesday 2008-12-09 19:50, Ralf Wildenhues wrote: Just using ./configure CFLAGS=-fPIE should work fine, or put it in target_CFLAGS if you only want some targets to be PIE. Be sure to use recent Libtool, so that libraries ^ get the

Re: GNU Make Extensions

2008-12-10 Thread Jan Engelhardt
On Wednesday 2008-12-10 16:04, Bob Friesenhahn wrote: On Wed, 10 Dec 2008, Tom Browder wrote: * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET: Is it legal to use the += operator in lieu of \ when listing members of a variable in Makefile.am's? Yes. In this case, an Automake

Re: including autoconf paths in source

2008-12-11 Thread Jan Engelhardt
On Thursday 2008-12-11 21:38, Monty Taylor wrote: Hey all, I'm wondering if there is a best practice for getting paths such as locaeldir or datadir into source code. As it stands now in the Makefile I've got: prefix= /usr/local datarootdir= ${prefix}/share localedir = ${datarootdir}/locale To

Re: automake less verbose (iter 3.1)

2008-12-15 Thread Jan Engelhardt
On Monday 2008-12-15 08:32, William Pursell wrote: Jan Engelhardt wrote: third round here of the automake-tranquility patch from me. Updates from previous attempts: I've been looking through the archive and haven't noticed any followup on this. I don't know if it counts for anything but I

Re: automake less verbose (iter 3.1)

2008-12-15 Thread Jan Engelhardt
On Monday 2008-12-15 21:19, William Pursell wrote: Thanks for this Jan, it is really nice functionality. I don't know if this is a portability issue, but I think it would be nice to change $ to $? in this section: +'am__1verbose_CCLD_1 = @echo CCLD $@ - $;', +

Re: automake less verbose (iter 3.1)

2008-12-22 Thread Jan Engelhardt
On Monday 2008-12-15 21:48, Jan Engelhardt wrote: On Monday 2008-12-15 21:19, William Pursell wrote: Thanks for this Jan, it is really nice functionality. I don't know if this is a portability issue, but I think it would be nice to change $ to $? in this section

Re: automake less verbose (iter 3)

2008-12-22 Thread Jan Engelhardt
On Monday 2008-12-22 21:36, Ralf Wildenhues wrote: On Monday 2008-12-15 21:19, William Pursell wrote: The make info pages mention that $? expands to “all the prerequisites that are newer than the target”, and that sounds like there could be more than just the .c file. I just noticed that

Re: AM_COND_IF

2009-01-02 Thread Jan Engelhardt
On Friday 2009-01-02 17:33, Matěj Týč wrote: Hello, I would like to use the AM_COND_IF macro in my configure.ac, but when I run autoreconf, I get an error message saying that the macro couldn't be found anywhere. I could not find it in the manual either, so the macro is probably not the right

Automake_flags not override

2009-01-02 Thread Jan Engelhardt
Hi, given a configure.ac which defines AM_INIT_AUTOMAKE([-Wall]), running `automake -Wnone` still produces the warnings I had with -Wall. I think command line should override any earlier flags.

Portable suffix rules question

2009-01-02 Thread Jan Engelhardt
Hi, I reckon that %-style suffix rules (e.g. %.o: %.c) are rather unportable, but I wonder how the old-fashioned suffix rule for %.1: %.1.php would look like.

Re: AM_COND_IF

2009-01-02 Thread Jan Engelhardt
On Friday 2009-01-02 20:57, Matěj Týč wrote: Did you try regenerating the aclocal files?- usually done by `autoreconf -fi`. Yes, I tried it and it did not help, I still get the error. Are there any files where the macro is supposed to be defined to check? Grepping in the automake tree

Re: checking for glib

2009-01-20 Thread Jan Engelhardt
On Tuesday 2009-01-20 10:37, Lorenzo Bettini wrote: Hi I'd need to use the function g_find_program_in_path () in glib, if glib is found in the system... which is the best way of doing that? using the pkconfig or some specific macro provided by glib itself? Yes,

Re: R_X86_64_32S error building a shared library

2009-01-25 Thread Jan Engelhardt
On Sunday 2009-01-25 05:46, Adam Nielsen wrote: x86_64-pc-linux-gnu/bin/ld: .../lib64/libboost_system-mt-1_37.a(error_code.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC .../lib64/libboost_system-mt-1_37.a: could not

Re: R_X86_64_32S error building a shared library

2009-01-25 Thread Jan Engelhardt
On Monday 2009-01-26 01:23, Adam Nielsen wrote: x86_64-pc-linux-gnu/bin/ld: .../lib64/libboost_system-mt-1_37.a(error_code.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC .../lib64/libboost_system-mt-1_37.a: could not

Re: blank line following trailing backslash

2009-01-25 Thread Jan Engelhardt
On Sunday 2009-01-25 18:42, Andreas wrote: When you specify a list of files for a rule you put every file in a line like this. fileA.c \ fileB.c \ fileC.c now if 2 independent people add another file fileD and fileE to that list you have a conflict because both of them modify the

Re: Install to lib64

2009-01-25 Thread Jan Engelhardt
On Sunday 2009-01-25 22:54, Jason Sewall wrote: I'm maintaining an autotools-configured project, and I've noticed that the make install resulting from my build (on x86_64 arch, linux) puts generated libraries in prefix/lib instead of prefix/lib64 - is there something I should do differently, or

Re: R_X86_64_32S error building a shared library

2009-01-26 Thread Jan Engelhardt
On Monday 2009-01-26 23:33, Adam Nielsen wrote: $ g++ -fPIC -c -o main.o main.cpp -I/usr/include/boost-1_37/ g++ -o test.so main.o -shared This works since main.cpp is being compiled to main.o with PIC. However, Boost is not involved here so it proves nothing about Boost. It does prove

Re: Where to generate .lo files ?

2009-02-04 Thread Jan Engelhardt
On Wednesday 2009-02-04 10:33, Michel Briand wrote: Furthermore I noted that .o files are twice for one source file: $ find . -name main.* -ls 49646234 -rw-r--r-- 1 michel users 266 fév 4 10:22 ./main.lo 44401878 -rw-r--r-- 1 michel users5268 fév 4 10:22

Re: Appending to builtin Automake variables from an included file

2009-02-25 Thread Jan Engelhardt
On Thursday 2009-02-26 00:44, Allan Caffee wrote: What is the cleanest to way to append something to a builtin variable (e.g. MAINTAINERCLEANFILES) from an Automake header.[...] Is there a cleaner, ideally non-invasive method for adding things to these builtin lists? In one project I use --

Re: Appending to builtin Automake variables from an included file

2009-02-28 Thread Jan Engelhardt
On Saturday 2009-02-28 11:16, Ralf Wildenhues wrote: Modern Automake does support appending. But only appending to a variable that has already been set. Yes. This is done primarily to be able to diagnose typos, e.g., foolish = foo1ish += bar [...] Is it worth the hassle? It's certainly

Re: Destination directory for object files

2009-03-03 Thread Jan Engelhardt
On Tuesday 2009-03-03 22:37, Ralf Wildenhues wrote: * Jeff Ward wrote on Tue, Mar 03, 2009 at 10:31:01PM CET: What I was hoping for was an ability to make the rule look something like the following: .cpp.o: if $(CXXCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o objects/$@ $; \

Re: automake less verbose branch

2009-03-07 Thread Jan Engelhardt
On Saturday 2009-03-07 16:16, Ralf Wildenhues wrote: Hello Jan, all, I've worked a bit on the less verbose automake stuff, and put the result up as a branch in the git repository: git clone git://git.savannah.gnu.org/automake.git git branch je-silent origin/je-silent-am

Re: Does using automake+autoconf require my project to be GPL'ed?

2009-03-09 Thread Jan Engelhardt
On Monday 2009-03-09 14:45, almkglor wrote: What I'd like to know is, does using Automake+Autoconf require me to license distributions built using them with the GPL? [...] While GPL is OK by me, it might not be as popular among other developers. ^^ I could list apache-httpd2 as an example

Re: git branch strategy after 1.11

2009-03-24 Thread Jan Engelhardt
On Sunday 2009-03-22 12:23, Ralf Wildenhues wrote: Hello everyone, just to let you know, after 1.11 I intend to change the branch setup a bit. When branch-1-11 is created, I will also create a branch maint, which will then receive bug fixes appropriate for both 1.11.x and 1.11a. The maint

Re: git branch strategy after 1.11

2009-03-24 Thread Jan Engelhardt
Hi Ralf, On Tuesday 2009-03-24 22:48, Ralf Wildenhues wrote: And: once branch-1.11 development finally ceases, it can be deleted. This works because the commits remain reachable via the release tags. If necessary, the branch pointer can simply be recreated. What would be the advantage of

ylwrap fails with name-prefixed .l file

2009-03-24 Thread Jan Engelhardt
Hi, when a scanner.l file contains %option prefix=foo_ flex will output to lex.foo_.c instead of lex.yy.c, causing ylwrap to fail (automake runs:) /bin/sh ../ylwrap scanner.l lex.yy.c scanner.c -- flex How would one best proceed here? Especially when there are

ylwrap and flex --header-file

2009-03-24 Thread Jan Engelhardt
Hi, when one uses --header-file in conjunction with ylwrap, the header file is produced in the temporary directory ylwrap runs in instead of ${srcdir}. I think this should be addresses somehow - I'm open to suggestions or ideas on how this could be tackled. One way would probably just to add

Re: Finding library procedures in /usr/local/lib/

2009-04-03 Thread Jan Engelhardt
On Thursday 2009-04-02 23:45, Gerald I. Evenden wrote: After trying so many options related to libraries I am exhausted. I have a simple program that needs to link with a shared library installed in /usr/local/lib. When using my own simple Makefile and simply adding -lproject -lm everything

mingw compiler on cygwin, and path issues

2009-04-10 Thread Jan Engelhardt
Hi, I am currently using automake in a Windows-related project; there is a (pure) mingw compiler in c:\mingw, and cygwin is installed in c:\cygwin. Now I noticed that Makefile.in, as generated by automake, has a CYGPATH_W variable which is `echo` on Unices, and `cygpath -w` on Cygwin. The

Re: mingw compiler on cygwin, and path issues

2009-04-10 Thread Jan Engelhardt
On Friday 2009-04-10 22:19, Jan Engelhardt wrote: AM_CFLAGS = -I${abs_top_builddir}/subproject AM_LDFLAGS = -L${abs_top_builddir}/subproject This gets expanded into -I/home/User/project/subproject, but the mingw compiler of course tries to search in C:\home\user\project\subproject instead of c

Re: silent build rules

2009-04-14 Thread Jan Engelhardt
On Tuesday 2009-04-14 08:09, Ralf Wildenhues wrote: Here's why: [...] Yet another way out: remove per-Makefile.am `AUTOMAKE_OPTIONS = silent-rules' as well as `automake --silent-rules' so that the only way to specify them is as option listed in AM_INIT_AUTOMAKE. This may be inconvenient for

Re: 32-bit/64-bit builds on Solaris

2009-04-18 Thread Jan Engelhardt
On Saturday 2009-04-18 19:21, Monty Taylor wrote: Solaris on Sparc supports both 32 and 64 bit binaries, with builds defaulting to 32-bit. (Thanks backwards compatibility for proprietary software!) On SPARC, choosing 32-bit is an architectural decision rather than a software or political one.

Re: DESTDIR vs `make install exec_prefix='

2009-04-18 Thread Jan Engelhardt
On Saturday 2009-04-18 22:06, Russ Allbery wrote: Russ Allbery r...@stanford.edu writes: Ralf Wildenhues ralf.wildenh...@gmx.de writes: [1] I'm asking because Automake 1.11 will reliably not install files if their respective installation directory is empty. This is not yet functional in

Re: DESTDIR vs `make install exec_prefix='

2009-04-18 Thread Jan Engelhardt
On Saturday 2009-04-18 22:45, John Calcote wrote: Oh, you mean if the value of the *variable* is empty (following the thread), not the directory itself. D'oh, sorry, that should have been obvious to me from context. Never mind. :) No, I also thought of empty directories. Quote from

Re: Automatic debug symbol generation

2009-04-22 Thread Jan Engelhardt
On Wednesday 2009-04-22 07:33, Ralf Wildenhues wrote: * JRS wrote on Wed, Apr 22, 2009 at 07:02:55AM CEST: I was setting up build infrastructure once again when it occurred to me, hmm, wouldn't it be nice if automake had default targets for installing symbols? For example, make install-syms

Re: Create a custom target

2009-04-23 Thread Jan Engelhardt
On Thursday 2009-04-23 04:54, automake wrote: Hi I have a similar problem with giving a customized target. I have included target into Makefile.am as extra: ...nm ...link But the default target for makefiles from configure.ac is all. Is there a way to add this target to all

Re: Automatic debug symbol generation

2009-04-23 Thread Jan Engelhardt
On Thursday 2009-04-23 14:51, Bob Rossi wrote: What's the advantage over just installing binaries into $(bindir) without stripping them? **Non-brain-damaged** systems won't load them from the file anyway for normal execution. [emphasis added by me] On mingw/msys the executables with debug

Re: Automake 1.10b test release

2009-04-25 Thread Jan Engelhardt
On Tuesday 2009-03-31 01:21, Ralf Wildenhues wrote: I'm pleased to announce the Automake 1.10b test release. It contains a bunch of new features, and a bunch of bugfixes over previous versions, and probably a bunch of new bugs. Highlights, in no particular order: I just now tried

Re: Automake 1.10b test release

2009-04-25 Thread Jan Engelhardt
On Saturday 2009-04-25 23:19, Jan Engelhardt wrote: On Tuesday 2009-03-31 01:21, Ralf Wildenhues wrote: I'm pleased to announce the Automake 1.10b test release. It contains a bunch of new features, and a bunch of bugfixes over previous versions, and probably a bunch of new bugs. Highlights

Re: whitespaces truncated [Automake 1.10b test release]

2009-04-25 Thread Jan Engelhardt
On Tuesday 2009-03-31 01:21, Ralf Wildenhues wrote: I'm pleased to announce the Automake 1.10b test release. It contains a bunch of new features, and a bunch of bugfixes over previous versions, and probably a bunch of new bugs. Highlights, in no particular order: [...] As silent-rules stand

Re: whitespaces truncated [Automake 1.10b test release]

2009-04-28 Thread Jan Engelhardt
On Monday 2009-04-27 22:27, Ralf Wildenhues wrote: CXXbar.o CXXLD prog $ grep CXX_0 Makefile.in am__v_CXX_0 = @echo CXX$@; Thanks for the bug report. Fixed with the patch below. I also had a look at the automake source, and I rather find this the problem (in

[patch] restore original spacing width for verbose mode

2009-04-30 Thread Jan Engelhardt
Output seems crushed, so restore the original behavior. --- automake.in |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: automake/automake.in === --- automake.orig/automake.in +++ automake/automake.in @@ -1199,7

Re: [patch] restore original spacing width for verbose mode

2009-05-01 Thread Jan Engelhardt
On Friday 2009-05-01 09:57, Ralf Wildenhues wrote: Hi Jan, * Jan Engelhardt wrote on Thu, Apr 30, 2009 at 09:05:07PM CEST: Output seems crushed, so restore the original behavior. Can you explain this, please? The original submission I did around October 2008 followed the Linux-style output

Re: Setting shared lib version not functioning

2009-05-03 Thread Jan Engelhardt
On Sunday 2009-05-03 17:41, Gerald I. Evenden wrote: libproject_la_LDFLAGS = -version-info 2:0:1 which worked fine when with previous loading of a library with 2:0:0 versioning code. But now, when I go through the autoreconf, configure, compile and install I get: libproject.so.1.1.0 Which

Re: Setting shared lib version not functioning

2009-05-03 Thread Jan Engelhardt
On Sunday 2009-05-03 18:58, John Calcote wrote: It appears that Libtool is smart enough to detect ridiculous cases, but it should probably throw an error of some sort, rather than simply generate code with a different version number. Since libtool is just a linker as far as is considered here,

Re: Setting shared lib version not functioning

2009-05-03 Thread Jan Engelhardt
On Sunday 2009-05-03 20:40, Gerald I. Evenden wrote: What I did to the library was add several procedures That in itself would cause a bump in the 'current' number to 3. but the original functions were not changed nor affected. So 'age' becomes 1, since you are still supporting (3-1) = 2.

Re: Effects of some references to other libraries in a shared library

2009-05-03 Thread Jan Engelhardt
On Sunday 2009-05-03 23:32, Gerald I. Evenden wrote: In a shared library there are about 8 routines out over 100 that refer to libgsl and libpthread. A frequent situation may arise where an application program has no need for using the 8 procedures infected with other library needs. At the

Re: Effects of some references to other libraries in a shared library

2009-05-04 Thread Jan Engelhardt
On Monday 2009-05-04 08:06, John Calcote wrote: On 5/3/2009 3:32 PM, Gerald I. Evenden wrote: In a shared library there are about 8 routines out over 100 that refer to libgsl and libpthread. A frequent situation may arise where an application program has no need for using the 8 procedures

Re: rebuilding following a change in prefix?

2009-05-07 Thread Jan Engelhardt
On Friday 2009-05-08 06:23, Adam Mercer wrote: I have noticed some strange behaviour with the build system on a project I am working on, consider the following: $ ./configure --prefix=/path/1 $ make $ make install $ ./configure --prefix=/path/2 $ make $ make install I would expect the make

Re: cross-compiling on 64 to 32-bit Linux

2009-05-23 Thread Jan Engelhardt
On Saturday 2009-05-23 20:49, John Calcote wrote: Hi everyone, I was wondering what the procedure was for cross-compiling 32-bit apps on a 64-bin Linux system? Do you need special libraries. What command-line options are used? That sort of thing. I'm happy to read up on it, if there are

Re: cross-compiling on 64 to 32-bit Linux

2009-05-24 Thread Jan Engelhardt
On Sunday 2009-05-24 16:25, Andreas Schwab wrote: Bruno Haible br...@clisp.org writes: - The -m64 flag is the default on bi-arch Linux systems. This is wrong. - The -m32 flag has to be passed as part of both CC / CXX and LDFLAGS. That should not be necessaray, since any command that

Re: using C# in automake

2009-05-24 Thread Jan Engelhardt
On Sunday 2009-05-24 19:35, Bob Friesenhahn wrote: On Sun, 24 May 2009, Andreas Otto wrote: I want to create an language binding for a C libraray this mean I have as input an file called csmsgque.cs and get as output an csmsgque.dll on unix It seems like what is needed is C#

Re: makes which break with `silent-rules'

2009-05-27 Thread Jan Engelhardt
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

Non-recursive automake

2009-10-17 Thread Jan Engelhardt
Hi, when one decides to drive make in a non-recursive fashion, one has to write an Automake file like this: lib_LTLIBRARIES = foo/bar.la foo_bar_la_SOURCES = foo/one.c foo/two.c Usually I stuff that into a file called foo/Automakefile and include foo/Automakefile from the real Makefile.am.

Add missing bootstrap file

2009-11-08 Thread Jan Engelhardt
Hi, in the automake tarballs, the 'bootstrap' script is missing, but it would be needed when modifying any of the automake files in a tarball. In other words, when used in an rpm build script: Source: automake-1.11.tar.bz2 Patch1: foobar.diff modifying m4/init.m4 Not running bootstrap after

Re: Add missing bootstrap file

2009-11-14 Thread Jan Engelhardt
On Saturday 2009-11-14 14:06, Ralf Wildenhues wrote: Hi Jan, * Jan Engelhardt wrote on Mon, Nov 09, 2009 at 02:09:14AM CET: in the automake tarballs, the 'bootstrap' script is missing, but it would be needed when modifying any of the automake files in a tarball. Sounds reasonable to me

Re: Add missing bootstrap file

2009-11-15 Thread Jan Engelhardt
[Note that this has nothing to do with the bootstrap file] On Sunday 2009-11-15 17:44, Alfred M. Szmidt wrote: Index: automake/m4/init.m4 === --- automake.orig/m4/init.m4 +++ automake/m4/init.m4 @@ -107,6 +107,7 @@

ylwrap - flex filename weirdness

2010-10-31 Thread Jan Engelhardt
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,

Re: ylwrap - flex filename weirdness

2010-10-31 Thread Jan Engelhardt
On Sunday 2010-10-31 16:42, Philip Herron wrote: 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

What is it with the dependency on config.status

2011-12-30 Thread Jan Engelhardt
I have seen user-induced lines in Makefile.am like these in a handful of packages: ${pkgconfig_DATA}: ${top_builddir}/config.status Given that automake 1.11.1/autoconf 2.68 seem to automatically recreate files specified in AC_CONFIG_FILES when configure.ac is changed, what is the

Re: What is it with the dependency on config.status

2012-01-09 Thread Jan Engelhardt
On Sunday 2012-01-01 10:24, Stefano Lattarini wrote: On 12/31/2011 12:29 AM, Jan Engelhardt wrote: I have seen user-induced lines in Makefile.am like these in a handful of packages: Which packages? I need more information if I am to attempt an informed guess ... ${pkgconfig_DATA

The case of libkmod's .so versioning attempts, and induced collisions

2012-02-06 Thread Jan Engelhardt
Much to my disappointment, I found that the newly-released libkmod v5 has made the following non-trivial change to its source tree, the latter of which I want to bring to attention: commit e479598b7d19ae7be45bf5329d6e4df32d646c16 diff --git a/Makefile.am b/Makefile.am

Do fail when regeneration of Makefile.in does not succeed

2012-11-14 Thread Jan Engelhardt
Hi, Is there an option to yield an error instead of a warning if Makefile.in needs to be regenerated, but can't? The case before me is that iptables's Makefile.am in openSUSE is patched after tarball extraction. But, due to 1. $PEBKAC not calling autoreconf, 2. the system having automake-1.12

Error running help2man on aclocal-1.13.1

2013-01-09 Thread Jan Engelhardt
The help2man: can't get `--help' info from ./aclocal error seems to have reappeared in automake-1.13.1 (judging from http://gnu-automake.7480.n7.nabble.com/Man-pages-for-automake-and-aclocal-td11966.html) help2man is of version 1.40.12. --- Executing(%build): /bin/sh -e

Re: Error running help2man on aclocal-1.13.1

2013-01-09 Thread Jan Engelhardt
On Wednesday 2013-01-09 19:11, Stefano Lattarini wrote: On 01/09/2013 05:05 PM, Jan Engelhardt wrote: The help2man: can't get `--help' info from ./aclocal error seems to have reappeared in automake-1.13.1 (judging from http://gnu-automake.7480.n7.nabble.com/Man-pages-for-automake

Re: Error running help2man on aclocal-1.13.1

2013-01-09 Thread Jan Engelhardt
On Wednesday 2013-01-09 22:27, Stefano Lattarini wrote: Now I just have to figure out why someone thought that openSUSE should create the manpages directly... Good question What happens if you do this instead? help2man -S FSF ./t/wrap/aclocal-1.13 output.1 Does this fix your problem?

Automake should flag -l parameters in LDFLAGS

2013-03-30 Thread Jan Engelhardt
Given a Makefile.am with myprog_LDADD = -pthread automake will correctly output this warning Makefile.am:17: error: linker flags such as '-pthread' belong in 'myprog_LDFLAGS' It would be nice to also have automake report -l flags in LDFLAGS that actually belong into

${OBJEXT} in implicit rule

2014-11-12 Thread Jan Engelhardt
Using automake-1.13.4, when using the following Makefile.am fragment, ---8--- bin_PROGRAMS = foo foo_SOURCES = foo.c bar.k .k.${OBJEXT}: gcc -x c -c $ -o $@ ---8--- I observe that bar.o is not built and not linked into foo. ---8--- make V=0 CC foo.o CCLD foo

Re: ${OBJEXT} in implicit rule

2014-11-12 Thread Jan Engelhardt
On Wednesday 2014-11-12 20:15, Nick Bowler wrote: On 2014-11-12 16:58 +0100, Jan Engelhardt wrote: Using automake-1.13.4, when using the following Makefile.am fragment, .k.${OBJEXT}: gcc -x c -c $ -o $@ I observe that bar.o is not built and not linked into foo. Indeed, the use

[PATCH] automake: add install dep on install-libLTLIBRARIES to all targets

2021-08-29 Thread Jan Engelhardt
-libLTLIBRARIES therefore potentially breaking `make install -j`. Rectify this by depending on install-libLTLIBRARIES not just for bin_PROGRAMS, but all PROGRAMS and LTLIBRARIES. Signed-off-by: Jan Engelhardt --- bin/automake.in | 23 +-- 1 file changed, 17 insertions(+), 6

  1   2   >