Hello,
thanks for your interesting contribution.
On Sat, Jun 11, 2005 at 12:36:17AM +1000, John Vandenberg wrote:
> I recently accidently ran into a ~10% performance improvement in
> aclocal. The attached patch requests autom4te only traces 'defun'
> macros that aclocal has noticed, rather than
Hi,
a bug report pointed me to AC_PROG_CC_C_O.
The macro has two uses:
1) in GNU make's configure.in
2) in Automake's AM_PROG_CC_C_O
ad 1) Special needs of a project should be solved in that project.
ad 2) The comments in automake/m4/minuso.m4 explain why Automake is not
happy with the inter
Hi Stepan,
* Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST:
>
> The macro has two uses:
> 1) in GNU make's configure.in
> 2) in Automake's AM_PROG_CC_C_O
How do you know nobody else uses it? It's published.
> If yes, shouldn't we introduce a generalized macro, for example
>
>
On Fri, 2005-07-01 at 14:33 +0200, Ralf Wildenhues wrote:
> Hi Stepan,
>
> * Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST:
> >
> > The macro has two uses:
> > 1) in GNU make's configure.in
> > 2) in Automake's AM_PROG_CC_C_O
>
> How do you know nobody else uses it? It's published.
* Ralf Corsepius wrote on Fri, Jul 01, 2005 at 03:20:22PM CEST:
> On Fri, 2005-07-01 at 14:33 +0200, Ralf Wildenhues wrote:
> > * Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST:
> > >
> > > The macro has two uses:
> > > 1) in GNU make's configure.in
> > > 2) in Automake's AM_PROG_CC_C_O
On Fri, 2005-07-01 at 15:23 +0200, Ralf Wildenhues wrote:
> * Ralf Corsepius wrote on Fri, Jul 01, 2005 at 03:20:22PM CEST:
> > On Fri, 2005-07-01 at 14:33 +0200, Ralf Wildenhues wrote:
> > > * Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST:
> > > >
> > > > The macro has two uses:
> > >
Hello,
On Fri, Jul 01, 2005 at 02:33:57PM +0200, Ralf Wildenhues wrote:
> > The macro has two uses:
> > 1) in GNU make's configure.in
> > 2) in Automake's AM_PROG_CC_C_O
>
> How do you know nobody else uses it? It's published.
Of course I don't know. But it's so poorly designed, that I think i
Hi,
On Fri, Jul 01, 2005 at 04:08:50PM +0200, Ralf Corsepius wrote:
> > > All packages using "subdir-objects" (Flat Makefiles in deep source trees
> > > support) currently are using it.
...
> Yep, I am referring to AM_PROG_CC_C_O, which according to the comment
> above internally uses AC_PROG_CC_C
Hi all;
I got no real response to this. This release of GNU make (3.81) is
coming up (one hopes!) and this seems like a real problem that we need
to come up with a solution for. If we don't it seems like automake and
GNU make 3.81 and Java simply will not be usable together.
Anyone have any tho
I figured out the problem: for some reason, I couldn't just specify the
option in the top-level Makefile.am. I had to specify it in the src
directory's Makefile.am. (How come?)
Thus spake Ralf Wildenhues on 6/30/2005 6:29 PM:
* overbored wrote on Fri, Jul 01, 2005 at 12:44:38AM CEST:
Thus sp
FYI, here's one way to handle it (obviously requires GNU make):
ifeq (,$(filter second-expansion,$(.FEATURES)))
# GNU make <3.81
PRE_D := $$
else
# GNU make >=3.81
PRE_D :=
endif
# Now use PRE_D in prerequisites
all: foo$(PRE_D)bar ; @echo '$@: $<'
foo$$bar: ; @
>>> "pds" == Paul D Smith <[EMAIL PROTECTED]> writes:
pds> Hi all;
pds> I got no real response to this. This release of GNU make (3.81) is
pds> coming up (one hopes!) and this seems like a real problem that we need
pds> to come up with a solution for. If we don't it seems like automake and
>>> "pds" == Paul D Smith <[EMAIL PROTECTED]> writes:
pds> FYI, here's one way to handle it (obviously requires GNU make):
pds> ifeq (,$(filter second-expansion,$(.FEATURES)))
pds> # GNU make <3.81
pds> PRE_D := $$
pds> else
pds> # GNU make >=3.81
pds> PRE_D :=
pds> endif
pds> # Now
13 matches
Mail list logo
