> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>> > Ok, thanks.
>> > This is definitely an automake bug.
>> > Your proposed fix sounds ok to me.
>>
>> Patch included.
Derek> Whoops. Here's the patch for real.
This patch is still big enough that we need paperwork.
Derek> Akim, wha
On Feb 5, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
> * tests/semantics.at (AC_REPLACE_FUNCS): New test.
> * acfunctions.m4 (AC_REPLACE_FUNCS, _AC_LIBOBJ_ALLOCA): Use
> AC_LIBSOURCES.
Ok
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat G
These people should be sent the file
fencepost.gnu.org:/gd/gnuorg/Copyright/request-assign.future. They
fill out the form, return it to me, and I send them the paperwork to
sign.
If you don't have easy access to fencepost, I'll include the file
below.
- Brian Youma
"Derek R. Price" <[EMAIL PROTECTED]> writes:
> AC_REPLACE_FUNCS is still trying to call AC_LIBOBJ_DECL. :(
Pfff, there was no test for AC_REPLACE_FUNCS at all!
Thanks!
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
acfunctions.m4 was still using the old AC_LIBOBJ_DECL.
"Derek R. Price" wrote:
> > > +# This macro handles several different things.
> > > +AM_INIT_AUTOMAKE =>
> > > + sub { $seen_make_set = $_[0];
> > > + $seen_arg_prog = $_[0];
> > > + $seen_prog_install = $_[0];
> > > + $package_version = $_[3];
> > > +
Akim Demaille wrote:
> FYI, I applied this to Autoconf:
>
> 2001-02-03 Akim Demaille <[EMAIL PROTECTED]>
>
> * acfunctions.m4 (AC_FUNC_ERROR_AT_LINE, AC_FUNC_ONSTACK): Use
> AC_LIBSOURCES.
>
> 2001-02-03 Akim Demaille <[EMAIL PROTECTED]>
>
> * acgeneral.m4 (AC_LIBOBJ_D
Akim Demaille wrote:
> "Derek R. Price" <[EMAIL PROTECTED]> writes:
>
> All these comments are related to the same idea: Automake must know as
> less as possible about macros. It means that if needed, we have to
>
> ~/src/ace % echo "AC_INIT AC_CANONICAL_SYSTEM" | ace -t AC_CANONICAL_SYSTEM -t
"Derek R. Price" wrote:
> Tom Tromey wrote:
>
> > > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
> >
> > Derek> From comp-vars.am:
> > Derek> DEFS = @DEFS@@DEFAULT_INCLUDES@
> >
> > Ok, thanks.
> > This is definitely an automake bug.
> > Your proposed fix sounds ok to me.
>
> Patch in
Tom Tromey wrote:
> > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> Derek> From comp-vars.am:
> Derek> DEFS = @DEFS@@DEFAULT_INCLUDES@
>
> Derek> Automake subs some compiler include paths into
> Derek> @DEFAULT_INCLUDES@ during the creation of Makefile.ins from
> Derek> Makefile.am
> Hm, I'm in favor of having AC_ARG_PROGRAM always run. I see no use in
> having only partial support for this option across configures. In
> addition, AM_INIT_AUTOMAKE, IIRC, calls it by itself.
>
> Pavel, Alexandre, any problem with integrating AC_ARG_PROGRAM in AC_INIT?
An obvious problem is
Tom Tromey <[EMAIL PROTECTED]> writes:
> Akim, provided that the changes don't break using automake with an
> older autoconf, I trust your judgement on reviewing them.
OK, thanks.
> I still haven't looked at the --trace code.
Anyway, I think it can still change a lot. But reading it is re
"Derek R. Price" <[EMAIL PROTECTED]> writes:
> Ok, I found the link on gnu.org on how and why. You can send me the
> set allowing multiple contributions, and I need an empployer
> disclaimer.
What do you want us to sign? The FSF has recently changed its
procedure, and we are all a bit lost.
B
"Derek R. Price" <[EMAIL PROTECTED]> writes:
Hi Derek, a few more comments on the fly. I have not played with your
patch yet.
All these comments are related to the same idea: Automake must know as
less as possible about macros. It means that if needed, we have to
equip Autoconf with macros whi
> "Akim" == akim <[EMAIL PROTECTED]> writes:
Akim> As far as I'm concerned, given that your mark are extremely easy
Akim> to remove, given that most messages are from the experimental
Akim> code, given that I certainly would like to toy with your
Akim> implementation, I'd vote for an inclusi
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> From comp-vars.am:
Derek> DEFS = @DEFS@@DEFAULT_INCLUDES@
Derek> Automake subs some compiler include paths into
Derek> @DEFAULT_INCLUDES@ during the creation of Makefile.ins from
Derek> Makefile.ams so that any headers described i
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> The case in question is the DEFAULT_INCLUDES variable being
Derek> substituted in as part of DEFS. Since Automake still asumes
Derek> that a call to AC_SUBST(DEFS) is always user-requested and that
Derek> a user request overrides
"Derek R. Price" wrote:
> [EMAIL PROTECTED] wrote:
>
> > On Fri, Feb 02, 2001 at 01:17:13PM -0500, Derek R. Price wrote:
> > > Akim Demaille wrote:
> > > that I certainly would like to toy with your implementation, I'd vote
> > > for an inclusion in Automake. Do you have your papers? :)
>
> No,
[EMAIL PROTECTED] wrote:
> On Fri, Feb 02, 2001 at 01:17:13PM -0500, Derek R. Price wrote:
> > Akim Demaille wrote:
> >
> > > "Derek R. Price" <[EMAIL PROTECTED]> writes:
> >
> > Patch against the current CVS Automake attached. Please excuse all the
> > "print STDERR"s and my initials littered i
On Fri, Feb 02, 2001 at 01:17:13PM -0500, Derek R. Price wrote:
> Akim Demaille wrote:
>
> > "Derek R. Price" <[EMAIL PROTECTED]> writes:
>
> Patch against the current CVS Automake attached. Please excuse all the
> "print STDERR"s and my initials littered in comments around the things I was
> s
Akim Demaille wrote:
> "Derek R. Price" <[EMAIL PROTECTED]> writes:
>
> > Ok, I have amtraces code that slurps in almost all the information that
> > scan_one_autoconf_file used to. Unfortuantely I hit a minor snag:
>
> We are probably working on the same things. Please, show some code so
> tha
"Derek R. Price" <[EMAIL PROTECTED]> writes:
> Ok, I have amtraces code that slurps in almost all the information that
> scan_one_autoconf_file used to. Unfortuantely I hit a minor snag:
We are probably working on the same things. Please, show some code so
that we don't duplicate.
> Since _al
21 matches
Mail list logo
