On Fri, 12 Jun 2009, Bruno Haible wrote:
How to solve this? Should the arguments to AM_INIT_VERSION be
1. the expression that computes the version,
2. a dependency?
An expression is most flexible and does not require use of a file
which might cause the recursion issue with the version contr
Ralf Wildenhues wrote:
> > > AM_INIT_VERSION([$$version], [version=`sh $(top_srcdir)/gen-version`])
>
> Here's a slightly different idea. The basic unit of granularity in
> makefiles is a target, or a file. The problem we're facing is that the
> version is clumped together with all other inf
Hello Ralf,
The proposed patch was meant as a prototype, not a proposed patch for
Automake. Forget about the code, and just note that it can be done with
- a new macro through which the user declares how to compute the version,
- some modifications in init.m4 and distdir.am.
> > - with a lazi
On Fri, 5 Jun 2009, William Pursell wrote:
I don't understand your use of the phrase "specially privileged".
Do you mean only those people who have access to clone the git
repository?
It could mean that. Best I can tell, there are still other viable
version control systems besides git.
Bob
Bob Friesenhahn wrote:
> Yes. Hard-coding something like `git describe` into any
> default/standard Makefile targets is the bane of free software. For
> example, if a project was to hard code it into the 'dist' target then
> only specially privileged maintainers would be allowed to do 'make
> di
On Fri, 5 Jun 2009, Ralf Wildenhues wrote:
Yes. It assumes the model where anyone who receives the package has the
ability to build and maintain it similar to the original maintainer.
But whether the file is distributed in a package tarball or not is
independent of whether the file is put int
Hi Bob,
* Bob Friesenhahn wrote on Fri, Jun 05, 2009 at 06:54:16PM CEST:
> On Fri, 5 Jun 2009, Peter Johansson wrote:
>> Bob Friesenhahn wrote:
>>> Doesn't any approach which depends on an automatically generated file
>>> assure that the version control system is one step out of date? Every
>>>
On Fri, 5 Jun 2009, Peter Johansson wrote:
Bob Friesenhahn wrote:
Doesn't any approach which depends on an automatically generated file
assure that the version control system is one step out of date? Every time
you do a 'commit' the version file is one step newer and therefore needs to
be com
Hi Bob,
Bob Friesenhahn wrote:
Doesn't any approach which depends on an automatically generated file
assure that the version control system is one step out of date? Every
time you do a 'commit' the version file is one step newer and
therefore needs to be committed.
Your analysis seems to a
On Thu, 4 Jun 2009, Ralf Wildenhues wrote:
You could then experiment with suitable rules to keep the file up to
date, depending on the VCS. VCS hooks could ensure to update (or
remove, or otherwise outdate) the file. All rules that need the version
can just depend upon the file, and read from
Hi Ralf,
Ralf Wildenhues wrote:
You could then experiment with suitable rules to keep the file up to
date, depending on the VCS. VCS hooks could ensure to update (or
remove, or otherwise outdate) the file. All rules that need the version
can just depend upon the file, and read from it afterwar
Hi Bruno,
> * Bruno Haible wrote on Sun, May 31, 2009 at 12:50:13PM CEST:
> > - with a lazily computed version number (this is for projects where the
> > version
> > changes several times a day):
> >
> > AM_INIT_VERSION([$$version], [version=`sh $(top_srcdir)/gen-version`])
Here's a sligh
Hello Bruno,
* Bruno Haible wrote on Sun, May 31, 2009 at 12:50:13PM CEST:
> Ralf Wildenhues wrote:
> > I have been playing with the idea of having two separate version strings.
> > ...
> > smells of the developer working around limitations of the tools, rather
> > than the tools providing adequat
Ralf Wildenhues wrote:
> I have been playing with the idea of having two separate version strings.
> ...
> smells of the developer working around limitations of the tools, rather
> than the tools providing adequate functionality
Yes, exactly.
This approach of two pieces is useful for the PACKAGE
Hi Bruno,
thanks for the good writeup!
* Bruno Haible wrote on Sun, May 24, 2009 at 03:15:47AM CEST:
> It has been mentioned in a discussion [1][2][3]
> "In the medium to long run, Autoconf should be changed to not depend
>at autoconf run time upon a volatile version string."
> and
> "the
Joseph S. Myers wrote:
> GCC, Binutils, GDB and EGLIBC support configure options --with-pkgversion
> and --with-bugurl. --with-pkgversion changes the package name used in
> --version output (and in manuals), so you get e.g.
>
> GNU assembler (GNU Binutils for Ubuntu) 2.19.1
>
> rather than
>
Another variation on computed versions is also worth mentioning:
GCC, Binutils, GDB and EGLIBC support configure options --with-pkgversion
and --with-bugurl. --with-pkgversion changes the package name used in
--version output (and in manuals), so you get e.g.
GNU assembler (GNU Binutils for Ub
Since I posted about this issue last week, and since GraphicsMagick
has been using a version.sh script with computed version numbers since
late 2002, you can be sure that there is strong support from me for
this proposal. Thanks for describing the issues so succinctly.
Version number and pack
Hint: ALL my packages derive the version number at
configure time by reading an external file, e.g.
VERSION, xxxrpm.spec or the version repository. Everything
else is being hacked around whatever new pecularities
some autoconf/automake release may have. Whatever lifts
the requirement on hacking is
Hi all,
It has been mentioned in a discussion [1][2][3]
"In the medium to long run, Autoconf should be changed to not depend
at autoconf run time upon a volatile version string."
and
"the goal is that the version string should _not_ appear in
config.h, so there should be _no_ configure o
20 matches
Mail list logo
