On Mar 30, 2001, Eric Siegerman <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 29, 2001 at 10:33:03PM -0300, Alexandre Oliva wrote:
>> On Mar 29, 2001, "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
>>
>> > AC_PACKAGE_NAME configure AC_PACKAGE_VERSION
>> > generated by GNU Autoconf AC_ACVERSION
>>
>> I lik
On Thu, Mar 29, 2001 at 10:33:03PM -0300, Alexandre Oliva wrote:
> On Mar 29, 2001, "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
>
> > AC_PACKAGE_NAME configure AC_PACKAGE_VERSION
> > generated by GNU Autoconf AC_ACVERSION
>
> I like this one. Except that the copyright notice must appear between
>
On Mar 29, 2001, "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> AC_PACKAGE_NAME configure AC_PACKAGE_VERSION
> generated by GNU Autoconf AC_ACVERSION
I like this one. Except that the copyright notice must appear between
these lines.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.b
On Thu, Mar 29, 2001 at 12:25:55PM -0500, Derek R. Price wrote:
: Peter's original suggestion seems appropriate, then:
:
: > configure (AC_PACKAGE_NAME) AC_PACKAGE_VERSION
: > generated by GNU Autoconf AC_ACVERSION
Another log on the fire :)
AC_PACKAGE_NAME configure AC_PACKAGE_VERSION
generate
"Derek R. Price" wrote:
>
> Tim Van Holder wrote:
>
> I think we're debating this only because RMS doesn't seem to have left much
> room for generated programs
Well, RMS's ol' toy bison handles this issue this way (First lines
of a bison generated *c):
>
> /* A Bison parser, made from file.yy
Peter Eisentraut wrote:
> Quoth the GCS:
>
> If you *need* to mention the version numbers of libraries which
>
> (Autoconf is sort of a library...)
>
> are distributed separately from the package which contains this
> program, you can do so by printing an additional line of version
Ivan Vlaev wrote:
> Sorry if you already discussed it but, what about having both:
> configure --version
> and
> configure --autoconf-version
>
> at least i don't expect
> any-program --version
> to dump the version of the compiler used for building it.
>
> Probably this is matter of which
Tim Van Holder wrote:
> True. But if you apply 'the program being run', then you need a seperate
> version for configure, as it is neither autoconf, nor the package,
> really.
> I guess that is what it boils down to: do we see 'configure' as a) a
> program in its own right, b) an inextricable par
Lars J. Aas writes:
> On Thu, Mar 29, 2001 at 08:29:19AM -0500, Derek R. Price wrote:
> : I also don't see a reason why it would be very useful to maintain a version
> : on a configure script separate from the pacage version. Anyone else?
>
> If you follow development sources through CVS, it can
Lars J. Aas writes:
> : I would agree, but the GNU standards are pretty clear about this. I think
> : the idea was that (e.g.)
> :
> : `any_program --version | sed -n '1s/^.* \([^ ][^ ]*\)$/\1/p'`
> :
> : should be able to return something useful with any program of a package.
>
> The GNU coding
> I must admit that this contains all the relevant information, but
> I think it violates the coding standard. The text following the last
> space and up until the EOL is supposed to be a version string for the
> _program being run_. I would hazard to say that two versions of a
> package could h
Sorry if you already discussed it but, what about having both:
configure --version
and
configure --autoconf-version
at least i don't expect
any-program --version
to dump the version of the compiler used for building it.
Probably this is matter of which version is most important, that of
co
Tim Van Holder wrote:
> GNU configure (PACKAGE VERSION) AC_VERSION
>
> After all, the relevant version number for configure itself, is that
> of the autoconf that created it; the name & version of the package
> it's intended for are useful extra information.
> And since you explicitly call it _GN
"Lars J. Aas" wrote:
> On Thu, Mar 29, 2001 at 08:29:19AM -0500, Derek R. Price wrote:
> : I also don't see a reason why it would be very useful to maintain a version
> : on a configure script separate from the pacage version. Anyone else?
>
> If you follow development sources through CVS, it ca
> I also don't see a reason why it would be very useful to maintain
> a version on a configure script separate from the pacage version.
Figure I might as well chuck in my EUR 0.02 as well: what about
GNU configure (PACKAGE VERSION) AC_VERSION
After all, the relevant version number for configur
On Thu, Mar 29, 2001 at 08:29:19AM -0500, Derek R. Price wrote:
: I also don't see a reason why it would be very useful to maintain a version
: on a configure script separate from the pacage version. Anyone else?
If you follow development sources through CVS, it can be a good idea, but
using AC
"Lars J. Aas" wrote:
> On Wed, Mar 28, 2001 at 11:29:14PM +0200, Peter Eisentraut wrote:
> : Lars J. Aas writes:
> : > : A Gnits dude would probably prefer
> : > :
> : > : configure (AC_PACKAGE_NAME) AC_PACKAGE_VERSION
> : > : generated by GNU Autoconf AC_ACVERSION
> : >
> : > Or
> : >
> : > conf
On Wed, Mar 28, 2001 at 11:29:14PM +0200, Peter Eisentraut wrote:
: Lars J. Aas writes:
: > : A Gnits dude would probably prefer
: > :
: > : configure (AC_PACKAGE_NAME) AC_PACKAGE_VERSION
: > : generated by GNU Autoconf AC_ACVERSION
: >
: > Or
: >
: > configure (AC_PACKAGE_STRING)
: > generated by
Hi everyone,
I have been updating my aclocal backpacker package, renaming it
to "aclocal-archive". Now it can create some rpm files for binary
distribution of aclocal macros for your convenience too. I would
like to have some comments on the usefulness of the aclocal-archive,
idea and I would l
19 matches
Mail list logo
