Zack Weinberg wrote:
> ...
> grumpy aside in OpenBSD's "fcntl(2)" manpage:
>
> | This interface follows the completely stupid semantics of System V
> | and IEEE Std 1003.1-1988 ("POSIX.1") that require ...
>
> As I recall, at the time, *neither* flock nor fcntl locks
> were honored *at all* over N
On 1/28/21 10:34 AM, Zack Weinberg wrote:
we could instead use the
battle-tested technique used by Emacs: symlink sentinels. (See
https://git.savannah.gnu.org/cgit/emacs.git/tree/src/filelock.c .)
Although that Emacs code is battle-tested, one of the things it does is
fall back on regular fi
On Thu, 28 Jan 2021, Nick Bowler wrote:
If I understand correctly the issue at hand is multiple concurrent
rebuild rules, from a single parallel make implementation, are each
invoking autom4te concurrently and since file locking didn't work,
they clobber each other and things go wrong.
That is
s that it *does* have something to do. It might be
Perhaps this experience is a side effect of my recent experience
(regarding AC_INIT and versioning) and not the normal case.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Main
On 2021-01-28, Zack Weinberg wrote:
> There is a potential way forward here. The *only* place in all of
> Autoconf and Automake where XFile::lock is used, is by autom4te, to
> take an exclusive lock on the entire contents of autom4te.cache.
> For this, open-file locks are overkill; we could inste
On Thu, Jan 28, 2021 at 2:16 PM Bob Friesenhahn
wrote:
> On Thu, 28 Jan 2021, Zack Weinberg wrote:
> >
> > The main reason I can think of, not to do this, is that it would make
> > the locking strategy incompatible with that used by older autom4te;
> > this could come up, for instance, if you’ve g
On Thu, 28 Jan 2021, Zack Weinberg wrote:
The main reason I can think of, not to do this, is that it would make
the locking strategy incompatible with that used by older autom4te;
this could come up, for instance, if you’ve got your source directory
on NFS and you’re building on two different cl
On Mon, Jan 25, 2021 at 11:18 AM Bob Friesenhahn
wrote:
> On Mon, 25 Jan 2021, Zack Weinberg wrote:
> > Automake "just" calls Perl's 'flock' built-in (see 'sub lock' in
> > Automake/XFile.pm) (this code is copied into Autoconf under the
> > Autom4te:: namespace). It would be relatively straightfo
On Mon, 25 Jan 2021, Zack Weinberg wrote:
Automake "just" calls Perl's 'flock' built-in (see 'sub lock' in
Automake/XFile.pm) (this code is copied into Autoconf under the
Autom4te:: namespace). It would be relatively straightforward to
teach it to try 'fcntl(F_SETLKW, ...)' if that fails. Do y
On Mon, Jan 25, 2021 at 9:52 AM Bob Friesenhahn
wrote:
> At the moment it is a big deal for me because the locking prototol
> that Autoconf/Automake is using does not work with NFS mounts for
> Illumos-derived systems when the client is also an Illumos-derived
> system, because Illumos failed to s
On Sun, 24 Jan 2021, Paul Eggert wrote:
On 1/23/21 4:06 PM, Bob Friesenhahn wrote:
A tiny fork/exec is not a big deal.
It is indeed not a big deal. That being said, one can optimize away GNU
make's fork and exec by using "@:" instead of "@true".
At the moment it is a big deal for me becau
ght having configure not be updated when the information
provided to AC_INIT has not changed was what you wanted to happen!)
It is good if each each 'make' cycle reaches a terminal conclusion and
assures that all targets are successfully concluded. Even if the
content of a target is not
se for example if ChangeLog has been touched, then autoconf
> won't touch configure. I suppose that behavior of autoconf is too
> established to be changed, but I think making --force default would be
> more intuitive.
>
> One solution is to put the content of the AC_INIT arguments into
&
ardless whether 'CONFIGURE_DEPENDENCIES' is mentioned in 'Makefile.am'.
(Also, I thought having configure not be updated when the information
provided to AC_INIT has not changed was what you wanted to happen!)
True, but once the rule for regenerating configure is updated, one wants
On 1/23/21 4:06 PM, Bob Friesenhahn wrote:
A tiny fork/exec is not a big deal.
It is indeed not a big deal. That being said, one can optimize away GNU
make's fork and exec by using "@:" instead of "@true".
_srcdir)/version.sh
directly in Makefile.am? The way you did it, I don't think Automake
will be aware that the variable exists.
(Also, I thought having configure not be updated when the information
provided to AC_INIT has not changed was what you wanted to happen!)
zw
are declared as "dependencies", if one of them changed
it did not necessarily result in configure being updated. If the
information provided to AC_INIT was the same as before it did not seem
to result in configure being updated.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
Hi Bob,
On 24/1/21 10:06 am, Bob Friesenhahn wrote:
I did try this type of solution. As I recall, it did not help because
the terminal target is Automake's regeneration rules, which are
apparently optimized to not modify the target files (e.g. configure)
if there was no change.
This seems l
e before now. I’ve filed
https://savannah.gnu.org/support/index.php?110431 saying that AC_INIT
should start accepting shell variables in its arguments. I’m not sure
what other consequences this may have, but you can make aclocal and
automake shut up about AC_INIT by passing a dummy version argument:
A
On Sat, Jan 23, 2021 at 11:38 AM Bob Friesenhahn
wrote:
>
> I am about to give up on using the new style AC_INIT in the form of
>
> AC_INIT(m4_esyscmd([./version.sh packagename]),
> m4_esyscmd([./version.sh packageversion]),
> m4_esyscmd([./version.s
I am about to give up on using the new style AC_INIT in the form of
AC_INIT(m4_esyscmd([./version.sh packagename]),
m4_esyscmd([./version.sh packageversion]),
m4_esyscmd([./version.sh packagebugreport]),
m4_esyscmd([./version.sh packagetarname]),
m4_esyscmd
On Thu, 14 Jan 2021, Peter Johansson wrote:
I suspect it would be possible to solve by splitting the timestamps into two
different files. One is the VERSION file determining when autoconf needs to
be run and a timestamp file determines when the version.sh script needs be
run. Something like:
On 13/1/21 12:37 pm, Bob Friesenhahn wrote:
This seems like a Catch-22 situation. If the VERSION file timestamp
does not get updated, it will produce this noise, and if does get
updated, then there is a whole reconf-config-build cycle.
Is there any solution for that?
I suspect it would b
On Tue, 12 Jan 2021, Peter Johansson wrote:
The problem is that there is no dependency in the Makefile telling that
autoconf need to be rerun when the version has changed. Automake has the
variable 'CONFIGURE_DEPENDENCIES' for this purpose, so adding
CONFIGURE_DEPENDENCIES = ChangeLog
would s
On Wed, 13 Jan 2021, Peter Johansson wrote:
I don't see any way without a specific file holding the timestamp on when
the version was last updated.
This is very helpful advice (and adds to valuable advice offered in private
emails by others). I don't really like hidden files but I do have a
Hi Bob,
On 13/1/21 12:35 am, Bob Friesenhahn wrote:
On Tue, 12 Jan 2021, Peter Johansson wrote:
The problem is that there is no dependency in the Makefile telling
that autoconf need to be rerun when the version has changed. Automake
has the variable 'CONFIGURE_DEPENDENCIES' for this purpose,
On Tue, 12 Jan 2021, Peter Johansson wrote:
The problem is that there is no dependency in the Makefile telling that
autoconf need to be rerun when the version has changed. Automake has the
variable 'CONFIGURE_DEPENDENCIES' for this purpose, so adding
CONFIGURE_DEPENDENCIES = ChangeLog
would
Hi Bob,
On 12/1/21 10:35 am, Bob Friesenhahn wrote:
I recently updated GraphicsMagick to use the 5 argument form of
AC_INIT and the one argument form of AM_INIT_AUTOMAKE. I also used
m4_esyscmd to get version info from an external script. The
invokation looks like this:
AC_INIT(m4_esyscmd
I recently updated GraphicsMagick to use the 5 argument form of
AC_INIT and the one argument form of AM_INIT_AUTOMAKE. I also used
m4_esyscmd to get version info from an external script. The
invokation looks like this:
AC_INIT(m4_esyscmd([./version.sh packagename]),
m4_esyscmd
am *still* working to update GraphicsMagick to support the 5-part AC_INIT
plus new-style AM_INIT_AUTOMAKE. I am using Autoconf 2.69 and Automake
1.16.3.
Something which is very much unwanted is now the generated config.h has added
these
/* Name of package */
#define PACKAGE "GraphicsMagi
I am *still* working to update GraphicsMagick to support the 5-part
AC_INIT plus new-style AM_INIT_AUTOMAKE. I am using Autoconf 2.69 and
Automake 1.16.3.
Something which is very much unwanted is now the generated config.h
has added these
/* Name of package */
#define PACKAGE
On 2021-01-05, Bob Friesenhahn wrote:
> Something I found which surprised me is that Automake has added a GNU
> COPYING file to my non-GNU non-GPL package. Once the file appeared in
> the source directory, it seems that it continued to be used and
> included in spite of the Automake options provi
On Tue, 5 Jan 2021, Zack Weinberg wrote:
Something I found which surprised me is that Automake has added a GNU
COPYING file to my non-GNU non-GPL package. Once the file appeared in
the source directory, it seems that it continued to be used and
included in spite of the Automake options provide
between the old and new configure
> > scripts that you're curious about.
>
> To be clear, the size difference was intended to be due to the list of
> parameters passed to AC_INIT and AM_INIT_AUTOMAKE and re-autotooling.
> In fact this is still using Autoconf 2.69.
Oh, I mi
eters passed to AC_INIT and AM_INIT_AUTOMAKE and re-autotooling.
In fact this is still using Autoconf 2.69.
Something I found which surprised me is that Automake has added a GNU
COPYING file to my non-GNU non-GPL package. Once the file appeared in
the source directory, it seems that it continued
On Mon, Jan 4, 2021 at 9:08 PM Bob Friesenhahn
wrote:
> I am pretty close to done with updating GraphicsMagick to use the
> recommended Autoconf and Automake initialization syntax. Thanks again
> for your help.
>
> Something which surprises me is that the distribution tarballs became
> noticeably
Hi Bob,
On Mon, 4 Jan 2021, Bob Friesenhahn wrote:
> The .tar.gz package increased from 9,675,006 to 9,683,225 bytes (8,219 bytes
> difference when compressed). Perhaps it is not much but the size difference
> seems large given that only 23 lines of original source code were added.
Forget to
Zack,
I am pretty close to done with updating GraphicsMagick to use the
recommended Autoconf and Automake initialization syntax. Thanks again
for your help.
Something which surprises me is that the distribution tarballs became
noticeably larger.
The .tar.gz package increased from 9,675,00
pt was executed
in two different ways, and the older way was executing it (while
executing configure) in the current directory.
Autoconf itself does something similar and it works reliably:
(quoting https://git.savannah.gnu.org/cgit/autoconf.git/tree/configure.ac#n22)
AC_INIT([GNU Autoconf],
m4
On Sun, Jan 3, 2021 at 6:01 PM Bob Friesenhahn
wrote:
>
> AC_INIT(m4_esyscmd([./version.sh packagename]),
> m4_esyscmd([./version.sh packageversion]),
> m4_esyscmd([./version.sh packagebugreport]))
>
> This works fine when building in the source directory.
&g
syntax in configure.ac:
AC_INIT(m4_esyscmd([./version.sh packagename]),
m4_esyscmd([./version.sh packageversion]),
m4_esyscmd([./version.sh packagebugreport]))
This works fine when building in the source directory.
The problem I am encountering is that in the context of AC_INIT and
On 3/6/19 2:31 AM, Matthieu Poullet wrote:
> Hello,
>
> I've just updated a bunch of configure.ac with autoupdate 2.69 and it
> removes all spaces after commas in the AC_INIT macro and only in this
> macro, e.g.
>
> diff --git a/flaim-ch8-10/configure.ac b/flaim-c
Hello,
I've just updated a bunch of configure.ac with autoupdate 2.69 and it
removes all spaces after commas in the AC_INIT macro and only in this
macro, e.g.
diff --git a/flaim-ch8-10/configure.ac b/flaim-ch8-10/configure.ac
index baa0a1c..a724bbc 100644
--- a/flaim-ch8-10/configure.ac
Hi,
On Wed, May 23, 2012 at 2:17 AM, Bob Friesenhahn
wrote:
> The forthcoming Automake release is about to break the means I have been
> using to automatically version my package (without manually editing
> configure.ac) for the past 9 years. I am told to use m4 code in the AC_INIT
&g
x27;t see appearing if not several several months from now (i.e,, until
there is some major feature or non trivial bug-fix that justifies a new major
release).
That is good to know. Then it is not an emergency for me.
This issue feels like an Autoconf bug to me since AC_INIT is
presumably an Aut
ine([sbuild_m4_chomp],
[m4_format([[%.*s]], m4_bregexp(m4_translit([$1], [
]]m4_dquote(_m4_defn([m4_cr_all]))[, [/]]m4_format([%255s], [])[),
[/*$]), [$1])])
m4_define([sbuild_m4_esyscmd_s],
[sbuild_m4_chomp(m4_esyscmd([$1]))])
AC_PREREQ(2.59)
dnl Quoting the first argument results in a bizarrely corrupte
Hi Bob.
On 05/23/2012 02:17 AM, Bob Friesenhahn wrote:
> The forthcoming Automake release is about to break the means I have been
> using to automatically version my package (without manually editing
> configure.ac) for the past 9 years.
>
I smell a misunderstanding here: Automake 1.12.1 will only
The forthcoming Automake release is about to break the means I have
been using to automatically version my package (without manually
editing configure.ac) for the past 9 years. I am told to use m4 code
in the AC_INIT arguments in order to supply package versioning
information. This is what I
detects if AC_INIT is missing, or if
any of its parameters are not normalized.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
I suppose it's up to
the package authors, as they determine both the format of the address in
PACKAGE_BUGREPORT, and the way it is used.
Hmm, just to clarify: I don't mean that the addresses shouldn't be
wrapped in<...> when presented to the user, but rather that maybe the
e it's up to
> the package authors, as they determine both the format of the address in
> PACKAGE_BUGREPORT, and the way it is used.
Hmm, just to clarify: I don't mean that the addresses shouldn't be
wrapped in <...> when presented to the user, but rather that maybe t
Ralf Wildenhues writes:
> Does it matter that autoconf/general.m4, autoconf/status.m4, and
> autotest/general.m4 wrap PACKAGE_BUGREPORT in < ... > in their messages?
> Would look a bit ugly as >.
Perhaps they shouldn't do such wrapping, although I suppose it's up to
the package authors, as they d
* Eric Blake wrote on Wed, Oct 13, 2010 at 05:02:18PM CEST:
> This bit of NEWS from 2.68 is probably relevant then:
>
> ** AC_INIT again allows URLs with '?' for its BUG-REPORT argument.
>Regression introduced in 2.66.
>
> It doesn't mention '<&#x
On Wed, Oct 13, 2010 at 11:06 PM, Eric Blake wrote:
>> What does this warning mean? What's wrong with my bug-reporting
>> address... is this a bug?
>
> Which version of autoconf? Does it still happen with 2.68?
2.67 (it's been happening for a while, not sure what version it started with)
I'l
while, not sure what version it started with)
I'll try it with 2.68 when I get a chance.
This bit of NEWS from 2.68 is probably relevant then:
** AC_INIT again allows URLs with '?' for its BUG-REPORT argument.
Regression introduced in 2.66.
It doesn't mention '<&
On 10/13/2010 02:55 AM, Miles Bader wrote:
I use AC_INIT like:
AC_INIT([blarghhh], [0.0001], [Miles Bader])
but this many (although not very edifying) complaints from various autotools:
$ autoreconf
configure.ac:1: warning: AC_INIT: not a literal: Miles Bader
configure.ac:1
I use AC_INIT like:
AC_INIT([blarghhh], [0.0001], [Miles Bader ])
but this many (although not very edifying) complaints from various autotools:
$ autoreconf
configure.ac:1: warning: AC_INIT: not a literal: Miles Bader
configure.ac:1: warning: AC_INIT: not a literal: Miles Bader
Hi Ralf,
> > $ autoconf
> > configure.ac:1: warning: AC_INIT: not a literal: 2.48++ (2010-07-03)
> >
> > Yes, in some packages, the version number consists of two parts, separated
> > by
> > a space.
>
> The space isn't a what triggers the
nt you to add -g
>> -O2 to my flags"
>
> That's okay. Doing simply
>
> : ${CXXFLAGS=""}
>
> right after AC_INIT is fine. So is setting CXXFLAGS to "-O1 -g" if your
> program doesn't like being compiled at -O2.
>
> I'm
gt; ./package/configure.ac
>> m4_include([../version.m4])
>> AC_INIT([package],VERSION_NUMBER)
>
> FWIW, it is a bit safer wrt. m4 quoting to use something like
>AC_INIT([package], m4_defn([VERSION_NUMBER])
>
> (unfortunately, normal quoting won't work here).
>
nclude([../version.m4])
> AC_INIT([package],VERSION_NUMBER)
FWIW, it is a bit safer wrt. m4 quoting to use something like
AC_INIT([package], m4_defn([VERSION_NUMBER])
(unfortunately, normal quoting won't work here).
Cheers,
Ralf
___
Autoconf maili
> What's the easiest way to specify the AC_INIT package version external to
> configure.ac?
why not including just another m4 file which defines the version number?
example:
./version.m4
m4_define([VERSION_NUMBER],[1.2.3])
./package/configure.ac
m4_include([../version.m4]
NightStrike writes:
> Ralf Wildenhues wrote:
>> Automake still needs changes in order for efficient handling of
>> fast-changing version strings (as from, e.g., git describe).
> What's a fast-changing string?
Version strings that change with every commit.
--
Russ Allbery (r...@stanford.edu)
* NightStrike wrote on Tue, Jan 05, 2010 at 08:18:03PM CET:
> On Tue, Jan 5, 2010 at 2:07 PM, Ralf Wildenhues wrote:
> > Automake still needs changes in order for efficient handling of
> > fast-changing version strings (as from, e.g., git describe).
>
> What's a fast-changing string?
Well, for ex
On Tue, Jan 5, 2010 at 2:07 PM, Ralf Wildenhues wrote:
> Automake still needs changes in order for efficient handling of
> fast-changing version strings (as from, e.g., git describe).
What's a fast-changing string?
___
Autoconf mailing list
Autoconf@g
Hello,
* esseffe wrote on Mon, Jan 04, 2010 at 05:30:14PM CET:
>
> What's the easiest way to specify the AC_INIT package version external to
> configure.ac?
One way is to use m4_esyscmd to use a command that is run at autoconf
run time to specify the version. Autoconf's ow
What's the easiest way to specify the AC_INIT package version external to
configure.ac?
I have about 12 sets of configure.ac/Makefile.am that compile the same code
in slightly different ways. The version set in AC_INIT has to be the same
for all configure.ac's. I want to avoid having t
to add -g
-O2 to my flags"
That's okay. Doing simply
: ${CXXFLAGS=""}
right after AC_INIT is fine. So is setting CXXFLAGS to "-O1 -g" if your
program doesn't like being compiled at -O2.
I'm not a native speaker (and the only native-speaking Autoconf
develo
Bob Friesenhahn wrote:
> On Thu, 30 Jul 2009, Paolo Bonzini wrote:
>
>>> The terrible part about how this mechanism works is that it injects into
>>> CXXFLAGS itself, which means that, without my configure script can't
>>> override that via the setting of AM_CXXFLAGS.
>>
>> I cannot parse this sen
On Thu, 30 Jul 2009, Bob Friesenhahn wrote:
On Thu, 30 Jul 2009, Paolo Bonzini wrote:
The terrible part about how this mechanism works is that it injects into
CXXFLAGS itself, which means that, without my configure script can't
override that via the setting of AM_CXXFLAGS.
I cannot parse thi
On Thu, 30 Jul 2009, Paolo Bonzini wrote:
The terrible part about how this mechanism works is that it injects into
CXXFLAGS itself, which means that, without my configure script can't
override that via the setting of AM_CXXFLAGS.
I cannot parse this sentence. Can you explain?
He is saying t
The terrible part about how this mechanism works is that it injects into
CXXFLAGS itself, which means that, without my configure script can't
override that via the setting of AM_CXXFLAGS.
I cannot parse this sentence. Can you explain?
Paolo
___
A
Bob Friesenhahn wrote:
> On Sun, 26 Jul 2009, Richard Connon wrote:
>>
>> Hi. I'm trying to write a configure.ac script for a project I'm working
>> on. At present it has AC_INIT at the beginning.
>> It seems that running that macro is adding "-g -O2"
On Sun, 26 Jul 2009, Richard Connon wrote:
Hi. I'm trying to write a configure.ac script for a project I'm working
on. At present it has AC_INIT at the beginning.
It seems that running that macro is adding "-g -O2" to the CXXFLAGS
variable. Is there anything I can do to s
On Sun, 2009-07-26 at 22:11 +0100, Richard Connon wrote:
> Hi. I'm trying to write a configure.ac script for a project I'm working
> on. At present it has AC_INIT at the beginning.
> It seems that running that macro is adding "-g -O2" to the CXXFLAGS
> variable. Is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi. I'm trying to write a configure.ac script for a project I'm working
on. At present it has AC_INIT at the beginning.
It seems that running that macro is adding "-g -O2" to the CXXFLAGS
variable. Is there anything I can do to s
In the manual, it says this:
This macro is the only macro that may be used before AC_INIT, but for
consistency, you are invited not to do so.
Yes, autoscan places AC_PREREQ first. Which is considered "better",
in any sense of the term?
__
number.
> >
> > So I hacked up this in configure.in:
> >
> > SVN_VERSION=`./version.sh`
> >
> > AC_INIT(my-fine-package, $SVN_VERSION)
>
> AC_INIT(my-fine-package, m4_esyscmd([./version.sh | tr -d '\n']))
>
> Note that you need to manuall
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding m4-discuss for a discussion on syscmd/esyscmd behavior]
According to Eric Blake on 12/14/2007 8:05 AM:
> According to Andreas Schwab on 12/14/2007 7:56 AM:
>> AC_INIT(my-fine-package, m4_esyscmd([./version.sh | tr -d '\n'
Eric Blake <[EMAIL PROTECTED]> writes:
> According to Andreas Schwab on 12/14/2007 7:56 AM:
>> AC_INIT(my-fine-package, m4_esyscmd([./version.sh | tr -d '\n']))
>>
>> Note that you need to manually remove the final newline, unlike command
>> substi
Hello,
* Eric Blake wrote on Fri, Dec 14, 2007 at 04:04:20PM CET:
>
> AC_INIT([GNU Autoconf],
> m4_esyscmd([build-aux/git-version-gen . .version]),
> [EMAIL PROTECTED])
[...]
> One thing to be aware of is build
> dependencies [...]
> Therefore, autoconf also h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Andreas Schwab on 12/14/2007 7:56 AM:
> AC_INIT(my-fine-package, m4_esyscmd([./version.sh | tr -d '\n']))
>
> Note that you need to manually remove the final newline, unlike command
> substitutions m4_esyscmd do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Stefano Sabatini on 12/14/2007 7:45 AM:
>
> |It is preferable that the arguments of `AC_INIT' be static, i.e.,
> |there should not be any shell computation, but they can be
> |computed by M4.
>
> So my questio
Stefano Sabatini <[EMAIL PROTECTED]> writes:
> Hi all autoconfers,
>
> I have a package managed by SVN, and I would like to assign the
> AC_PACKAGE_VERSION using the current SVN version number.
>
> So I hacked up this in configure.in:
>
> SVN_VERSION=`./version.s
Hi all autoconfers,
I have a package managed by SVN, and I would like to assign the
AC_PACKAGE_VERSION using the current SVN version number.
So I hacked up this in configure.in:
SVN_VERSION=`./version.sh`
AC_INIT(my-fine-package, $SVN_VERSION)
where version.sh is a script which will output on
Hi,
Currently some configure.ac of mine starts like this:
AC_PREREQ([2.59])
AC_INIT
AC_CONFIG_SRCDIR(intl/dcigettext.c)
AC_CONFIG_AUX_DIR(../build-aux)
. $srcdir/../version.sh
AM_INIT_AUTOMAKE(gettext-runtime, $VERSION_NUMBER)
Now I would like to set some automake options. The
* Harlan Stenn wrote on Thu, Feb 02, 2006 at 11:37:04PM CET:
> > > I am always surprized, as well, to see so many warnings due to the
> > > latest libtool, still using obsolete macros !
libtool 2.0 will do away with most of these warnings.
> > I assume that you prefer that anyone using the latest
> > I am always surprized, as well, to see so many warnings due to the
> > latest libtool, still using obsolete macros !
>
> I assume that you prefer that anyone using the latest libtool should
> also be required to use the latest autoconf?
What would be the problem with that?
But I also think
On Thu, 2 Feb 2006, Olivier Boudeville wrote:
I am always surprized, as well, to see so many warnings due to the
latest libtool, still using obsolete macros !
I assume that you prefer that anyone using the latest libtool should
also be required to use the latest autoconf?
Bob
==
this approach, I noticed that at least AC_INIT,
>> AC_CONFIG_SRCDIR and AC_CONFIG_HEADERS do not seem to allow variable
>> substitution ($A taken litterally instead of its value, am I wrong ?)
>> I think to using a template that could be filled with settings read
>> from a f
Olivier Boudeville wrote:
After having tried this approach, I noticed that at least AC_INIT,
AC_CONFIG_SRCDIR and AC_CONFIG_HEADERS do not seem to allow variable
substitution ($A taken litterally instead of its value, am I wrong ?)
I think to using a template that could be filled with
Hi all,
I do not know well the Autotools, but regarding the past thread 'AC_INIT
receiving PACKAGE_VERSION from outside', I wrote a little shell script
(attached to this mail)
that allows to generate a version file that can be both sourced by shell
scripts and included by m4, as su
Hi all,
I do not know well the Autotools, but regarding the past thread 'AC_INIT
receiving PACKAGE_VERSION from outside', I wrote a little shell script
that allows to generate a version file that can be both sourced by shell
scripts and included by M4, as suggested by Alexandre
([syntax], [AC_INIT: not a literal: $3])])
But you also have to face the real problems: grep the autoconf CVS (amd Automake
CVS) for occurrences of the AC_PACKAGE_* macros.
Then you did changes like this:
> -m4_ifndef([AC_PACKAGE_NAME],
> - [m4_define([AC_PACKAGE_NAME], [$1])])
RELEASE_DATE=2005-03-14 # in "date +%Y-%m-%d" format
Sam> --
Sam> do I need something like this:
Sam> syscmd([. version.sh; echo "${VERSION_NUMBER} ${RELEASE_DATE}">version])
Sam> AC_INIT([foo
Alexandre Duret-Lutz wrote:
> AC_INIT([foobar], m4_normalize(m4_include([version])))
>
> And write down your version string in the `version' file.
Ah, thanks for the great trick!
> (m4_normalize strips extra spaces and new lines.)
The call to m4_normalize appears to be needed
Sam Steingold wrote:
> > AC_INIT([foobar], m4_normalize(m4_include([version])))
> >
> > And write down your version string in the `version' file.
>
> what if my version is more complex?
> e.g.
> --
> * Alexandre Duret-Lutz <[EMAIL PROTECTED]> [2005-03-17 23:52:14 +0100]:
>
> [...]
> Stepan> In your case, you would put the defines in a separate
> Stepan> file, and include it like this
> Stepan>
> Stepan> m4_include([m4/version.m4])
> Stepan&g
[...]
Stepan> In your case, you would put the defines in a separate
Stepan> file, and include it like this
Stepan>
Stepan> m4_include([m4/version.m4])
Stepan> AC_INIT([gnumeric], [gnumeric_full_version],
Stepan> [http://bugzilla.gnome.org/enter_bug.cgi?product=gnumeric])
--
m4_define([_AC_INIT_PACKAGE],
-[AS_LITERAL_IF([$1], [], [m4_warn([syntax], [AC_INIT: not a literal: $1])])
-AS_LITERAL_IF([$2], [], [m4_warn([syntax], [AC_INIT: not a literal: $2])])
-AS_LITERAL_IF([$3], [], [m4_warn([syntax], [AC_INIT: not a li
1 - 100 of 183 matches
Mail list logo
