This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] patch libffi autoconversion

On Wed, 2004-03-10 at 11:23, Joseph S. Myers wrote:
> On Wed, 10 Mar 2004, andreas tobler wrote:
> > >>>+AC_INIT([libffi], [3.5], [])
> > >>
> > >>Isn't zero-argument AC_INIT the preferred form now?
> > > 
> > > No, the >3 arguments AC_INIT is the preferred form with autoconf-2.5x.
> > > 
> > > You might be mixing it up with AM_INIT_AUTOMAKE, which now prefers the 0
> > > or 1-argument form.
> > 
> > Then I keep the above try?

What I said above was from the perspective of the auto*tools.

The zero-args form is more or less deprecated (I am not sure if it has
officially been announced to be deprecated) and (AFAIK intentionally) is
undocumented (cf. AC_INIT in; only the 3-4 args form is

The single-args form definitely is obsolete.

> You don't hardcode the GCC version number anywhere beyond gcc/version.c
> and gcc/doc/include/gcc-common.texi.  There are far too many manual
> release management steps as is. Ideally we'd only have the version number
> and release status in gcc-common.texi and put those in a generated C file
> at configuration or build time, combining those with an automatically
> updated date to get the version string, so avoiding the need to change
> version.c when the version number changes.

You could do the converse: provide the version number from inside of the
configure script and AC_SUBST it or propagate it through config-headers,
or apply sed-magic in Makefile to regenerate version.c


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]