bug#32074: maintainer-clean and removing configure/Makefile.in/etc.

Mathieu Lirzin writes: > Jack Kelly writes: > >> It is certainly valuable to test that you can bootstrap your package >> from autoreconf up, but I don't think `make maintainer-clean' is the >> best place to do that. The `git-clean' command removes untrac

bug#32074: maintainer-clean and removing configure/Makefile.in/etc.

Karl Berry writes: > [snip automake manual blockquote] > > But nowadays, especially since autoreconf exists, it does not seem > unreasonable to me to want to delete Makefile.in, configure, etc. It > is just as easy to run autoreconf (or equivalent) as configure&&make, > and it feels nice to have

bug#13588: Pax hangs in case big UID

13588 > > * m4/tar.m4: check for ustar V7 archive format. Maximum value for user > or group ID > is limited to 2097151. Thanks to Jack Kelly for patch corrections > --- > m4/tar.m4 | 22 ++ > 1 file changed, 22 insertions(+) > > diff --git a/m

bug#13588: Pax hangs in case big UID

Hi Petr, I have a couple of observations: - AC_MSG_ERROR is going to stop the configure anyway, so you don't need exit 1. - I'd suggest the following messages for your AC_MSG_ERRORS: "the uid is too large for ustar-format tarfiles. Change format in configure.ac" "the gid is too large fo

bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

Diego Elio Pettenò writes: > On 31/01/2013 20:58, Jack Kelly wrote: >> IMHO, that seems like a great way to cause trouble for unsuspecting >> users. (Anyone remember KDE4.0?) Can you expand on why you think it's a >> good plan? > > Because unlike KDE, automake

bug#13170: automake and pyconfigure: a future integration?

Kerrick Staley writes: > Really, I'd just like to get gobject-introspection to compile on Arch Linux. > The problem is that gobject-introspection's configure.ac has the line > > AM_PATH_PYTHON([2.5]) > > but gobject-introspection can't actually work with Python 3 or higher (the > default on Arch)

bug#12620: Parallel tests vs fast tests (and beyond)

On Thu, Oct 11, 2012 at 6:53 AM, Reuben Thomas wrote: > This whole problem is an instance of a more general problem, of which > another example is parallel make: for best performance, it should > probably batch up calls to gcc, for example, so that multiple source > files are compiled by each invo

bug#12142: automake tries to compile a program when 'foo' and 'foo.cxx' exist (though the former is header)

On Mon, Aug 6, 2012 at 5:38 PM, Stefano Lattarini wrote: > On 08/05/2012 11:45 AM, Michał Górny wrote: >> My library was structured like the following: >> >> - src/foo (the header file), >> > Why not simply using a more usual name like 'foo.h' for 'foo.hxx'? > That would be unlikely to trigger une

bug#12058: AM_PATH_SDL does not find SDL framework installations on Mac OSX

On Fri, Jul 27, 2012 at 4:38 AM, Stefano Lattarini wrote: > IMNSHO that choice of a name it is a serious mistake by whoever is > defining/distributing that macro, for two reasons: > > 1. it gives the wrong impression that the macro is provided > by or related to Automake -- not true. > >

bug#11806: (setq load-path ..) of elisp-comp

On Fri, Jul 6, 2012 at 7:57 AM, Stefano Lattarini wrote: > Usually I'd agree, and in fact I had done as you're suggesting in a > previous attempt; but that caused the test 'lisp3.sh' to fail :-/ > With the patch I've posted, the testsuite remains clean at least. > > So I say we commit my patch: al

bug#11806: (setq load-path ..) of elisp-comp

On Sat, Jun 30, 2012 at 11:19 AM, Makoto Fujiwara wrote: > With your advice for VPATH issue, I am now using attached patch, > thanks a lot, > --- lib/elisp-comp.orig 2012-01-31 20:41:18.0 +0900 > +++ lib/elisp-comp 2012-04-13 22:14:39.0 +0900 > @@ -62,6 +62,7 @@ > fi > > tem

bug#11806: (setq load-path ..) of elisp-comp

On Thu, Jun 28, 2012 at 8:49 PM, Stefano Lattarini wrote: > On 06/28/2012 06:47 AM, Makoto Fujiwara wrote: >> I do have problem compiling *.el files with tc-2.3.1 (svn version) I think this is the relevant Makefile.am: http://code.google.com/p/tcode/source/browse/trunk/tc/lisp/Makefile.am It con

bug#11356: automake 1.12 and (C) 2011

On Fri, Apr 27, 2012 at 10:05 PM, Eric Blake wrote: > On 04/27/2012 03:18 AM, Stefano Lattarini wrote: >> On 04/27/2012 05:30 AM, Peter Johansson wrote: >> +++ b/aclocal.in >> @@ -840,9 +840,8 @@ $output"; >>    # name in the header. >>    $output = "# generated automatically by aclocal $VERSION -

bug#10226: Drop redundant Python 1.5 support?

On Tue, Dec 6, 2011 at 9:42 AM, Reuben Thomas wrote: > Reading python.m4, I notice that it claims to support only Python >= > 2.0, yet still has specific support for Python 1.5. Would a patch > along the following lines therefore be accepted? (If so I'll write the > changelog entry &c.!) The patc

bug#9088: Java support

On Sat, Jul 16, 2011 at 9:55 AM, tsuna wrote: > On Fri, Jul 15, 2011 at 1:58 AM, Stefano Lattarini > wrote: >> As my java foo is pretty weak, I'm not sure how to handle jar manifests, >> jar entry points, or other jar/javac subtleties and advanced features. >> Suggestions welcome. > > You can cre

bug#8881: config.h double inclusion

On Fri, Jun 17, 2011 at 6:29 AM, Paul Eggert wrote: > On 06/16/11 10:36, Alfred M. Szmidt wrote: >> I'm thinking that maybe should be generated with a double >> inclusion guard > > But the general rule is that must always be included first, no? > So there shouldn't ever be a possibility of inclu

bug#8718: error when using nested conditionals

On Fri, Jun 10, 2011 at 6:19 PM, Stefano Lattarini wrote: > Here is my idea: 'AM_IGNORE_UNDEFINED_CONDITIONALS' can accept two > arguments, "yes" and "no" (defaulting to "yes" if no argument is given). > The idea is that an usage like: > > -snip- > > will cause the generated configure to check tha

bug#8665: automake should offer APIs to honour silent-rules verbosity from shell code in Makefiles

On Fri, May 13, 2011 at 7:30 PM, Stefano Lattarini wrote: > Hello Jack, thanks for the feedback. > > On Friday 13 May 2011, Jack Kelly wrote: >> Comments inline, after some snipping. >> >> On Fri, May 13, 2011 at 6:27 AM, Stefano Lattarini >> wrote: >> >

bug#8665: automake should offer APIs to honour silent-rules verbosity from shell code in Makefiles

Comments inline, after some snipping. On Fri, May 13, 2011 at 6:27 AM, Stefano Lattarini wrote: > -snip intro- > > I thus propose we add an API of this kind.  At first, this might be as > simple as just defining two proper `AM_V_ECHO' and `AM_Q_ECHO' variables; > `AM_V_ECHO' should be `echo' when

bug#8289: distcheck and make dvi

On Mon, Mar 21, 2011 at 8:28 AM, Karl Berry wrote: > All together, for a general fix, my suggestion is to simply replace the > hardwired "dvi" string with a new variable name, like > $(AM_DISTCHECK_DOC) or some such (no idea if that's a reasonable name, > but you get the idea), which defaults to d

bug#8289: distcheck and make dvi

On Sun, Mar 20, 2011 at 10:53 PM, Ralf Wildenhues wrote: >> Another possible change, in addition to messing with the documentation, >> would be to make the "dvi" a variable that such non-dvi-generating >> people can override with "pdf" if they wish.  Then they could get the >> benefit of the check

bug#8111: after adding a(nother) subconfigure, rerunning make fails

On Fri, Feb 25, 2011 at 6:36 AM, Ralf Wildenhues wrote: > Can we fix this somehow in either Autoconf or Automake? Could we save the results of tracing AC_CONFIG_SUBDIRS calls? If there's a change, invoke ./config.status --recheck. If not, config.status --recheck --no-recursion. -- Jack

bug#8104: automake suggests use of AC_PROG_LIBTOOL, this has been replaced by LT_INIT

Version: 1.11.1 (ubuntu 10.10). I have inspected the most recent master and it appears to also have this bug. configure.ac: AC_INIT([a], [b], [c]) AM_INIT_AUTOMAKE([foreign]) dnl no LT_INIT -- on purpose AC_PROG_CC AC_CONFIG_FILES([Makefile]) AC_OUTPUT Makefile.am: lib_LTLIBRARIES = libfoo.la Ru

bug#8044: Automake should support autotest-based testsuites.

On Wed, Feb 16, 2011 at 4:39 AM, Stefano Lattarini wrote: > The steps required to set up an autotest-based testsuite are already > excellently described in the autoconf manual: >   > and seem pretty mechanical, so

bug#7944: Should AM_PATH_PYTHON call AC_ARG_VAR?

On Tue, Feb 1, 2011 at 7:31 AM, Stefano Lattarini wrote: > On Monday 31 January 2011, Jack Kelly wrote: >> I've noticed that if you put AM_PATH_PYTHON in configure.ac, it >> doesn't add an entry for PYTHON in ./configure --help. Is PYTHON meant >> to be a user

bug#7944: Should AM_PATH_PYTHON call AC_ARG_VAR?

Hi automakers, I've noticed that if you put AM_PATH_PYTHON in configure.ac, it doesn't add an entry for PYTHON in ./configure --help. Is PYTHON meant to be a user's variable? Minimal configure.ac: AC_INIT AM_PATH_PYTHON AC_OUTPUT -- Jack

bug#7945: Is AM_PATH_PYTHON missing some versions in _AM_PYTHON_INTERPRETER_LIST?

(automake-1.11.1, ubuntu 10.10 package) Hi automakers, While poking around python.m4, I noticed that python2.6 and python2.7 are not mentioned in the list of python interpreters defined in _AM_PYTHON_INTERPRETER_LIST. Is this intentional? -- Jack

bug#7621: add a way to pass link dependencies

On Sat, Jan 22, 2011 at 11:16 PM, Bruno Haible wrote: > For (A), the list of options to be ignored during dependency extraction is the > following (cf. gnulib/build-aux/config.rpath): >  -rpath /some/path >  -Wl,-rpath -Wl,/some/path >  -Wl,-rpath,/some/path >  -lopt=-rpath -lopt=/some/path >  -Qo

bug#7655: conditional _TEXINFOS should be supported

On Fri, Dec 17, 2010 at 7:02 AM, Ralf Wildenhues wrote: > [ no need to keep bug-automake@ in Cc:; debbugs takes care of that ] Noted. > * Jack Kelly wrote on Thu, Dec 16, 2010 at 08:42:52PM CET: >> > Disagree. foo.info should always be built, because it goes into `make >&g

bug#7655: conditional _TEXINFOS should be supported

On Fri, Dec 17, 2010 at 6:09 AM, Ralf Wildenhues wrote: > if COND > info_TEXINFOS = foo.texi > foo_TEXINFOS = bar.texi > nodist_info_TEXINFOS = generated.texi > endif > > should work to generate and install foo.{info,pdf,...} only if COND, > but distribute foo.texi and bar.texi always.  Similar wi

bug#7655: conditional _TEXINFOS should be supported

On Fri, Dec 17, 2010 at 6:41 AM, Jack Kelly wrote: > On Fri, Dec 17, 2010 at 6:09 AM, Ralf Wildenhues > wrote: >> if COND >> info_TEXINFOS = foo.texi >> foo_TEXINFOS = bar.texi >> nodist_info_TEXINFOS = generated.texi >> endif >> >> should work to

Re: need to set ACLOCAL_AMFLAGS along with AC_CONFIG_MACRO_DIR

On Thu, Sep 16, 2010 at 6:11 AM, Eric Blake wrote: > On 09/15/2010 12:59 PM, Ralf Wildenhues wrote: >> * Eric Blake wrote on Wed, Sep 15, 2010 at 04:15:13PM CEST: >>> >>> On 09/15/2010 04:37 AM, langdead wrote: Whether does "ACLOCAL_AMFLAGS= -I @path" only work for "Makefile.am"? >>> >>>

Re: aclocal directory not found error

On Thu, Jul 29, 2010 at 4:26 PM, Mike Frysinger wrote: > one example where ive hit this is with projects using git: >  - initial clone is done >  - local libtool is configured with AC_CONFIG_MACRO_DIR(m4) like it suggests >  - m4/ only contains generated files, and those arent in git, and git does

Re: Feature request: per-file compilation flags

On Wed, Mar 31, 2010 at 9:04 AM, Manoj Rajagopalan wrote: >   A typical use case for me is when one particular function that resides in a > file by itself must be compiled without optimizations so that some > machine-specific numerical information can be calculated accurately. With C++ > the volat

Re: convenience library dependencies (was: 1.11 doesn't add sources with nonstandard suffixes when making a binary)

2009/12/2 Юрий Пухальский : > Aye, that was what i thought. Jack misled me:) Sorry. I must've got mixed up and thought you were building _PROGRAMS and not _LIBRARIES. I've used noinst_LIBRARIES before when building a program. -- Jack

Re: 1.11 doesn't add sources with nonstandard suffixes when making a binary

2009/11/28 Юрий Пухальский : > -snip- >> >> My bad. I meant noinst_LIBRARIES, so you make a libcommon.a instead of >> libcommon.la. This goes into LDADD as with libtool convenience >> libraries. > I haven't checked it, but does it support library dependencies like > .la? This i use extensively. Ye

Re: 1.11 doesn't add sources with nonstandard suffixes when making a binary

Hi Ralf, 2009/11/28 Ralf Wildenhues : > That's why you should do it like this: > > .pc.$(OBJEXT): >        ... I'm confused. Why is this better than writing a .pc.c rule? Doesn't it sacrifice proper dependency tracking on the generated .c file? -- Jack

Re: 1.11 doesn't add sources with nonstandard suffixes when making a binary

2009/11/28 Юрий Пухальский : > On Fri, Nov 27, 2009 at 4:07 PM, Jack Kelly wrote: >> 2009/11/27 Юрий Пухальский : >>> Automake links binaries through libtool too, at least in my case. >> >>> -make output--- >>> /oracle/10.2.0.4/bin/proc COD

Re: 1.11 doesn't add sources with nonstandard suffixes when making a binary

2009/11/27 Юрий Пухальский : > Automake links binaries through libtool too, at least in my case. > -make output--- > /oracle/10.2.0.4/bin/proc CODE=ANSI_C include=../../include > include=/oracle/10.2.0.4/lib include=/usr/include ireclen=4800 > oreclen=4800 select_error=no release_cursor=no

Re: 1.11 doesn't add sources with nonstandard suffixes when making a binary

2009/11/25 Юрий Пухальский : > Good day! > > As of automake 1.11 the following problem exists: > I have a nonstandard suffix .pc (ProC source), which i compile into .lo with > SUFFIXES = .pc > .pc.lo: >        $(PCC) $(PCCFLAGS) iname=$(srcdir)/$*.pc oname=$(builddir)/$*.c >        $(LIBTOOL) --tag

Re: Remove dependency on gunzip

On Fri, Oct 30, 2009 at 5:43 PM, Ralf Wildenhues wrote: > OTOH, wasn't it likely for some of the compressions that only the > decompressor is installed, due to them being separate packages with > separate licenses or so? Maybe you're thinking of compress? http://en.wikipedia.org/wiki/Compress say

Re: AM_SILENT_RULES doesn't silence texinfo rules

>From ae772ea28436cb0c49a423b541d6b51f3e907cc9 Mon Sep 17 00:00:00 2001 From: Jack Kelly Date: Tue, 22 Sep 2009 12:24:04 +1000 Subject: [PATCH] Add silent rules support for dvips, makeinfo, makeinfo --html, texi2dvi and texi2pdf. --- ChangeLog | 16 automake.in

Re: Feature Request: Improved cross-directory builds (intermediate files)

On Tue, Sep 15, 2009 at 1:33 AM, Bollinger, John C wrote: > That would also help in the case where one or more $(DEPDIR)s is accidentally > or cluelessly deleted -- the developer would not have to re-run configure > (not an > obvious solution) to fix the project directory. Do you have to re-run

Re: Feature Request: Improved cross-directory builds (intermediate files)

On Sat, Sep 12, 2009 at 5:09 AM, Bollinger, John C wrote: > Hi, > > So color me embarrassed:  the ‘subdir-objects’ Automake option appears to do > what I want, more or less(*).  Inasmuch as it is particularly relevant > there, perhaps a mention of it could be added to section 7.3 of the manual? >

Re: compile wrapper script with C++ file

On Fri, Sep 4, 2009 at 10:27 PM, Eric Blake wrote: >> I'm not sure whether this is something I'm doing wrong or something wrong >> with automake, autoconf or libtool.  At the moment I'm leaning to autoconf + >> automake. > > compile is maintained by automake, so I've redirected your patch there. >

Re: AM_SILENT_RULES doesn't silence texinfo rules

On Sun, Aug 16, 2009 at 9:12 AM, Ralf Wildenhues wrote: > Hello Jack, > > * Jack Kelly wrote on Sun, Aug 16, 2009 at 12:44:57AM CEST: >> I was hoping that AM_SILENT_RULES would silence the complex makeinfo >> invocations on texinfo files, but it doesn't. I thought that

AM_SILENT_RULES doesn't silence texinfo rules

Hi List, I was hoping that AM_SILENT_RULES would silence the complex makeinfo invocations on texinfo files, but it doesn't. I thought that might've been OK, since the info files are usually generated before distribution, but `make pdf' (or ps, or dvi, or html) still have unsilenced output. I'm us

Re: texi2dvi ignores -o under unclear circumstances.

On Wed, Aug 12, 2009 at 4:29 AM, Karl Berry wrote: > Thanks for the report. >    Running texi2dvi -o doc/foo.dvi doc/foo.texi causes a copy of foo.dvi I wound up fixing this in my case by adding foo.dvi (equivalent) to CLEANFILES in Makefile.am. Perhaps automake can change the generated rules for

texi2dvi ignores -o under unclear circumstances.

Hello, I think I have found a bug with texi2dvi. It seems to manifest only when using -o to write the dvi to a subdirectory and when the .texi file has a sectioning command like @top. texi2dvi emits an identical copy of the dvi file in the current working directory. I found a similar-sounding rep

Re: AM_PROG_GCJ fails at `make' if nothing else defines OBJEXT

On Sun, Jun 7, 2009 at 4:06 PM, Ralf Wildenhues wrote: >> 2. The suffix mechanism might not be quite enough for Java projects >> with native methods using the C++ interface. > > I'm sorry, but I fail to parse this.  Even with the example you gave, it > is unclear to me.  Can you rephrase this, stat

Re: AM_PROG_GCJ fails at `make' if nothing else defines OBJEXT

On Mon, May 25, 2009 at 8:17 AM, Jack Kelly wrote: > On Mon, May 25, 2009 at 12:42 AM, Ralf Wildenhues > wrote: >> Hi Jack, >> >> * Jack Kelly wrote on Wed, May 13, 2009 at 01:24:40PM CEST: >>> I've found that if nothing else defines OBJEXT, AM_PROG_GCJ w

Re: AM_PROG_GCJ fails at `make' if nothing else defines OBJEXT

On Mon, May 25, 2009 at 12:42 AM, Ralf Wildenhues wrote: > Hi Jack, > > * Jack Kelly wrote on Wed, May 13, 2009 at 01:24:40PM CEST: >> I've found that if nothing else defines OBJEXT, AM_PROG_GCJ won't do >> it and then make will fail with an error like: >>

AM_PROG_GCJ fails at `make' if nothing else defines OBJEXT

Hi list, I've found that if nothing else defines OBJEXT, AM_PROG_GCJ won't do it and then make will fail with an error like: make: *** No rule to make target `Test.', needed by `test'. Stop. Minimal complete example (I'm using autoconf 2.63 and automake 1.10.2): configure.ac: 8<--- AC_INIT([