"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, what is the naming
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
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 GCC
"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.
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
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_DECL): Remove.
"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
"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.
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
"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.
S
From comp-vars.am:
DEFS = @DEFS@@DEFAULT_INCLUDES@
Automake subs some compiler include paths into @DEFAULT_INCLUDES@ during the
creation of Makefile.ins from Makefile.ams so that any headers described in
AM_CONFIG_HEADER can be found during compilation.
Unfortuantely, it will not do this if
[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 in comments
"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, actually. I
The amtraces functionality for AC_CONFIG_FILES is totally broken.
Anyone mind if I spend a few minutes on it?
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
I don't suffer from stress
14 matches
Mail list logo
