Automake seems to be creating targets by default that make use of
automake whether or not the user has automake installed. Timestamps
seem to get fouled up in distribution often enough that I think this is
very bad from a maintenance viewpoint (more questions to answer) and
very rude to users.
I
swer...
- Bart Simpson on chalkboard, _The Simpsons_
"Derek R. Price" wrote:
> Automake seems to be creating targets by default that make use of
> automake whether or not the user has automake installed. Timestamps
> seem to get fouled up in distribution often enough that
Akim Demaille wrote:
> >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> Derek> This could be a very useful tool but without this feature I
> Derek> cannot use it in good conscience.
>
> What's wrong with the `missing'
Paul Berrevoets wrote:
> This should already be taken care of by the macro AM_MAINTAINER_MODE. If you use:
> ./configure --enable-maintainer-mode
> then the autoconf/automake targets are enabled. They should be disabled by default.
Doesn't it make more sense to enable/disable the targets bas
"Lars J. Aas" wrote:
> : And I'm totally against AM_MAINTAINER_MODE :)
>
> I always use it. I want every invokation of autoconf and automake to
> be explicit on my behalf. I even hate it when config.status goes into
> recheck mode.
I'm happy enough with them running automatically when the tool
Akim Demaille wrote:
> What's wrong with the `missing' approach? What version of Automake
> are you using? I'm using CVS Automake for my package, and never found
> such problem.
Oh, Version 1.4. And what's 'CVS Automake' as opposed to automake?
Derek
--
Derek Price CVS
Akim Demaille wrote:
> What's wrong with the `missing' approach?
I ran automake the first time without the '--add-missing' argument so
when it told me it wouldn't run because "AUTHORS" and "missing" weren't
present I simply touched the files in expectation of figuring out what
GNU wanted of me l
Is there some reason that *-local targets aren't always valid when their
parent exists? I wanted to define distclean-hdr-local to remove
options.h-SAVED as well as options.h, but I can't seem to get it to
work.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.o
I'm in the middle of an attempt to convert CVS to use automake but I'm
having some trouble. Is there some way to selectively override clean
targets created by default for info targets without having to specify
the entire clean target manually?
I specified
info_TEXINFOS = cvs.texinfo cvsclie
Okay, is there some way short of symlinking the
/usr/share/automake/texinfo.tex file by hand to make sure that automake
--add-missing uses the "proper" texinfo.tex file (i.e. the one installed
with the texinfo package and assumedly the most recent one)?
Derek
--
Derek Price
Why does AM require that texinfo.tex be included in the distribution in
the first place? It is installed with tex distributions by default
anyhow, isn't it? Its presence screws up my PDF target, which needs to
find the texinfo.tex in /usr/share/texmf/pdftex/texinfo/texinfo.tex but
will accept th
"Derek R. Price" wrote:
> Why does AM require that texinfo.tex be included in the distribution in
> the first place? It is installed with tex distributions by default
> anyhow, isn't it? Its presence screws up my PDF target, which needs to
Okay, I found the no-texin
Alexandre Oliva wrote:
> On Nov 13, 2000, "Derek R. Price" <[EMAIL PROTECTED]> wrote:
>
> > Okay, is there some way short of symlinking the
> > /usr/share/automake/texinfo.tex file by hand to make sure that automake
> > --add-missing uses the "pro
ROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
... one of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination of their C
programs.
- Robert Firth
Hi,
"Derek R. Price" <[EMAIL PROTECTED]> wri
is there some easy (i.e. not involving hacking) way to define a new
recursive target? e.g.:
RECURSIVE_TARGETS = remotecheck
which would shove remotecheck-recursive into the list with generated
targets all-recursive, check-recursive, install-recursive, etc. and add
a remotecheck & remotechec
"Derek R. Price" wrote:
> I'm in the middle of an attempt to convert CVS to use automake but I'm
> having some trouble. Is there some way to selectively override clean
> targets created by default for info targets without having to specify
> the entire clean
Tom Tromey wrote:
> >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> Derek> Yep. Looks like that could be used by configure to set, say,
> Derek> TEX_TEXINPUTS & PDFTEX_TEXINPUTS and prepend include dirs
> Derek> di
The CVS automake, using --add-missing and not using AC_CONFIG_AUX_DIR,
is placing depcomp in whatever directory it first encounters C files in
then looking for it during configure in $(top_srcdir).
The problem appears to start on line 3054 of automake.in (in the
handle_dependencies function):
( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
82. Hold a hard drive to your ear -- listen to the C.
Raja R Harinath wrote:
> "Derek R. Price" <[EMAIL PROTECTED]> writes:
> > The problem appears to start on line 3054 of automak
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
Round up the usual suspects.
- Claude Rains as Captain Louis Renault, _Casablanca_
"Derek R. Price" wrote:
>
"Derek R. Price" wrote:
> 2) In the case of $config_aux_dir, I removed all the switches on '.' and '' and
> replaced three with a switch on a new variable $config_aux_dir_set_in_configure_in
> (yeah, I know that's a little long, but it su
I built RPMs out of the CVS automake and with my fix for the depcomp
behavior. I figured I'd post them in case anybody wants them. The RPM
source is almost identical to RedHat's 1.4 automake with some patches
removed that wouldn't apply anymore and the depcomp patch added. I'm
not sure what the
There was a bug in m4/header.m4 (AM_CONFIG_HEADER) which was causing
configure & config.status to create a $(top_builddir)/stamp-h file for
every header file instead of the $(top_builddir)/$(subdir)/stamp-h$index
file it was supposed to create. Basically, a few shell metachars which
were supposed
Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
He who laughs last thinks slowest.
"Derek R. Price" wrote:
> I built RPMs out of the CVS automake and with my fix for the depcomp
> behavior. I figured I'd post them in ca
n the Constitution called them to the
decision by suffrage, they pronounced their verdict, honorable to those who had
served them and consolatory to the friend of man who believes he may be
intrusted with his own affairs.
- Thomas Jefferson; 2nd Inaugural Address, 1805
"Dere
Tom Tromey wrote:
> >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> >> Me too. But the point is that GNU packages are supposed to ship
> >> with texinfo.tex.
>
> Derek> Is there a web page somewhere with this standa
Is there a good reason the configure script creates
$(top_builddir)/.deps during the test that sets $DEPDIR and doesn't
delete it again? Besides some developer or other needing sleep? ;)
My distribution certainly doesn't seem to need that directory sitting
around...
Derek
--
Derek Price
Sebastian Rahtz wrote:
> [EMAIL PROTECTED] writes:
> >
> > Assuming I have a texinfo.tex & a pdftexinfo.tex, both in '.', is there
> > some command that will allow 'texi2dvi foo.texi' and 'texi2dvi --pdf
> > foo.texi' to each find the appropriate texinfo.tex?
> >
>
> surely the simpler answe
Raja R Harinath wrote:
> > directory from the same source files, this would disable either the building
> > of PDFs or it would disable everything else.
>
> Actually, new versions of texinfo.tex from ftp.gnu.org seem to not
> need a special pdftexinfo.tex.
Yep. That seems to have done the trick
Tom Tromey wrote:
> >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> Derek> Is there a good reason the configure script creates
> Derek> $(top_builddir)/.deps during the test that sets $DEPDIR and
> Derek> doesn't delete
vtexi.test is failing in the CVS automake. I assume it broke due to the
recent vtexi behavior change.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
[Let us] go on in doing with [the]
I added rudimentary support for different implementations of etags (read
the one Automake expects and Exuberent etags) since they take slightly
different options. Exuberent etags is the version distributed with
RedHat Linux 6.2 & I believe Debian and a few others.
I added a macro to test for the
I added the etags support to my RPMs:
http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_5.src.rpm
http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_5.src.rpm
Derek
--
Derek Price CVS Solutions Architect (
http://CVSHome.org )
mailto:[EMAIL
"Derek R. Price" wrote:
> vtexi.test is failing in the CVS automake. I assume it broke due to the
> recent vtexi behavior change.
I just looked and I was right. The fix was simple - the test simply wasn't
expecting the $(srcdir)/ prefix on version.texi.
"Derek R. Price" wrote:
> "Derek R. Price" wrote:
>
> > vtexi.test is failing in the CVS automake. I assume it broke due to the
> > recent vtexi behavior change.
>
> I just looked and I was right. The fix was simple - the test simply wasn't
"Derek R. Price" wrote:
> I added the etags support to my RPMs:
I regenerated them again using todays version of the CVS Automake since the
failing vtexi.test wasn't a bug.
http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_6.noarch.rpm
http://alumni.engin
Raja R Harinath wrote:
> > I added a macro to test for the presence of etags and whether it
> > supports "--etags-include=" or "-i " for includes.
>
> If Exuberent etags is supposed to be a drop-in replacement for Emacs
> etags, it should support the same options. Otherwise, it is a bug in
> the
"Derek R. Price" wrote:
> > > I added a macro to test for the presence of etags and whether it
> > > supports "--etags-include=" or "-i " for includes.
Okay, one more try. I hadn't added etags.m4 to the Makefile.am so it wasn't being
in
"Derek R. Price" wrote:
> "Derek R. Price" wrote:
>
> > I added the etags support to my RPMs:
>
> I regenerated them again using todays version of the CVS Automake since the
> failing vtexi.test wasn't a bug.
And one more try. etags.m4 wasn
Tom Tromey wrote:
> >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> Hmm. I'm running RH 6.2 and /usr/bin/etags is the GNU version:
I just looked into it and it looks like etags was distributed with the
version of emacs (20.5) t
Tom Tromey wrote:
> I wouldn't be averse to adding a `pdf' target so that `make pdf' works
> as expected. Someone else would have to write it though since I don't
> know how.
It should be the exact target used for DVI except for the addition of a
'--pdf' switch to the texi2dvi command line. I'
Raja R Harinath wrote:
> BTW, why do you need to 'configure' or 'sed' substitute a version
> number into a .c file -- you already have config.h which defines the
> symbol 'VERSION' to the version number string.
That's a good point. They're there because I just converted this source to use
Autom
"Derek R. Price" wrote:
> Raja R Harinath wrote:
>
> > BTW, why do you need to 'configure' or 'sed' substitute a version
> > number into a .c file -- you already have config.h which defines the
> > symbol 'VERSION' to the version
Tom Tromey wrote:Derek> Apparently BSD wants something like the following:
> Derek> .include "file"
> Derek> or
> Derek> .include
>
> Yuck. Does make have -I options too?
Don't know. I didn't actually have a BSD box until last week and I haven't
touched it over the last few days. I'l
Whoops. Missed a list.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
He who laughs last thinks slowest.
Harlan Stenn wrote:
> /bin/sh: : not found
> WARNING: `:' is needed, an
Found another bug in automake's support for dependencies using BSD's make. This
one is based on the fact that BSD make doesn't allow comments to continue on the
next line using '\'. I just hooked into the existing conditional machinery
instead of stuffing "\@AMDEP\@" as the first item in the DEP
"Derek R. Price" wrote:
> Okay, I fixed this as well as all the special casing of '.' that the code is
> littered with FIXME comments about. I've included ChangeLog entries in the patch
> as well as a new test case, but here's a bit more detail:
Is
It seems some BSD makes don't look through VPATH for targets either
(i.e. when they're not found in $(builddir) make assumes they are
missing and rebuilds).
Mostly this isn't a problem, but there are a few cases where it is. For
example, info targets are rebuilt every time and I can't create a
*
Tom Tromey wrote:
> The idea behind DOCUMENTATION is to provide a way to install README
> and the other stuff that ends up (eg) in /usr/doc/$PACKAGE.
Just a note, I believe the RedHat standard is /usr/share/doc now.
Derek
--
Derek Price CVS Solutions Architect ( http://CVS
Geoffrey Wossum wrote:
> I was thinking about this, and I considered another possibility. autopkg
> would scan the Makefile.am to build a basic specfile, which the developer
> could then add pre/post install scripts and so forth. This would be
> analogous to autoscan producing a basic configure
Tom Tromey wrote:
> Unfortunately, I don't think it is that easy.
>
> First, Makefile.am contents can be conditional on the particular
> configuration. That is why you really want to deal with the
> post-configuration package (using `make') and not Makefile.am.
>
> Second, the more complex post-
Geoffrey Wossum wrote:
> > You can use GNU m4 or PERL in autoconf and automake, as these are
> > maintainer-only tools. If autopackage is a package-installer tool (i.e. a
> > native package front-end) the choice of implementation language is almost
> > restricted to "/bin/sh" or "/bin/sh" and pro
Harlan Stenn wrote:
> Are there several issues here?
>
> The package maintainer has the package to worry about.
Aha! Here's the crossed wire. What I was envisioning was a package tool
designed such that most platforms wouldn't _need_ devoted package maintainers.
A single package maintainer usi
Michael Sweet wrote:
> Rusty Ballinger wrote:
> > ...
> > (What packaging systems only let you create packages as root, and
> > why do they do that? I know rpm *wants* you to be root, but you
> > don't have to be...)
>
> Debian's dpkg needs you to run as root; otherwise the files you
> install w
Akim Demaille wrote:
> So, I think I'm slowly starting to understand this VPATH stuff:
> configure wants to remove it only when useless, right? I.e., when
> VPATH is just set to srcdir? So then, I'm in favor of Derek's patch
> which seems finer that the current one, and updating the Autoconf
>
"Derek R. Price" wrote:
> Akim Demaille wrote:
>
> > VPATH is just set to srcdir? So then, I'm in favor of Derek's patch
> > which seems finer that the current one, and updating the Autoconf
> > documentation to explain exactly what happens.
>
>
Why do automake stamp targets go through all the trouble of creating a
temporary stamp file before executing config.status and then moving the
stamp file into the correct position?
thirdfile.h: stamp-h3
@if test ! -f $@; then \
rm -f stamp-h3; \
Akim Demaille wrote:
> | It is fine to `cvs add' a file so that `cvs diff -N' creates the
> | correct diff. This applies generally -- if you don't have cvs write
> | access there is a script you can get that will do a phony `cvs add' by
> | manipulating CVS/Entries.
>
> Oh, I didn't know that, t
stamp-h? files in subdirs are still being created in the wrong locations
by an automake configure script. The problem was in AM_CONFIG_HEADERS.
I fixed it, but is dependent on the autoconf beta. Patch attached.
I was thinking of attempting to eliminate the need for the recreation of
stamp-h? fi
"Derek R. Price" wrote:
> stamp-h? files in subdirs are still being created in the wrong locations
> by an automake configure script. The problem was in AM_CONFIG_HEADERS.
> I fixed it, but is dependent on the autoconf beta. Patch attached.
>
> I was thinking of at
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.
Tim Van Holder wrote:
> >(_AM_DIRNAME): helper function which basically implements an sh
> >`dirname` in m4
> Only have 1 problem with it: no support for DOS-style paths (and this is
> conveniently not tested in your dirname.test either :-P).
Yeah, sorry. I noticed that, but I d
Tom Tromey wrote:
> >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> Derek> by an automake configure script. The problem was in
> Derek> AM_CONFIG_HEADERS. I fixed it, but is dependent on the
> Derek> autoconf beta.
>
&g
[EMAIL PROTECTED] wrote:
> But in the very same function, if I use $_ instead of @_, which is
> what the following line does:
$_ isn't set upon function entry in perl. Only @_. The value of your $_ is left over
from
somewhere.
By the way, I think I have amtraces 99% working. Are we going to
"Derek R. Price" wrote:
> [EMAIL PROTECTED] wrote:
>
> > But in the very same function, if I use $_ instead of @_, which is
> > what the following line does:
>
> $_ isn't set upon function entry in perl. Only @_. The value of your $_ is left
>over f
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:
Since _all_ AC_SUBSTs are being processed now, at least one instance
where Automake was allowing for user override is now broken.
The case in question is the
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
[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
"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 inclu
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> @DE
"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.
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_
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
"Derek R. Price" wrote:
> > > +# This macro handles several different things.
> > > +AM_INIT_AUTOMAKE =>
> > > + sub { $seen_make_set = $_[0];
> > > + $seen_arg_prog = $_[0];
> > > + $seen_prog_
Somebody checked in a bad quote recently. It breaks at least the
stamph/header targets. Patch attached.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
82. Hold a hard drive to your ea
Inspired by Akim Demaille's use of ifdef, I wrote a third edition of
this patch which increases functionality when used with a current
Autoconf.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.co
"Derek R. Price" wrote:
> Inspired by Akim Demaille's use of ifdef, I wrote a third edition of
> this patch which increases functionality when used with a current
> Autoconf.
I just wanted to let you all know that.
...
Ok, fine, here's the patc
"Derek R. Price" wrote:
> Looks like someone broke the 'make dist' target in the last few days.
> Specifically, input files from AC_OUTPUT are no longer being added to
> DIST_COMMON...
Here's the patch.
Derek
--
Derek Price CVS Soluti
"Derek R. Price" wrote:
> "Derek R. Price" wrote:
>
> > Looks like someone broke the 'make dist' target in the last few days.
> > Specifically, input files from AC_OUTPUT are no longer being added to
> > DIST_COMMON...
>
> Here's t
Pavel Roskin wrote:
> Hello, Derek!
>
> > > > Looks like someone broke the 'make dist' target in the last few days.
>
> I also noticed that.
>
> > > > Specifically, input files from AC_OUTPUT are no longer being added to
> > > > DIST_COMMON...
>
> Exactly the same problem.
>
> > > Here's the patc
Pavel Roskin wrote:
> The new test fails exactly how it should. I'm going to apply it unless you
> come with something better.
Well, you should have seen my slightly more succinct version by now. I'd say
check them both in, as there is some logic that says it'd be nice to be able
to notice the
Tom Tromey wrote:
> Anyway I wrote a test for the weird case and checked it in.
>
> I also checked in a fix for both the recent bugs in that area. I'm
> afraid I'm not entirely sure why my fix fixes distcommon.test :-(.
Checked in? Fixes? I'm not pulling any changes...
Derek
--
Derek Price
Tom Tromey wrote:
> > "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
>
> >> I'm checking this in.
>
> Pavel> I'm sorry, but the bug seems to be yours. The new test fails
> Pavel> after automake.in changes from revision 1.848 to 1.849.
>
> Oh, I know it is mine..
>
> Pavel> In fact it say
Tom Tromey wrote:
> Derek> Checked in? Fixes? I'm not pulling any changes...
>
> I can't explain that. I've seen the commit message and everything.
>
> You aren't using the subversions automake are you?
> That is a mirror that doesn't update.
Yeah, I am. Where is the other one?
Derek
--
De
"Derek R. Price" wrote:
> Tom Tromey wrote:
>
> > Derek> Checked in? Fixes? I'm not pulling any changes...
> >
> > I can't explain that. I've seen the commit message and everything.
> >
> > You aren't using the subversions
Pavel Roskin wrote:
> On 7 Feb 2001, Tom Tromey wrote:
>
> > I've long considered it a mistake that tests/ChangeLog exists. I
> > think it should be merged with the main ChangeLog.
> >
> > How about I rename tests/ChangeLog and we start putting entries into
> > the toplevel ChangeLog? Any objec
Tom Tromey wrote:
> >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> Derek> Also, looking at this area of the code reminds me that I sent
> Derek> a, unfortunately largish, patch in something over a month ago
> Derek> th
Tom Tromey wrote:
> >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> Derek> Also, looking at this area of the code reminds me that I sent
> Derek> a, unfortunately largish, patch in something over a month ago
> Derek> th
Backwards compatible support for the new AC_INIT.
ChangeLog entry:
* m4/init.m4 (AM_INIT_AUTOMAKE): If AC_PACKAGE_NAME &
AC_PACKAGE_VERSION
are set, use those to set PACKAGE & VERSION in lieu of arguments.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHo
Why do the AC_CANONICAL_* functions no longer set *_alias? There's a
FIXME comment and fixing it would be a matter of removing the 'dnl', as
far as I can see and the CVS Automake is still expecting *_alias to be
set:
# _AC_CANONICAL_SPLIT(THING)
# --
# Generate the variab
Is there a good reason that Automake renames the three variables set by
AC_CANONICAL_* ('build', 'host', & 'target') to 'build_triplet', 'host_triplet',
& 'target_triplet'?
Because using the current traces design, 'build', 'host', & 'target' would be
substituted automatically, allowing removal/si
I've removed the references to $seen_canonical, re one of the FIXME
comments on the way to enabling traces. I know this patch is kinda
largish, but even if it doesn't get checked in yet, I'd like some
feedback. This is somewhat integral to my work on traces.
Derek
--
Derek Price
Tim Van Holder wrote:
> >> >* remake-hdr.am (@STAMP@): Use .T as suffix for the
> >> >temporary file.
> >>
> >> You should probably patch autoconf's autoreconf too.
> >
> > > What part would need patching?
> >
> > The one that choose stamp file names like those created by automake.
>
> Ri
Tom Tromey wrote:
> > "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
>
> Tim> 2001-02-10 Tim Van Holder <[EMAIL PROTECTED]>
>
> Tim>* remake-hdr.am (@STAMP@): Use .T as suffix for the
> Tim>temporary file.
>
> I don't think this is sufficient. I think you also have to change
>
Pavel Roskin wrote:
> Hello, Derek!
>
> On Fri, 9 Feb 2001, Derek R. Price wrote:
>
> > Why do the AC_CANONICAL_* functions no longer set *_alias? There's a
>
> "cvs annotate" and "cvs log" are your friends. Akim did it. But the log
> mes
Tom Tromey wrote:
> >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> Derek> Is there a good reason that Automake renames the three
> Derek> variables set by AC_CANONICAL_* ('build', 'host', &
Akim Demaille wrote:
> What is the general policy wrt `optimizations' in automake vs leaving
> some job to make? For instance there are many places with code like:
>
> if ($relative_dir eq '.')
> {
> push (@files, 'acconfig.h');
>
>From tests/defs:
# User can set which tools from Autoconf to use.
test -z "$AUTOCONF" && AUTOCONF=autoconf
if ($AUTOCONF --version) >/dev/null 2>&1; then
has_autoconf=:
needs_autoconf=:
else
has_autoconf=false
needs_autoconf='exit 77'
fi
Wha
"Derek R. Price" wrote:
> AUTOCONF='exit 77 &&'
Excuse me:
AUTOCONF='exit 77 && dummy'
to keep the parser eternally happy.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL
"Derek R. Price" wrote:
> "Derek R. Price" wrote:
>
> > AUTOCONF='exit 77 &&'
>
> Excuse me:
>
> AUTOCONF='exit 77 && dummy'
>
> to keep the parser eternally happy.
Or almost eternally happy.
1 - 100 of 132 matches
Mail list logo
