In order to test several compilation variants on the same small set of
files and to reduce bugreport turnaround time, it would be helpful
if, after the first failure, the other tests would still be run.
OTOH, I would not like to repeatedly mention the files as AT_DATA input.
Essentially,
* 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 AC_INIT([gnumeric], [gnumeric_full_version],
Stepan
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.
--
# Version number and release date.
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, since usually a file
Hi,
I am novice for gnu automake/autoconf tools then I
have had some general questions about the subject;
Mainly I could like to know a bit more
about best practices.
1-) Which are the advantages to use a
configure.in for each subdirectory ? Today I am
using only one configure.in in the
Sam == Sam Steingold [EMAIL PROTECTED] writes:
Sam what if my version is more complex?
Sam e.g.
Sam --
Sam # Version number and release date.
Sam VERSION_NUMBER=2.33.83
Sam RELEASE_DATE=2005-03-14 # in date +%Y-%m-%d format
