Related to automake bug#13514.
Every bootstrapping process which does not need to have the local
macro directory existing in version control system (because it does
not have any user-defined macros) would fail during 'autoreconf -vfi'
phase if the AC_CONFIG_MACRO_DIRS([m4]) is specified (to force
Related to automake bug#13514.
Do not explore these directories multiple times in 'aclocal'. This
causes problems on older packages that specify
configure.ac: AC_CONFIG_MACRO_DIRS([m4])
Makefile.am: ACLOCAL_AMFLAGS = -I m4
when the m4 directory does not exist.
See:
Hi, thanks for your comments!
Here is second iteration of my proposal.
[PATCH 1/2] aclocal: just warn if the primary local m4 dir doesn't
aclocal.in | 10 ++
t/aclocal-macrodir.tap | 22 +-
[PATCH 2/2] aclocal: fix for more-than-once specified directories
On 02/11/2013 01:11 PM, Pavel Raiskup wrote:
Hi, thanks for your comments!
Thanks for your patches, and you patience.
Here is second iteration of my proposal.
[PATCH 1/2] aclocal: just warn if the primary local m4 dir doesn't
aclocal.in | 10 ++
t/aclocal-macrodir.tap
Related to automake bug#13514.
Every bootstrapping process which does not need to have the local
macro directory existing in version control system (because it does
not have any user-defined macros) would fail during 'autoreconf -vfi'
phase if the AC_CONFIG_MACRO_DIRS([m4]) is specified (to force
Hi, thanks for your comments!
Here is second iteration of my proposal.
[PATCH 1/2] aclocal: just warn if the primary local m4 dir doesn't
aclocal.in | 10 ++
t/aclocal-macrodir.tap | 22 +-
[PATCH 2/2] aclocal: fix for more-than-once specified directories
Related to automake bug#13514.
Do not explore these directories multiple times in 'aclocal'. This
causes problems on older packages that specify
configure.ac: AC_CONFIG_MACRO_DIRS([m4])
Makefile.am: ACLOCAL_AMFLAGS = -I m4
when the m4 directory does not exist.
See:
Yes, but not if they don't want (or don't necessarily need) to switch
macros into different directory than 'm4'?
There might be a misunderstanding here (either from your part, or in
my understanding of what you are saying). Are you aware that none of
the autotools use *any* local m4
Hi Diego, Jack, sorry for the late reply.
On 02/01/2013 06:47 AM, Jack Kelly wrote:
Diego Elio Pettenò flamee...@flameeyes.eu writes:
On 31/01/2013 20:58, Jack Kelly wrote:
IMHO, that seems like a great way to cause trouble for unsuspecting
users. (Anyone remember KDE4.0?) Can you expand on
Yes, but not if they don't want (or don't necessarily need) to switch
macros into different directory than 'm4'?
There might be a misunderstanding here (either from your part, or in
my understanding of what you are saying). Are you aware that none of
the autotools use *any* local m4
On 11/02/2013 15:54, Stefano Lattarini wrote:
But what if we want to have multiple betas for, say, Automake 1.14? Today,
we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
you are proposing?
Given that 1.12.0 was not really final release, and 1.13.0 _and_ .1
were not
Stefano Lattarini stefano.lattar...@gmail.com writes:
But what if we want to have multiple betas for, say, Automake 1.14? Today,
we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
you are proposing?
There's always 1.14.0.1, ...
Or the widely used in FOSS 1.13.99...
Hey
I'm porting a lib to a non recursive make build system. I have a
single top level Makefile.am which has:
AUTOMAKE_OPTIONS = subdir-objects
include src/lib/css/Makefile.mk
In that Makefile.mk, yacc is called and generates the file
src_lib_css_libecss_la-ecss_grammar.h from ecss_grammar.y
13 matches
Mail list logo
