On 2008-08-27, Michel Briand <[EMAIL PROTECTED]> wrote:
> Last, but not the least: autotools documentation that can be found on
> the web seems to obsoletes rapidly. There is the famous autobook that's
> not maintained anymore [1] and some info2www documentation [2], [3].
You've missed probably th
On 2008-06-06, Erik de Castro Lopo <[EMAIL PROTECTED]> wrote:
> Ralf Wildenhues wrote:
>
>> amtest_SOURCES = cpp.cc amtest.c amtest.h
>
> Ah, that fixed that problem. The test project now works as it should.
>
> Getting back to real project I managed to fix that as well, but I
> not sure what I was
On Wed, Nov 28, 2007 at 07:15:10PM +0100, Ralf Wildenhues wrote:
> elc-stamp: $(elc_stamp_SOURCES)
> @rm -f [EMAIL PROTECTED]
> @touch [EMAIL PROTECTED]
> $(elc_stamp_COMMAND)
> @mv -f [EMAIL PROTECTED] $@
Hmm, what's the reason for "rm -f" before "touch" here?
Cheers,
On Mon, Dec 10, 2007 at 09:15:26AM +0100, Ralf Wildenhues wrote:
> * Olly Betts wrote on Sun, Dec 09, 2007 at 03:53:11AM CET:
> > On Wed, Nov 28, 2007 at 07:15:10PM +0100, Ralf Wildenhues wrote:
> > > That would drive us
> > > further away from being able to copy the c
On Wed, Nov 28, 2007 at 07:15:10PM +0100, Ralf Wildenhues wrote:
> * Olly Betts wrote on Tue, Nov 27, 2007 at 01:30:31AM CET:
> > I don't have a concrete proposal, but it seems that this would need
> > to be controllable rather than automatically adjusting any rule with
>
On 2007-11-27, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Nov 2007, Olly Betts wrote:
>> My experience is that multi-output rules often aren't protected at all,
>> and parallel make is unreliable on such projects. This is becoming much
>> more of an i
On 2007-11-27, Stepan Kasal <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 27, 2007 at 12:30:31AM +0000, Olly Betts wrote:
>> data.c data.h::: data.foo
>> foo data.foo
>
> But this looks like too much magic for a feature which is not used
> that much.
My e
I've read (and use the recipes from) the automake manual section
"Handling Tools that Produce Many Outputs". However, these recipes
require a lot of boilerplate code which annoyingly obscures the actual
rule they are protecting - a two line rule is swamped by a dozen lines of
boilerplate.
It's ju
On Wed, May 24, 2006 at 01:57:15PM +0200, Ralf Wildenhues wrote:
> * Olly Betts wrote on Wed, May 24, 2006 at 12:24:53PM CEST:
> > * Generally, it would be useful for the manual to go into a bit more
> > detail about how to approach all this.
>
> Agreed. I'm sure Al
I've been looking at the feasibility of converting a project (Xapian)
using autoconf+automake+libtool to using non-recursive makefiles.
Currently each subdirectory produces a libtool convenience library
and these are linked into the main installable library. There are
a few convenience librarie
In message <[EMAIL PROTECTED]>, Alexandre Oliva writes:
>[linking a library from other libraries with no object files]
>
>The point is that this just can't be done portably.
Since libtool's major purpose is to allow libraries to be built using a
portable interface, perhaps it should take care of
In article <[EMAIL PROTECTED]>, Gerall Kahla wrote:
> I'm working with a program whose name begins with a numeral, and
>I'm getting an error:
>
>localhost:~/src/4dim$ automake
>Makefile.am:2: bad macro name '4dim_SOURCES'
I hit this problem a few months ago. It's an unnecessary restriction
In article <[EMAIL PROTECTED]>, Tom Tromey wrote:
>> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
>Lars> Any point in using the f flag at all in such cases?
>Lars> => $(TAR) cho $(distdir) | $(GZIP) -c > $(distdir).tar.gz
>
>I thought some versions of tar defaulted to something like /de
13 matches
Mail list logo
