it works better
Only Al.pha Male Plus will give men tonz of orga.sms. At last, any man can have tonz of orgasms and give his lo.ver the orgasm they need tyddafewvx ccatvupndc no more
Re: Can't run aclocal from automake 1.8
Thanks Alexandre, it works fine in Automake 1.8.2 Regards, Mark. - Mark R.Bannister, Author, Programmer, I.T. Consultant and Musician. Email: [EMAIL PROTECTED] Website: www.freedomware.co.uk - ---BeginMessage--- Freedomware == Freedomware [EMAIL PROTECTED] writes: Freedomware I've installed automake 1.8 on Sun Solaris 8, and Freedomware aclocal doesn't seem to know it's version number. Thanks for the report. This was fixed in Automake 1.8.2, released last week. -- Alexandre Duret-Lutz ---End Message---
Re: VPATH?
Harlan == Harlan Stenn [EMAIL PROTECTED] writes: Harlan So in the past we have successfully created Makefile.am's that say: Harlan [EMAIL PROTECTED]@:@srcdir@/other/dir Harlan foo_SOURCES= filefromdot filefromotherdir Harlan and with 1.8 I am seein more places where this no longer works. Harlan The documentation does not clearly state that Harlan augmenting VPATH is wrong. Harlan Is it wrong to use an augmented VPATH with automake? Right now, yes. I don't know how it could have possibly worked in the past. In fact I don't believe it ever worked, but maybe it depends on the definition we use for `to work' :) For instance `make dist' has always assumed that files are either in the current directory, or in $(srcdir). Therefore it would never distribute `filefromotherdir' [*]. I believe this apply to all Automake versions. Could you give a more detailed example of what worked, when, and how? more places is a bit fuzzy. [*] I think this is not accurate if you limit yourself Solaris or Tru64 Make. But I'm assuming you don't. -- Alexandre Duret-Lutz
Re: Feature proposal: sort file compilation order by time
David == David Sterba [EMAIL PROTECTED] writes: David Hi, David I'd like to present an idea which can make edit-compile-edit David cycle faster. David The idea is simple: compile first files which vere modified David most recently. The idea sounds sensible to me, but not the place. Wouldn't it be more useful to implement this as a make option? It seems to me that make has all the necessary information (it has to check all time stamps anyway), and that doing this here would be more generic. Assuming that Makefile is re-read after one of its included file (here Makefile.order) has changed is a GNU Make idiom anyway. [...] -- Alexandre Duret-Lutz
Re: release schedule for 1.9? (Was: Re: automake -vs- huge projects (1st patch))
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes: adl Also, since we have switched to API-numbering, bumping that adl version number has a cost. For instance Debian distributes adl automake1.4, automake1.6, automake1.7, and automake1.8. If we adl add another API, it'd better be worth it. Yeah. It turns out that Red Hat still ships 1.5 because some packages still depend on it. Sigh. Obviously this doesn't scale -- at some point it has to be so painless to upgrade that someone like Debian or Red Hat can simply ditch 1.x and convert everything to 1.x+1 all at once. adl Maybe we could release an official snapshot of HEAD? This may adl also help to better test these uncertain subdir-suffix-rules. adl Would that be enough? It might. Unfortunately I don't think we can unilaterally make a decision like this. We'll have to involve the other gcc maintainers. I think the ideal for gcc is to have the entire tree requiring a single released version of automake. But, we'll never know if we can do it until we try :-) Tom
