Re: release schedule for 1.9? (Was: Re: automake -vs- huge projects (1st patch))
On Thu, Jan 22, 2004 at 04:54:33PM -0700, Tom Tromey wrote: > > "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. Frankly, the reason Debian is carrying so many versions is because maintainers are bloody lazy. Every transition of this form takes ages, no matter how easy it is to convert. Half the time there's nothing that needs to be done aside from actually using a newer version, and it still doesn't get done. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
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
Re: VPATH?
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: [...] adl> [*] I think this is not accurate if you limit yourself Solaris adl> or Tru64 Make. But I'm assuming you don't. if you limit yourself _to_ Solaris and Tru64 Make. -- Alexandre Duret-Lutz
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' :) The software tree compiled. > 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. We never used the dist target. > Could you give a more detailed example of what worked, when, and > how? "more places" is a bit fuzzy. A subdir that had: Makefile.am: [EMAIL PROTECTED]@:@srcdir@/../common bin_PROGRAMS= foo and no other files in it used to automatically get foo.c from srcdir/../common/foo.c, and with automake-1.8 it no longer does. I have 108 other Makefile.am's that are successfully doing this; every so often another one will break and I have to move the "path" spec from VPATH to the correct file names. This happens Rarely. > [*] I think this is not accurate if you limit yourself Solaris > or Tru64 Make. But I'm assuming you don't. This project Requires GNU make. H
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: 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: 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 - --- Begin Message --- >>> "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 ---
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 emailz
