stamph processing fix
Hi! Akim told me awhile back to port forward and resubmit some patches if I noticed that they hadn't been accepted after some time had passed. Anyway, it's been awhile, so here's a resubmission of the patch that fixes the stamp-h? processing which configure is currently doing. Basically, the old configure creates the initial stamp files in the wrong places. This fixes that as well as adding support for a more concise, less loopy, more correctly placed, and less knowledgable (it doesn't need to check for existance of directories and create them sometimes) configure script when AC_FOREACH is available. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- It does me no injury for my neighbor to say there are twenty gods or no god. It neither picks my pocket nor breaks my leg. - Thomas Jefferson ? tmp.diff Index: ChangeLog === RCS file: /cvs/automake/automake/ChangeLog,v retrieving revision 1.1448 diff -u -r1.1448 ChangeLog --- ChangeLog 2001/07/03 04:19:35 1.1448 +++ ChangeLog 2001/07/03 15:46:09 @@ -1,3 +1,12 @@ +2001-07-02 Derek Price [EMAIL PROTECTED] + + * m4/header.m4 (AM_CONFIG_HEADER): Create stamp-h files in the correct + locations. + * tests/dirname.test: New test. + * tests/stamph2.test: New test. + * tests/Makefile.am: Add new tests. + * tests/Makefile.in: Regenerated. + 2001-07-02 Tom Tromey [EMAIL PROTECTED] Fix for libtool2.test: Index: m4/header.m4 === RCS file: /cvs/automake/automake/m4/header.m4,v retrieving revision 1.7 diff -u -r1.7 header.m4 --- header.m4 2000/08/06 12:36:53 1.7 +++ header.m4 2001/07/03 15:46:10 @@ -10,19 +10,57 @@ AC_PREREQ([2.12]) AC_DEFUN([AM_CONFIG_HEADER], +[ifdef([AC_FOREACH],dnl +[dnl init our file count if it isn't already +m4_ifndef([_AM_Config_Header_Index], m4_define([_AM_Config_Header_Index], +[0])) +dnl prepare to store our destination file list for use in config.status +AC_FOREACH([_AM_File], [$1], + [m4_pushdef([_AM_Dest], m4_patsubst(_AM_File, [:.*])) + m4_define([_AM_Config_Header_Index], +m4_incr(_AM_Config_Header_Index)) + dnl and add it to the list of files AC keeps track of, along + dnl with our hook + AC_CONFIG_HEADERS(_AM_File, +dnl COMMANDS, [, INIT-CMDS] +[# update the timestamp +echo timestamp AS_ESCAPE(_AM_DIRNAME(]_AM_Dest[))/stamp-h]_AM_Config_Header_Index[ +][$2]m4_ifval([$3], [, [$3]]))dnl AC_CONFIG_HEADERS + m4_popdef([_AM_Dest])])],dnl [AC_CONFIG_HEADER([$1]) AC_OUTPUT_COMMANDS( ifelse(patsubst([$1], [[^ ]], []), [], [test -z $CONFIG_HEADERS || echo timestamp dnl - patsubst([$1], [^\([^:]*/\)?.*], [\1])stamp-h]), - [am_indx=1 - for am_file in $1; do -case $CONFIG_HEADERS in -* $am_file *) - echo timestamp `echo $am_file | sed 's%:.*%%;s%[^/]*$%%'`stamp-h$am_indx - ;; -esac -am_indx=\`expr \$am_indx + 1\` - done]) -]) + patsubst([$1], [^\([^:]*/\)?.*], [\1])stamp-h]),dnl +[am_indx=1 +for am_file in $1; do + case \$CONFIG_HEADERS in + * \$am_file *) +am_dir=\`echo \$am_file |sed 's%:.*%%;s%[^/]*\$%%'\` +if test -n \$am_dir; then + am_tmpdir=\`echo \$am_dir |sed 's%^\(/*\).*\$%\1%'\` + for am_subdir in \`echo \$am_dir |sed 's%/% %'\`; do +am_tmpdir=\$am_tmpdir\$am_subdir/ +if test ! -d \$am_tmpdir; then + mkdir \$am_tmpdir +fi + done +fi +echo timestamp \$am_dirstamp-h\$am_indx +;; + esac + am_indx=\`expr \$am_indx + 1\` +done]) +])]) # AM_CONFIG_HEADER + +# _AM_DIRNAME(PATH) +# - +# Like AS_DIRNAME, only do it during macro expansion +AC_DEFUN([_AM_DIRNAME], + [m4_if(m4_regexp([$1], [^.*[^/]//*[^/][^/]*/*$]), -1, + m4_if(m4_regexp([$1], [^//\([^/]\|$\)]), -1, + m4_if(m4_regexp([$1], [^/.*]), -1, + [.], + m4_patsubst([$1], [^\(/\).*], [\1])), + m4_patsubst([$1], [^\(//\)\([^/].*\|$\)], [\1])), + m4_patsubst([$1], [^\(.*[^/]\)//*[^/][^/]*/*$], [\1]))[]dnl +]) # _AM_DIRNAME Index: tests/Makefile.am === RCS file: /cvs/automake/automake/tests/Makefile.am,v retrieving revision 1.319 diff -u -r1.319 Makefile.am --- Makefile.am 2001/07/03 04:19:36 1.319 +++ Makefile.am 2001/07/03 15:46:10 @@ -101,6 +101,7 @@ depend2.test \ depend3.test \ depend4.test \ +dirname.test \ discover.test \ distcommon.test \ distdir.test \ @@ -247,6 +248,7 @@ spell3.test \ spelling.test \ stamph.test \ +stamph2.test \ stdlib.test \ subdir.test \
Re: depcomp problem [Fwd: Trying to compile latest CVS on old SCO unixware 2]
Stephen Cameron wrote:
It's getting a bit weird now,
Making all in lib
source='argmatch.c' object='argmatch.o' libtool=no \
depfile='.deps/argmatch.Po' tmpdepfile='.deps/argmatch.TPo' \
depmode=none /bin/sh ../depcomp \
../compile cc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I../src -g -c
-o argmatch.o `test -f argmatch.c || echo './'`argmatch.c
UX:as: ERROR: (EOF):cannot open output file: argmatch.o: Is a directory
Say what?!?
The test system probably had ofile defaulting to ./argmatch.o or somesuch...
So now I try ineptly patching compile which gets me a little further, loads
of .c files compile, but:
--- compile.origMon Jun 18 05:09:55 2001
+++ compile Mon Jun 18 05:11:53 2001
@@ -47,8 +47,18 @@
done
test -z $ofile {
- echo compile: no \`-o' option seen 12
- exit 1
+ if [ $cfile = ]
+ then
+ echo compile: no \`-o' option seen, and no .c file. 12
+ exit 1
+ else
+ ofile=`echo $cfile | sed -e s/\.c$/.o/`
+ if [ $ofile = $cfile ]
+ then
+ echo compile: could not guess .o file from .c file: $cfile
+ exit 1
+ fi
+ fi
}
test -z $cfile {
This sounds suspicious, perhaps a symptom of a bug in the makefile rules if you
realy needed it - compile is designed to work around a problem with -o and -c
being used at the same time, so it shouldn't be called without -o or -c...
@@ -60,7 +70,7 @@
cofile=`echo $cfile | sed -e 's|^.*/||' -e 's/\.c$/.o/'`
# Create the lock directory.
-lockdir=`echo $ofile | sed -e 's|/|_|g'`
+lockdir=`echo $ofile.lock | sed -e 's|/|_|g'`
while true; do
if mkdir $lockdir /dev/null 21; then
break
Okay, but I have a nitpick. You shouldn't need the quotes around $ofile.lock:
$ofile.lock should be sufficient.
Then running make again:
[]
UX:mv: ERROR: version.o and version.o are identical
../compile cc -g -o cvs add.o admin.o annotate.o buffer.o
checkin.o checkout.o classify.o client.o commit.o create_adm.o cvsrc.o diff.o
edit.o entries.o error.o expand_path.o fileattr.o filesubr.o find_names.o
hardlink.o hash.o history.o ignore.o import.o lock.o log.o login.o logmsg.o
main.o mkmodules.o modules.o myndbm.o no_diff.o parseinfo.o patch.o rcs.o
rcscmds.o recurse.o release.o remove.o repos.o root.o run.o scramble.o
server.o status.o subr.o tag.o update.o vers_ts.o watch.o wrapper.o zlib.o
../diff/libdiff.a ../lib/libcvs.a ../zlib/libz.a version.o -lsocket -lgen
compile: no `.c' file seen
Okay, this sounds like an Automake bug now. I suspect compile shouldn't be called
for linking... only when both -o and -c are specified. I'm cc'ing Automake again.
Automake folks: I've included a revised patch for the lockdir line as I'm pretty
sure you'll want that bit whatever else comes out of this.
Hmmm. At this point I have to wonder if this compile script is all it's
cracked up to be. It doesn't seem to be able to use cc to just link...(and my
patch is wrong in that area too.)For that matter, compile may be generated by
automake for all I know.
And, BTW, that [UX:mv: ERROR: x.o and x.o are identical appears for pretty
much every file that gets compiled...
And I wonder about the line in the script:
$prog $args
Would that have problems with quoted arguments passed into the script? Not that
cvs would run into that, but still.
Actually, I think it would, but the source of the problem is the loop that
constructs $args, not this call. I've included a patch for this too.
Feel free to forward this email to the automake list, if that's a more
appropriate destination.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
Round up the usual suspects.
- Claude Rains as Captain Louis Renault, _Casablanca_
Index: ChangeLog
===
RCS file: /cvs/automake/automake/ChangeLog,v
retrieving revision 1.1430
diff -u -r1.1430 ChangeLog
--- ChangeLog 2001/06/18 01:08:34 1.1430
+++ ChangeLog 2001/06/18 18:29:45
@@ -1,3 +1,9 @@
+2001-06-18 Derek Price [EMAIL PROTECTED]
+ Stephen Cameron [EMAIL PROTECTED]
+
+ * lib/compile: Make sure lockdir doesn't have the same name as the
+ object file.
+
2001-06-17 Tom Tromey [EMAIL PROTECTED]
* automake.in (require_file_internal): Check for already-required
Index: lib/compile
===
RCS file: /cvs/automake/automake/lib/compile,v
retrieving revision 1.3
diff -u -r1.3 compile
--- compile 2000/10/16 09:01:36 1.3
+++ compile 2001/06/18 18:29:46
@@ -60,7 +60,7 @@
cofile=`echo $cfile | sed -e 's|^.*/||' -e 's/\.c$/.o/'`
# Create the lock directory.
-lockdir=`echo $ofile | sed -e 's|/|_|g'`
+lockdir=`echo $ofile.lock | sed -e 's|/|_|g'`
while
depcomp problem [Fwd: Trying to compile latest CVS on old SCO unixware 2]
Sounds like this could be fixed in depcomp? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Very funny Scotty, now beam down my clothes! Hi, I'm Trying to update an old SCO unixware 2 box...Currently I have CVS 1.10.8 there. (Yeah, shame on me) The cc's -o option refuses to overwrite existing .o files...: scameron@unixdev 208 $ make UX:make: WARNING: No suffix list. make all-recursive UX:make: WARNING: No suffix list. Making all in lib source='argmatch.c' object='argmatch.o' libtool=no \ depfile='.deps/argmatch.Po' tmpdepfile='.deps/argmatch.TPo' \ depmode=none /bin/sh ../depcomp \ cc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I../src -g -c -o argmatch.o `test -f argmatch.c || echo './'`argmatch.c UX:cc: ERROR: -o would overwrite argmatch.o *** Error code 1 (bu21) UX:make: ERROR: fatal error. *** Error code 1 (bu21) UX:make: ERROR: fatal error. *** Error code 1 (bu21) UX:make: ERROR: fatal error. I could edit the Makefile, but I know that's not the best way... (Maybe the best way is for me to install gcc, etc...) Any other thoughts? -- steve __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: aclocal doesn't check AUTOMAKE_OPTIONS (VERSION)
Akim Demaille wrote: Tom == Tom Tromey [EMAIL PROTECTED] writes: Tom We're planning to get rid of aclocal in the future. I forget Tom exactly what form that plan takes. Akim knows. First of all, the responsibility will move to Autoconf, aclocal has nothing to do with Automake. The main plan is to get rid of aclocal.m4 too, and to include, at the M4 level, all the m4/*.m4 files which are needed. This is doable, we actually have a proto since months. Wrt this actual problem, I'm afraid there will always have some problems due to incorrectly synchronized sets of tools :( In the future Automake will read the traces. We perfectly can imagine a macro to declare an Automake requirement, and automake checking this requirement. Conversely, hm... I dunno. How about something as simple as allowing a version to be specified in an *.m4 file. Then if the macro version is less than the version of the copy in the m4 dir then autoconf won't copy the new (old) version over m4/* unless forced? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Travel advisories - Alaska: Tourists are warned to wear tiny bells on their clothing when hiking in bear country. The bells warn away MOST bears. Tourists are also cautioned to watch the ground on the trail, paying particular attention to bear droppings, to be alert for the presence of Grizzly Bears. One can tell Grizzly droppings by the tiny bells in them.
Re: AC_CONFIG_AUX_DIR now required when mdate-sh resides in subdir?
Jim Meyering wrote: Hi Derek, Recently, automake changed so that I get the following in fileutils-4.1, even though I've put a copy of mdate-sh (though not in the official tarball) in doc/. $ automake --gnits --include-deps doc/Makefile.am:2: required file `./mdate-sh' not found I don't use AC_CONFIG_AUX_DIR. The last time I checked, I found it didn't work because some of those aux files live at the top level, and others (like mdate-sh and texinfo.tex) belong in doc/. That's the way AC_CONFIG_AUX_DIR is defined. It allows for the relocation of _all_ of the auxiliary files used in configuration. This can be decidedly convenient if you have two doc directories for some reason. An explicit exception was made for texinfo.tex, but only when AC_CONFIG_AUX_DIR isn't set explicitly. I would guess that a similar exception for mdate-sh would be acceptable if others thought it a good idea. I don't know much about it, but glancing through the code seems to confirm that an exception wouldn't hurt. My glance through the code also seems to confirm that this shouldn't be too hard to accomplish. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- May the forces of evil become confused on the way to your house. -- George Carlin
Re: possible bug with depcomp
Akim Demaille wrote: "Robert" == Robert Collins [EMAIL PROTECTED] writes: Robert The project I'm converting to automake uses Robert AC_CONFIG_AUX_DIR(cfgaux). The dependency cehcking code was Robert looking for depend in the srcdir, not the srcdir/cfgaux. I'm Robert using a cvs version of autoconf - it's possible they've Robert changed the variables used... Robert Anyway, I've worked around it by dnl'ing the AC_CONFIG_AUX_DIR Robert directive. Funny thing was, when I did that and ran automake Robert --foreign --add-missing -c, it installed depcomp into "lib/", Robert but all the other scripts into ".". It's a known bug, and it's really painful. Derek has posted a fix, but we are still waiting for the FSF's agreement. IIRC, The workaround was to not let AM install depcomp itself but to stuff it into '.' or cfgaux as appropriate. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- I will not waste chalk. I will not waste chalk. I will not waste chalk... - Bart Simpson on chalkboard, _The Simpsons_
Re: Default postscript cleans miss *.cps *.fns.
Akim Demaille wrote:
"Tom" == Tom Tromey [EMAIL PROTECTED] writes:
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim elsif (/^\@(syncode|print)index \w+ (\w*)/) { push
Akim @clean_suffixes, "$1s";
Tom Shouldn't that be "$2s" here?
Yes, definitely. Thanks!
Neither one worked. I grepped for "@(syncode|print)index" in CVS's
texinfo source and got the following:
@printindex cp
Are the two \w segments above a typo or maybe just not the general case?
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
It'll take a miracle to get you out of Casablanca and the Germans have outlawed
miracles.
- Sydney Greenstreet as Senor Ferrari, _Casablanca_
Re: Default postscript cleans miss *.cps *.fns.
Akim Demaille wrote:
elsif (/^\@syncodeindex \w+ (\w*)/
|| /^\@printindex (\w+)/)
{
push @clean_suffixes, "$1s";
}
Yep. That works.
IIRC, you also had problems with fns. What does a `grep fn *texi*' gives?
Not much obviously useful, but you prompted me to look in the cvs.fns file.
Except for the first line, lines are of the form:
\entry {\code {command}}{index}
Where command is variable and index is a number. Using `fgrep -w "command"
*.texi*' reveals that each command has a corresponding texinfo command like
the following in the manual:
@deffn Command {command} ...
where `Command' (with a capital 'C') is a literal and ... varies. `fgrep -w
deffn' reveals:
cvs.texinfo:@deffn Command {cvs add} [@code{-k} kflag] [@code{-m}
message] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs remove} [options] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs annotate} [@code{-flR}] [@code{-r
rev}|@code{-D date}] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs watch on} [@code{-lR}] files
@dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs watch off} [@code{-lR}] files
@dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs watch add} [@code{-a} action]
[@code{-lR}] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs watch remove} [@code{-a} action]
[@code{-lR}] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs edit} [options] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs unedit} [@code{-lR}] files @dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs watchers} [@code{-lR}] files
@dots{}
cvs.texinfo:@end deffn
cvs.texinfo:@deffn Command {cvs editors} [@code{-lR}] files @dots{}
cvs.texinfo:@end deffn
Which is the same order the entries appear in cvs.fns. Glancing at the
texinfo manual reveals that `Command' is a category argument and not
literal. Will that do the trick?
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
It is as useless to argue with those who have renounced the use and authority
of reason as to administer medication to the dead.
- Thomas Jefferson
Re: overriding tested automake aclocal in test suite
Tom Tromey wrote:
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek Is there some reason the automake test suite doesn't allow the
Derek user to override its AUTOMAKE ACLOCAL variables? I like to
Derek do it on ocassion to compare the current behavior against my
Derek installed version and the like.
No, there's no reason. Send a patch...
Attached.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
I will not carve gods.
I will not carve gods.
I will not carve gods...
- Bart Simpson on chalkboard, _The Simpsons_
Index: defs
===
RCS file: /cvs/automake/automake/tests/defs,v
retrieving revision 1.23
diff -u -r1.23 defs
--- defs2001/03/04 21:05:09 1.23
+++ defs2001/03/23 21:30:05
@@ -71,7 +71,7 @@
# See how Automake should be run. We put --foreign as the default
# strictness to avoid having to create lots and lots of files. A test
# can override this by specifying a different strictness.
-AUTOMAKE="$PERL ../../automake --amdir=$srcdir/.. --foreign"
+: ${AUTOMAKE-"$PERL ../../automake --amdir=$srcdir/.. --foreign"}
# See how aclocal should be run.
-ACLOCAL="$PERL ../../aclocal --acdir=$srcdir/../m4"
+: ${ACLOCAL-"$PERL ../../aclocal --acdir=$srcdir/../m4"}
Re: overriding tested automake aclocal in test suite
Tom Tromey wrote: "Derek" == Derek R Price [EMAIL PROTECTED] writes: Derek Is there some reason the automake test suite doesn't allow the Derek user to override its AUTOMAKE ACLOCAL variables? Thanks for the patch. I wrote a ChangeLog entry for you. Could you write it next time? Yep. Sorry about that. Busy day. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- This is the fourth? - Thomas Jefferson's last words (he died on the 4th of July)
depcomp bug (was [Fwd: CVS update: ccvs])
Hey folks! One of the other CVS developers reported a bug in depcomp on BSD/OS. Apparently the included /bin/sh doesn't set $? inside of the conditional. His original message and fix are attached. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Boy: A noise with dirt on it Derek R. Price writes: * depcomp: Don't count on $? being set in then or else clauses. What system is this happening on? depcomp is part of the Automake distribution. Boy, that was fast! I was going to send you a message suggesting that you pass that change on to the Automake folks, but you beat me to it. It happens on my BSD/OS system with bin/sh (but not with bash or ksh). Looking at the SUS-2 specs for sh: http://www.opengroup.org/onlinepubs/7908799/xcu/chap2.html I don't see any requirement that the exit status of the conditional be available in $? in the then and else clauses and given one counter example and the fact that it's easy enough to work around, it seems like the prudent thing to do. -Larry Jones He's just jealous because I accomplish so much more than he does. -- Calvin Index: depcomp === RCS file: /home2/cvsroot/ccvs/depcomp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- depcomp 2000/12/21 22:14:19 1.1 +++ depcomp 2001/04/04 18:21:01 1.2 @@ -61,9 +61,9 @@ if test -z "$gccflag"; then gccflag=-MD, fi - if "$@" -Wp,"$gccflag$tmpdepfile"; then : - else -stat=$? + "$@" -Wp,"$gccflag$tmpdepfile" + stat=$? + if test $stat != 0; then rm -f "$tmpdepfile" exit $stat fi @@ -102,9 +102,9 @@ # trick. Instead we must use -M and then rename the resulting .d # file. This is also the case for older versions of gcc, which # don't implement -Wp. - if "$@" -MD; then : - else -stat=$? + "$@" -MD + stat=$? + if test $stat != 0; then rm -f FIXME exit $stat fi @@ -118,9 +118,7 @@ "$@" -MDupdate "$tmpdepfile" fi stat=$? - if test $stat -eq 0; then : - else -stat=$? + if test $stat != 0; then rm -f "$tmpdepfile" exit $stat fi
Re: Default postscript cleans miss *.cps *.fns.
Akim Demaille wrote: | Akim Demaille wrote: | | Could you `grep indexcode' your texi sources? Thanks! | | [dprice@empress doc]$ fgrep indexcode cvs.texinfo | [dprice@empress doc]$ Actually I meant _all_ your sources. And in fact, @include would be useful too. Sorry for the delay in response. I'm just catching up on this list and the cc went to the account I'm not using anymore. [dprice@empress doc]$ ls *.t*x* CVSvn.texi CVSvn.texi.in cvs.texinfo cvsclient.texi texinfo.tex [dprice@empress doc]$ egrep 'indexcode|@include' *.t*x* cvsclient.texi:@include CVSvn.texi cvs.texinfo:@include CVSvn.texi texinfo.tex:% @include fileinsert text of that file as input. texinfo.tex: % Read the included file in a group so nested @include's work. texinfo.tex:% they're defined in; @include reads the file inside a group. [dprice@empress doc]$ I wasn't sure whether you wanted texinfo.tex included and there wasn't much output, so I left it in. FYI: the *.cps *.fns files are only being created for cvs.texinfo. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Where are we going? And what's with this handbasket?
Re: FYI: On the way to -w
Akim Demaille wrote:
Tom Tromey [EMAIL PROTECTED] writes:
What remains in order to enable `use strict'?
[. . .]
$require_file_found{'depcomp'} = 1 if -f "$depcomp_dir/depcomp";
it is because of this guy. It should not be used directly here, but
to fix this properly, I have to understand how to use the regular
mechanisms (i.e., study what you said about the special case of
depcomp not being like missing and the like).
We could use use strict right now *if* we declare %require_file_found
is global. But I didn't because it's a lie, it's not where we are
going to.
I sent a patch a while ago, ostensibly to fix the depcomp support, but which
cleans up a bunch of the require_file stuff, including removing this line. And
oh, was it a mess before I went at it.
You should have the rest of the asssignments necessary to use it shortly. I
mailed them Monday evening. I can even resubmit a new version which resolves the
current conflicts, I believe, as long as I do it on my own time. I'm not sure how
long it'll be before I can do automake work on my day job again. :)
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
On every question of construction [of the Constitution], let us carry ourselves
back to the time when the Constitution was adopted, recollect the spirit
manifested in the debates, and instead of trying what meaning may be squeezed
out of the text, or invented against it, conform to the probable one in which
it was passed.
- Thomas Jefferson, letter to William Johnson,
June 12, 1823, _The Complete Jefferson_, p. 322.
Default postscript cleans miss *.cps *.fns.
Building postscript docs from *.texi sources using the default automake targets, the dev version of CVS produces cvs.cps cvs.fns files as side effects. These files aren't removed by 'make clean' and thus break a distcheck. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- "I tried to think but nothing happened!" - Curly
Re: Default postscript cleans miss *.cps *.fns.
Akim Demaille wrote: hi Derek, Hi. :) Could you `grep indexcode' your texi sources? Thanks! [dprice@empress doc]$ fgrep indexcode cvs.texinfo [dprice@empress doc]$ Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- If thou dost marry, I'll give thee this plague for thy dowry: be thou as chaste as ice, as pure as snow, thou shalt not escape calumny. Get thee to a nunnery. Go, farewell. Or if thou wilt needs marry, marry a fool. For wise men know well enough what monsters you make of them. To a nunnery, go, and quickly, too. Fare- well. - Hamlet, Act III, Scene 1, Lines 135-141
Re: yaccvpath.test
Alexandre Oliva wrote:
On Feb 28, 2001, "Derek R. Price" [EMAIL PROTECTED] wrote:
CVS uses a single second sleep to guarentee timestamps change cross-platform
IIRC, FAT filesystems can only store even second numbers. So, in
order to be 100% safe, you'd need to sleep for 2 seconds, but a
1-second sleep should be ok on at least 50% of the cases.
I don't think so. The CVS code does the following, regardless of the platform:
while (last_register_time time ((time_t *) NULL) == last_register_time)
{
* sleep 20ms *
}
Where last_register_time is the last time a file was written (recorded just after
writing).
In other words, this code simply waits until the next second. I don't usually
work on the Windows specific code myself, but everything here except the sleep
function is common code, and unless the clock and not just the file system has a
2 second granularity, then a race condition would have been created. I haven't
seen the bug reports and I know for a fact that the Windows sleep function was
just recently rewritten to allow millisecond granularity, so the rest is
doubtful.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
I will not celebrate meaningless milestones.
I will not celebrate meaningless milestones.
I will not celebrate meaningless milestones...
- Bart Simpson on chalkboard, _The Simpsons_
Re: Current problems
Akim Demaille wrote:
# Now do all the work on each file.
foreach my $am_file (@input_files)
{
if (! -f ($am_file . '.am'))
{
am_error ("\`" . $am_file . ".am' does not exist");
}
else
{
generate_makefile ($output_files{$am_file}, $am_file);
}
}
and there is a sub:
# Print an error message and set exit status.
sub am_error
{
warn "$me: ${am_file}.am: @_\n";
$exit_status = 1;
}
Only a global is going to be seen within a separate function...
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
I will not hide behind the Fifth Amendment.
I will not hide behind the Fifth Amendment.
I will not hide behind the Fifth Amendment...
- Bart Simpson on chalkboard, _The Simpsons_
Re: Current problems
Akim Demaille wrote: "Derek R. Price" [EMAIL PROTECTED] writes: Only a global is going to be seen within a separate function... Right, but `my' at the top level is a global. The problem was really related to the specific semantics of foreach. Huh. You're right. I didn't believe you, but I just went and tested it myself. :) Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- There are two major products to come out of Berkley: LSD and UNIX. We don't believe this to be a coincidence.
Re: yaccvpath.test
Pavel Roskin wrote: Some unices (including GNU/Linux) are not very precise with respect to the timestamps. It's likely that parse.c and the new parse.y are created in the same second, so parse.c will appear to be up-to-date. Adding "sleep 3" (I have no idea what would be a minimal safe time) before the new CVS uses a single second sleep to guarentee timestamps change cross-platform and we don't see bug reports about it. Only ocassionaly complaints that scripts which invoke CVS many times take too long. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- "A slipping gear could let your M203 grenade launcher fire when you least expect it. That would make you quite unpopular in what's left of your unit." -- In the August 1993 issue, page 9, of PS magazine, the Army's magazine of preventive maintenance
Re: subdirs.am and $(RECURSIVE_TARGETS)
Tom Tromey wrote: "Akim" == akim [EMAIL PROTECTED] writes: Akim I wonder why we have a hard coded list list this in subdirs.am: Akim [ ... -recursive targets ... ] Historical reasons only, ie, I never thought of it. Akim Not only to I find this more pleasant, but most importantly it's Akim a win for Automake (we can have more modular *.am files which Akim register their own recursive targets), and it's a win for users Akim who can += on RECURSIVE_TARGETS. In the not-too-distant past, you couldn't `+=' an internally-defined variable. I feel the need to point out that the -recursive portions of the targets in the RECURSIVE_TARGETS macro seem somewhat redundant since users would be required to end any new targets they wished to add to RECURSIVE_TARGETS with the same string due to the way recursive targets are defined. i.e. a user should be able to add RECURSIVE_TARGETS += mytarget thus implicitly defining mytarget mytarget-recursive, and mytarget would call mytarget-local, mytarget-recursive, mytarget-hook as appropriate. Of course I don't have my head nearly deep enough in those implementation details at the moment to even start detailing how I would code the above. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- "Very funny Scotty, now beam down my clothes!"
Re: 57-my-last-mying-changes.patch
Tom Tromey wrote:
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim Six, six for them! (I'm not counting those for file handles,
Akim which perl refuses as my, not sure to understand why).
The way file handles work is another reason to dislike Perl. At
least, I've always found them confusing.
The Perl5 file handles are different. This example is for reading a file.
Really, the arguments to "new" are the same arguments open accepted.:
require 5.004;
use IO::File;
my $fh = new IO::File " filetoread";
while ($fh-getline)
{
dostuff $_;
}
The other functions available for old style file handles are similar. These
are just front ends for the old Perl builtins, but context switching just
happens automatically now. e.g. $fh-eof, $fh-print, $fh-open (usually
called implicitly with arguments to new), $fh-close (unnecessary - "undef
$fh" will autoclose), $fh-autoflush, $fh-fileno, etc.
"$fh-getlines;" will work like calling $fh in an array context.
"my $line = $fh-getline;" "my @lines = $fh-getlines;" (to read an entire
file) are valid constructs. I don't remember if the same was true of , but
I think so.
P.S. You probably won't need to know, but Perl5 prior to 5.004 used
FileHandle in lieu of IO::File, and FileHandle is still supported as a front
end for IO::File, but is deprecated.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
As honest as the day is long.
- S. Z. Sakall as Headwaiter Carl, _Casablanca_
Re: PATCH: patsubst support
Tom Tromey wrote: if FOO var = a b endif derived = $(var:%=%.c) if BAR var = c d endif Isn't the order irrelevant here since derived won't be evaluated until it's used? Um, the gmake manual calls this "expanded when read, except for the shell commands in rules, the right-hand sides of variable definitions using `=', and the bodies of variable definitions using the `define' directive". Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.
tests graceful tool dependencies
From tests/defs: # User can set which tools from Autoconf to use. test -z "$AUTOCONF" AUTOCONF=autoconf if ($AUTOCONF --version) /dev/null 21; then has_autoconf=: needs_autoconf=: else has_autoconf=false needs_autoconf='exit 77' fi What's preventing you from removing the needs_autoconf variable entirely and assigning something like AUTOCONF='exit 77 ' in the case that autoconf is missing or broken? It removes a step and becomes transparent when a test doesn't want to test $has_autoconf. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not burp in class. I will not burp in class. I will not burp in class... - Bart Simpson on chalkboard, _The Simpsons_
Re: tests graceful tool dependencies
"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 PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Every man's reason [is] his own rightful umpire. This principle, with that of acquiescence in the will of the majority, will preserve us free and prosperous as long as they are sacredly observed. - Thomas Jefferson to John F. Watson, 1814
Re: tests graceful tool dependencies
"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. Due to some wierdness where my Bash only evaluates a variable as a single command (i.e. ignoring ';', '', '||'), the following was necessary: test='eval exit 77 dummy' This does the Right Thing (tm) in all the following cases: $test ($test) $test -args and -more args :; $test; dummy; more : $test : || $test false || $test false $test $test : $test || : $test false $test || false if $test; then :; fi I expect more parens aren't going to change anything. Did I miss anything? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- The policy of the American government is to leave their citizens free, neither restraining nor aiding them in their pursuits. - Thomas Jefferson
Re: tests graceful tool dependencies
"Derek R. Price" wrote: test='eval exit 77 dummy' Whoops. Excuse me. That works in every case except ($test). The subshell created by parens breaks things. I guess that isn't all that robust. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not sleep through my education. I will not sleep through my education. I will not sleep through my education... - Bart Simpson on chalkboard, _The Simpsons_
Re: Testsuite fails
Akim Demaille wrote: Pavel Roskin [EMAIL PROTECTED] writes: We probably need a special macro, e.g. AC_REQUIRE_FILE, so that the macros will be able to indicate what files they need. This is what Derek and I are working on :) But I doubt 2.50 will be the good starting point, 2.51 will. Incidentally, I think we're going to need AM_ALL_LINGUAS or the like to replace the simple ALL_LINGUAS variable set. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. - Larry Wall
Redundant PACKAGE VERSION set in test suite?
Is there a good reason that the following constructs occasionally appear in 'configure.in's as created by the test suite? AM_INIT_AUTOMAKE(nonesuch, nonesuch) PACKAGE=nonesuch VERSION=nonesuch Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- "If triangles had a God, He'd have three sides." -- Old Yiddish Proverb
Re: Optimizing Makefiles
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');
}
else
{
push (@files, '$(top_srcdir)/acconfig.h');
}
While it certainly more elegant from the Makefile point of view, it
results in many little places in automake where the core code is
``polluted''. Don't we want to continue like this?
Aside from optimization, there's another diffrence in the above. The
first will be looked for in VPATH and the second won't be when
$(top_srcdir) is absolute. Not sure this matters.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
Always glad to share my ignorance - I've got plenty.
Re: Small autoreconf patch
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. Right - I hadn't noticed this: stamp_num=`test "$tcount" -gt 1 echo "$tcount"` stamp=$template_dir/stamp-h$stamp_num.in once tcount becomes larger than 9, there are potential problems. Now: a) how likely is it that tcount becomes 10 or more? When AM_CONFIG_HEADER is called on more than 9 headers. b) what impact does using a different name (e.g. st-h-$stamp.in) have? Jut namespace impact and aestetic concerns, I believe, but you may want to hear from someone else on this one. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I don't know what's right any longer! You have to think for both of us - for all of us! - Ingrid Bergman as Elsa, _Casablanca_
Re: Patch 3 of 4: Avoid 8+3 filename trouble
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 Timtemporary file. I don't think this is sufficient. I think you also have to change AM_CONFIG_HEADER as well. See m4/header.m4. Which is already broken and effectively unused. The only reason things were working is that the make targets recreated the stamp files anyhow. I've submitted a patch to fix this already. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- "It's difficult to work in a group when you're omnipotent." -Q, "Deja Q"
AC_CANONICAL_* *_triplet
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/simplification of some code once AC
2.13 is no longer supported, if the rename was unnecessary. This would include
removal of the following FIXME comment and associated code:
# Generate some useful variables when AC_CANONICAL_* used. FIXME:
# this should use generic %configure_vars method.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
I will not sell school property.
I will not sell school property.
I will not sell school property...
- Bart Simpson on chalkboard, _The Simpsons_
removing $seen_canonical
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 CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
Once Law was sitting on the bench
And Mercy knelt a-weeping.
"Clear out!" he cried, "disordered wench!
Nor come before me creeping.
Upon you knees if you appear,
'Tis plain you have no standing here."
Then Justice came. His Honor cried:
"YOUR states? -- Devil seize you!"
"Amica curiae," she replied --
"Friend of the court, so please you."
"Begone!" he shouted -- "There's the door --
I never saw your face before!"
-- Ambrose Bierce, "The Devil's Dictionary"
Index: ChangeLog
===
RCS file: /cvs/automake/automake/ChangeLog,v
retrieving revision 1.1014
diff -u -r1.1014 ChangeLog
--- ChangeLog 2001/02/10 01:26:54 1.1014
+++ ChangeLog 2001/02/10 05:06:50
@@ -1,3 +1,7 @@
+2001-02-10 Derek Price [EMAIL PROTECTED]
+
+ * automake.in: Replace $seen_canonical with %configure_vars.
+
2001-02-09 Raja R Harinath [EMAIL PROTECTED]
* depcomp (gcc3): Propagate exit code.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.872
diff -u -r1.872 automake.in
--- automake.in 2001/02/09 07:06:53 1.872
+++ automake.in 2001/02/10 05:06:54
@@ -191,10 +191,6 @@
# TRUE if AC_DECL_YYTEXT was seen.
$seen_decl_yytext = 0;
-# TRUE if we've seen AC_CANONICAL_(HOST|SYSTEM). The presence of
-# AC_CHECK_TOOL also sets this.
-$seen_canonical = 0;
-
# TRUE if we've seen AC_ARG_PROGRAM.
$seen_arg_prog = 0;
@@ -606,10 +602,14 @@
@libtoolize_files)
if $seen_libtool;
-# AC_CANONICAL_HOST and AC_CANONICAL_SYSTEM need config.guess and
-# config.sub.
+ # AC_CANONICAL_BUILD, AC_CANONICAL_HOST, and
+ # AC_CANONICAL_(SYSTEM|TARGET) need config.guess and config.sub.
+ #
+ # FIXME - When traces is enabled, only 'build' need be checked here
+ # since AC_CANONICAL_BUILD is required by AC_CANONICAL_HOST, which is
+ # required by AC_CANONICAL_TARGET, as of AC 2.50..
require_config_file ($FOREIGN, 'config.guess', 'config.sub')
- if $seen_canonical;
+ if $configure_vars{'build'} || $configure_vars{'host'};
}
# We still need Makefile.in here, because sometimes the `dist'
@@ -3932,29 +3932,18 @@
. "\t\@echo 'set tool \$(DEJATOOL)' \$\@-t\n"
. "\t\@echo 'set srcdir \$(srcdir)' \$\@-t\n"
. "\t\@echo 'set objdir' \`pwd\` \$\@-t\n");
-
-# Extra stuff for AC_CANONICAL_*
-local (@whatlist) = ();
-if ($seen_canonical)
-{
-push (@whatlist, 'host');
-}
-# Extra stuff only for AC_CANONICAL_SYSTEM.
-if ($seen_canonical == $AC_CANONICAL_SYSTEM)
+ my $c;
+ foreach $c ('build', 'host', 'target')
{
-push (@whatlist, 'target', 'build');
+ # Maybe an error message if both of these are not set is a good
+ # idea? It might be overkill.
+ $output_rules .= "\t\@echo 'set ${c}_triplet \$(${c})' \$\@-t\n"
+ if defined $configure_vars{$c};
+ $output_rules .= "\t\@echo 'set ${c}_alias \$(${c}_alias})' \$\@-t\n"
+ if defined $configure_vars{"${c}_alias"};
}
-local ($c1, $c2);
-foreach $c1 (@whatlist)
-{
-foreach $c2 ('alias', 'triplet')
-{
-$output_rules .= "\t\@echo 'set ${c1}_${c2} \$(${c1}_${c2})'
\$\@-t\n";
-}
-}
-
$output_rules .= ("\t\@echo '## All variables above are generated by
configure. Do Not Edit ##' \$\@-t\n"
. "\t\@test ! -f site.exp || sed '1,/^## All variables
above are.*##/ d' site.exp \$\@-t\n"
. "\t\@test ! -f site.exp || mv site.exp site.bak\n"
@@ -4228,6 +4217,21 @@
}
+
+# found_ac_canonical_x ($x, $where)
+# --
+# Helper function which sets %configure_vars for an AC_CANONICAL_* invocation
+sub found_ac_canonical_x
+{
+my $c;
+foreach $c ('', '_alias', '_cpu', '_vendor', '_os')
+{
+ $configure_vars{$_[0] . $c} = $_[1];
+}
+}
+
+
+
# scan_one_autoconf_file ($FILENAME)
# ---
# Scan one file for interesting things. Subroutine of
@@ -,12 +4448,25 @@
}
}
-# Handle AC_CANONICAL_*. Always allow upgrading to
-#
Re: DIST_COMMON broke
"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 the patch. This doesn't appear to be the correct fix. I'll write the test case Tom just requested and see if I can't figure out anymore. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- 77. (D)inner not ready: (A)bort, (R)etry, (P)izza?
Re: DIST_COMMON broke
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 CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Travel advisories - Alaska: Tourists are warned to wear tiny bells on their clothing when hiking in bear country. The bells warn away MOST bears. Tourists are also cautioned to watch the ground on the trail, paying particular attention to bear droppings, to be alert for the presence of Grizzly Bears. One can tell Grizzly droppings by the tiny bells in them.
Re: DIST_COMMON broke
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 says directly: "Don't push @inputs onto the dist list."
Pavel Not good. Many programs rely on that.
It is more complicated than that. The require_file_with_conf_line
call sometimes pushes onto the dist list.
This area still requires more work. I think I know another case where
it can fail: suppose you do `AC_OUTPUT(subdir/foo)' where there is no
Makefile.am in subdir? Then I think no rule to rebuild subdir/foo
will be generated.
You're right. Here's a test for that too. Well, if you still want it, re
Pavel's recent email.
Just a note, some of the logic you just mentioned seems to be in
maybe_push_required_file, but I haven't studied require_file_internal long
enough to know what it's supposed to be doing.
Also, looking at this area of the code reminds me that I sent a,
unfortunately largish, patch in something over a month ago that hasn't been
reviewed to my knowledge. The patch was intended to fix a misplaced depcomp
file (a bug which is still present in the current CVS Automake, I might
add), but I had also ended up removing all the "special case '.'" bugs the
code is littered with FIXME comments about (especially around the
require_file_* functions). I have only had to alter the patch once (well,
okay, so the test was also broken and I fixed that too), so far, to keep it
in sync with the CVS Automake, but with all the work going on lately this
might get worse. If somebody could review it and maybe check it in it would
be greatly appreciated. It cleans up a bunch of code. I'll include the new
patch in a subsequent email.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
If that plane leaves the ground and you're not with him, you'll regret it.
Maybe not today and maybe not tomorrow, but soon and for the rest of your life.
- Humphrey Bogart as Rick, _Casablanca_
#! /bin/sh
# A test for failure to include files and targets provided in AC_OUTPUT
# when the subdir doesn't contain a Makefile.am
. $srcdir/defs || exit 1
cat configure.in EOF
AM_INIT_AUTOMAKE(nonesuch, nonesuch)
AC_OUTPUT(subdir/bar \
Makefile)
EOF
: Makefile.am
mkdir subdir
: subdir/bar.in
$AUTOMAKE || exit 1
# verify bar.in
grep '^subdir/bar.in:' Makefile.in || exit 1
# yeah, so it eats _all_ the backslashes...
sed '/\\$/{N;s/\\.//g;}' testSubDir/Makefile.in \
|grep '^DIST_COMMON.*subdir/bar.in' Makefile.in || exit 1
exit 0
Re: DIST_COMMON broke
"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 automake are you? That is a mirror that doesn't update. Yeah, I am. Where is the other one? Nevermind. Found it from the Automake home page. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- 89. A day without sunshine is like, you know, night.
Re: tests/ChangeLog
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 objections? No objections. In fact, by having two ChangeLogs GNU Automake "endorses" its users to use this style. This should be fixed. Looks like you need to regenerate the Makefile.in - you broke make dist: [dprice@empress automake-clean]$ make dist chmod -R a+w automake-1.4c /dev/null 21; rm -rf automake-1.4c mkdir automake-1.4c /bin/sh ./mkinstalldirs automake-1.4c/. . for subdir in . m4 tests; do \ if test "$subdir" = .; then :; else \ test -d automake-1.4c/$subdir \ || mkdir automake-1.4c/$subdir \ || exit 1; \ (cd $subdir \ make top_distdir=../automake-1.4c distdir=../automake-1.4c/$subdir distdir) \ || exit 1; \ fi; \ done make[1]: Entering directory `/home/dprice/work/automake-clean/m4' make[1]: Leaving directory `/home/dprice/work/automake-clean/m4' make[1]: Entering directory `/home/dprice/work/automake-clean/tests' make[1]: *** No rule to make target `ChangeLog', needed by `distdir'. Stop. make[1]: Leaving directory `/home/dprice/work/automake-clean/tests' make: *** [distdir] Error 1 Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not bring sheep to class. I will not bring sheep to class. I will not bring sheep to class... - Bart Simpson on chalkboard, _The Simpsons_
Re: DIST_COMMON broke
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 that hasn't been reviewed to my knowledge. The patch was Derek intended to fix a misplaced depcomp file (a bug which is still Derek present in the current CVS Automake, I might add), but I had Derek also ended up removing all the "special case '.'" bugs the code Derek is littered with FIXME comments about (especially around the Derek require_file_* functions). Yeah, I still have a few of your patches sitting in my mailbox. We have to get the assignment stuff worked out. I've been putting that off since I hate dealing with it. I got some preliminary email in that direction from Brian Youmans @gnu.org the other day. I filled out the email form and returned it. The original mail said that would get me the next set of forms, but I haven't seen them yet, nor, in fact, received any reply at all. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- For sale: One parachute. Never opened. Small stain.
Re: DIST_COMMON broke
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 that hasn't been reviewed to my knowledge. The patch was Derek intended to fix a misplaced depcomp file (a bug which is still Derek present in the current CVS Automake, I might add), but I had Derek also ended up removing all the "special case '.'" bugs the code Derek is littered with FIXME comments about (especially around the Derek require_file_* functions). Yeah, I still have a few of your patches sitting in my mailbox. Well, when you get around to it, this one should take the place of my last depcomp patch. I fixed tests/depcomp, tidied the ChangeLog based on the standards and practices Raja Akim made me aware of, and merged the rest with the current CVS Autoconf. ChangeLog entry: * automake.in (require_file_with_conf_line, require_file_with_line, require_file): Pass a @require_file_path of $relative_dir instead of '.' to require_file_internal so that all the special casing of '.' can be removed elsewhere. (require_config_file, require_conf_file_with_line, require_conf_file_with_conf_line): Remove special casing for '.' and make sure $config_aux_dir is maintained properly. (require_file_internal): Remove special casing of '.' and set @require_file_path when missing files are added. (maybe_push_required_file): Remove special casing of '.' (handle_dependencies): Remove a workaround for a bug now fixed and remove $config_aux_dir special casing. (handle_configure): Remove special casing for $config_aux_dir (handle_python): Ditto. (yacc_lex_finish_helper): Change $config_aux_dir switch to switch on the value of $config_aux_dir_set_in_configure_in. (handle_texinfo): Ditto. (scan_one_configure_file): Set $config_aux_dir and $config_aux_dir_set_in_configure_in properly so special casing on the value of $config_aux_dir can be removed elsewhere. * tests/depcomp.test: New file. * tests/confsub.test: Look for depcomp in $(top_srcdir) instead of the first subdir containing a C file. * tests/libobj2.test: Ditto. * tests/Makefile.am (TESTS): Added 'depcomp.test'. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not aim for the head. I will not aim for the head. I will not aim for the head... - Bart Simpson on chalkboard, _The Simpsons_ Index: ChangeLog === RCS file: /cvs/automake/automake/ChangeLog,v retrieving revision 1.1001 diff -u -r1.1001 ChangeLog --- ChangeLog 2001/02/07 21:51:39 1.1001 +++ ChangeLog 2001/02/07 23:27:58 @@ -522,6 +522,35 @@ * automake.in (handle_ltlibraries): Allow _LDFLAGS to be conditionally defined. Fixes PR automake/77 and ldflags.test. +2000-12-05 Derek Price [EMAIL PROTECTED] + + * automake.in (require_file_with_conf_line, + require_file_with_line, require_file): Pass a @require_file_path + of $relative_dir instead of '.' to require_file_internal so that + all the special casing of '.' can be removed elsewhere. + (require_config_file, require_conf_file_with_line, + require_conf_file_with_conf_line): Remove special casing for '.' + and make sure $config_aux_dir is maintained properly. + (require_file_internal): Remove special casing of '.' and set + @require_file_path when missing files are added. + (maybe_push_required_file): Remove special casing of '.' + (handle_dependencies): Remove a workaround for a bug now fixed + and remove $config_aux_dir special casing. + (handle_configure): Remove special casing for $config_aux_dir + (handle_python): Ditto. + (yacc_lex_finish_helper): Change $config_aux_dir switch to + switch on the value of $config_aux_dir_set_in_configure_in. + (handle_texinfo): Ditto. + (scan_one_configure_file): Set $config_aux_dir and + $config_aux_dir_set_in_configure_in properly so special casing + on the value of $config_aux_dir can be removed elsewhere. + + * tests/depcomp.test: New file. + * tests/confsub.test: Look for depcomp in $(top_srcdir) instead of the + first subdir containing a C file. + * tests/libobj2.test: Ditto. + * tests/Makefile.am (TESTS): Added 'depcomp.test'. + 2000-11-25 Tom Tromey [EMAIL PROTECTED] * automake.in (file_contents_with_transform): Added file name and Index: automake.in === RCS file: /cvs/automake/automake/automake.in,v retrieving revision 1
AM_CONFIG_HEADER stamp-h files edition 3
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.com ) -- 99. Daddy, why doesn't this magnet pick up this floppy disk?
Re: AM_CONFIG_HEADER stamp-h files edition 3
"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 patch. :) Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- 99. Daddy, why doesn't this magnet pick up this floppy disk? ? automake-stamph3.diff ? automake-1.4c-stamph3.diff ? tests/automake-1.4c-stamph3.diff Index: ChangeLog === RCS file: /cvs/automake/ChangeLog,v retrieving revision 1.997 diff -u -r1.997 ChangeLog --- ChangeLog 2001/02/06 10:25:21 1.997 +++ ChangeLog 2001/02/06 18:07:37 @@ -77,6 +77,10 @@ about libtool, and maintainer-clean. * clean.am, libtool.am: Handle these. +2001-02-05 Derek Price [EMAIL PROTECTED] + + * m4/header.m4 (AM_CONFIG_HEADER): create stamp-h files in the correct + locations. 2001-02-05 Akim Demaille [EMAIL PROTECTED] Index: m4/header.m4 === RCS file: /cvs/automake/m4/header.m4,v retrieving revision 1.7 diff -u -r1.7 header.m4 --- m4/header.m42000/08/06 12:36:53 1.7 +++ m4/header.m42001/02/06 18:07:39 @@ -10,19 +10,57 @@ AC_PREREQ([2.12]) AC_DEFUN([AM_CONFIG_HEADER], +[ifdef([AC_FOREACH],dnl +[dnl init our file count if it isn't already +m4_ifndef([_AM_Config_Header_Index], m4_define([_AM_Config_Header_Index], +[0])) +dnl prepare to store our destination file list for use in config.status +AC_FOREACH([_AM_File], [$1], + [m4_pushdef([_AM_Dest], m4_patsubst(_AM_File, [:.*])) + m4_define([_AM_Config_Header_Index], +m4_incr(_AM_Config_Header_Index)) + dnl and add it to the list of files AC keeps track of, along + dnl with our hook + AC_CONFIG_HEADERS(_AM_File, +dnl COMMANDS, [, INIT-CMDS] +[# update the timestamp +echo timestamp "AS_ESCAPE(_AM_DIRNAME(]_AM_Dest[))/stamp-h]_AM_Config_Header_Index[" +][$2]m4_ifval([$3], [, [$3]]))dnl AC_CONFIG_HEADERS + m4_popdef([_AM_Dest])])],dnl [AC_CONFIG_HEADER([$1]) AC_OUTPUT_COMMANDS( ifelse(patsubst([$1], [[^ ]], []), [], [test -z "$CONFIG_HEADERS" || echo timestamp dnl - patsubst([$1], [^\([^:]*/\)?.*], [\1])stamp-h]), - [am_indx=1 - for am_file in $1; do -case " $CONFIG_HEADERS " in -*" $am_file "*) - echo timestamp `echo $am_file | sed 's%:.*%%;s%[^/]*$%%'`stamp-h$am_indx - ;; -esac -am_indx=\`expr \$am_indx + 1\` - done]) -]) + patsubst([$1], [^\([^:]*/\)?.*], [\1])stamp-h]),dnl +[am_indx=1 +for am_file in $1; do + case " \$CONFIG_HEADERS " in + *" \$am_file "*) +am_dir=\`echo \$am_file |sed 's%:.*%%;s%[^/]*\$%%'\` +if test -n "\$am_dir"; then + am_tmpdir=\`echo \$am_dir |sed 's%^\(/*\).*\$%\1%'\` + for am_subdir in \`echo \$am_dir |sed 's%/% %'\`; do +am_tmpdir=\$am_tmpdir\$am_subdir/ +if test ! -d \$am_tmpdir; then + mkdir \$am_tmpdir +fi + done +fi +echo timestamp "\$am_dir"stamp-h\$am_indx +;; + esac + am_indx=\`expr \$am_indx + 1\` +done]) +])]) # AM_CONFIG_HEADER + +# _AM_DIRNAME(PATH) +# - +# Like AS_DIRNAME, only do it during macro expansion +AC_DEFUN([_AM_DIRNAME], + [m4_if(m4_regexp([$1], [^.*[^/]//*[^/][^/]*/*$]), -1, + m4_if(m4_regexp([$1], [^//\([^/]\|$\)]), -1, + m4_if(m4_regexp([$1], [^/.*]), -1, + [.], + m4_patsubst([$1], [^\(/\).*], [\1])), + m4_patsubst([$1], [^\(//\)\([^/].*\|$\)], [\1])), + m4_patsubst([$1], [^\(.*[^/]\)//*[^/][^/]*/*$], [\1]))[]dnl +]) # _AM_DIRNAME Index: tests/Makefile.am === RCS file: /cvs/automake/tests/Makefile.am,v retrieving revision 1.248 diff -u -r1.248 Makefile.am --- tests/Makefile.am 2001/02/04 03:18:01 1.248 +++ tests/Makefile.am 2001/02/06 18:07:39 @@ -88,6 +88,7 @@ depacl2.test \ depend.test \ depend3.test \ +dirname.test \ discover.test \ distdir.test \ double.test \ @@ -226,6 +227,7 @@ spell3.test \ spelling.test \ stamph.test \ +stamph2.test \ stdlib.test \ subdir.test \ subdir2.test \ Index: tests/dirname.test === RCS file: tests/dirname.test diff -N tests/dirname.test --- /dev/null Tue Aug 29 07:25:14 2000 +++ tests/dirname.test Tue Feb 6 10:07:39 2001 @@ -0,0 +1,46 @@ +#! /bin/sh + +# Test the operation of the _AM_DIRNAME macro from m4/header.m4 + +. $srcdir/defs || exit 1
Bug + patch
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 ear -- listen to the C.
? automake-1.4c.tar.gz
? automake-1.4c.acconfig_h.diff
Index: ChangeLog
===
RCS file: /cvs/automake/ChangeLog,v
retrieving revision 1.992
diff -u -r1.992 ChangeLog
--- ChangeLog 2001/02/05 09:11:10 1.992
+++ ChangeLog 2001/02/06 04:19:20
@@ -1,3 +1,7 @@
+2001-02-05 Derek Price [EMAIL PROTECTED]
+
+ * automake.in (handle_configure): fix syntax error
+
2001-02-05 Akim Demaille [EMAIL PROTECTED]
* automake.in (handle_texinfo): No longer hard code the clean
Index: automake.in
===
RCS file: /cvs/automake/automake.in,v
retrieving revision 1.859
diff -u -r1.859 automake.in
--- automake.in 2001/02/05 09:11:10 1.859
+++ automake.in 2001/02/06 04:19:24
@@ -3387,7 +3387,7 @@
{
# Strange quoting because this gets fed through
# Perl.
- push (@files, '\$(top_srcdir)/acconfig.h');
+ push (@files, '$(top_srcdir)/acconfig.h');
}
}
Re: amtraces
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
AC_CANONICAL_HOST -
/tmp/ac23991/stdin:1:AC_CANONICAL_SYSTEM:
/tmp/ac23991/stdin:1:AC_CANONICAL_HOST:
i.e., drop AC_CANONICAL_SYSTEM *dead*.
Are you sure? I poked through the code a bit and it looks like AC_CANONICAL_SYSTEM is
now an alias
for AC_CANONICAL_TARGET which requires AC_CANONICAL_HOST but sets some extra variables
which AM seems
to have handlers for as part of its AC_CANONICAL_SYSTEM handling...
+# Some things required by Automake.
+AC_ARG_PROGRAM = sub { $seen_arg_prog = $_[0] },
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?
+AM_C_PROTOTYPES = sub { $am_c_prototypes = $_[0] },
Should be moved to an Autoconf macro.
+AC_CHECK_TOOL = \scan_autoconf_traces_AC_CANONICAL_HOST,
Sounds wrong: you don't need AC_CANONICAL_HOST to use AC_CHECK_TOOL.
+AM_CONDITIONAL = sub { $configure_cond{$_[2]} = $_[0] },
+AC_CONFIG_AUX_DIR = sub { @config_aux_path = $_[2] },
This macro gives too many problem. Alexandre D. knows what I'm
referring to, I'd like him to start a thread in autoconf@ about this.
Let me know when there's a fix I can use. My basic premise was to convert
scan_one_autoconf_file as
directly as possible while removing the redundancies I could spot.
+AC_CONFIG_FILES = sub { scan_autoconf_config_files ($_[2]) },
+# Handle configuration headers
+AC_CONFIG_HEADER = \scan_autoconf_traces_AC_CONFIG_HEADER,
+AC_CONFIG_HEADERS = \scan_autoconf_traces_AC_CONFIG_HEADER,
+AM_CONFIG_HEADER = \scan_autoconf_traces_AM_CONFIG_HEADER,
Nope, they all point to only AC_CONFIG_HEADERS. Don't trace the others.
This works for AC_CONFIG_HEADERS, but not for AM_CONFIG_HEADER. AM requires
AM_CONFIG_HEADERS to be
used so it needs to catch the call to AC_CONFIG_HEADER so it can warn the user about
their mistake.
+AC_DECL_YYTEXT =
+ sub { unless ($seen_decl_yytext eq $_[0])
+ {
+ $seen_decl_yytext = $_[0];
+ am_conf_line_warning (
+ split (/:/, $_[0]),
+ "\`AC_DECL_YYTEXT' is covered by \`AM_PROG_LEX'");
+ }
+ },
No longer exists, there is only AC_PROG_LEX which includes this.
AM_PROG_LEX is deprecated.
I added obsolete and deprecated warnings for AC_DECL_YYTEXT and AM_PROG_LEX,
respectively.
AC_PROG_LEX is still setting the $seen_decl_yytext variable. Maybe someone will want
to change the
name? I added a comment to this effect.
+AM_ENABLE_MULTILIB = sub { $seen_multilib = $_[0] },
+AC_EXEEXT = sub { $seen_exeext = 1 },
No longer exists, exeext is always computed when there is some
compilation involved, i.e., when Automake wants to use exeext and
obkext, don't check for them: they've been checked for. Or just look
at $ac_subst{EXEEXT}.
Changed the areas in the code to look for $configure_vars{EXEEXT} instead of
$seen_exeext. If these
are always checked for then maybe when tracing is required the special casing can be
removed
entirely.
+# Check for NLS support.
+AM_GNU_GETTEXT =
+ sub { # FIXME: eliminate redundant $ac_gettext_line
+ $seen_gettext = $_[0];
+ $ac_gettext_line = (split /:/, $_[0])[1];
+ },
Why does it need to know this? Hm, will look into the details some day.
+# 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];
+ $package_version_line = (split /:/, $_[0])[2];
+ $seen_init_automake = $_[0];
+ },
Not good: --trace looks inside, you don't need to know how
AM_INIT_AUTOMAKE is written and what it does. And now the proper
means to set the name/version of a package is via AC_INIT, more
precisely tracing _AC_INIT_PACKAGE. Note that we can introduce a
macro just to ask for the value of an Autoconf macro:
I will examine this more closely. The INSTALL and MAKE_SET stuff I removed already.
/tmp % cat configure.ac nostromo 14:40
AC_INIT(GNU Hello, 1.0)
m4_define([_AC_TRACE])
m4_define([AC_TRACE], [_AC_TRACE(m4_defn([$1]))])
AC_TRACE([AC_PACKAGE_NAME])
AC_TRACE([AC_PACKAGE_TARNAME])
AC_TRACE([AC_PACKAGE_STRING])
AC_TRACE([AC_PACKAGE_VERSION])
/tmp % ace -t _AC_TRACE
Re: 31-ac-libsources.patch Re: amtraces
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. (AC_LIBSOURCES, AC_LIBSOURCE): New. AC_REPLACE_FUNCS is still trying to call AC_LIBOBJ_DECL. :( Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will finish what I sta I will finish what I sta I will finish what I sta... - Bart Simpson on chalkboard, _The Simpsons_
Re: amtraces
[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 around the things I was
still working on.
I'm really impressed! Your work is impressive, congratulations! I'm
Thanks. :) I tried to write a macro for CVS which made use of AC_FOREACH and
Automake couldn't handle it anymore. I had to do _something_.
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 probably should too, seeing as I've been hacking on CVS for a
couple of years now. :) Can someone send them to me? I'd actually be
interested in learning the maintainer side of the process too since I'm probably
supposed to be doing some of this for CVS, if anyone could send me a link?
I'd make one simple comment: I would not trust `:' as a separator, I'd
play with more unlikely separators. See the Autoconf documentation,
I figured, but : was already being used and seems to work well enough in most
cases. If you look at my code, it should be easy to change the default. You can
even change the FORMAT string on a per-macro basis by tweaking the
%traced_macro_format hash. I've only had to do that for AC_CONFIG_FILES so far,
since that's the only macro my test base was passing arguments to in dest:source
format, but I imagine it would be necessary for AC_CONFIG_HEADER and any other
macro that takes filename arguments in that format. Maybe tweaking the default
to something like you suggest would be easiest:
The long SEPARATORs can be used to ease parsing of complex structures:
$ autoconf -t 'AM_MISSING_PROG:${|:|}*'
ACLOCAL|:|aclocal|:|$missing_dir
AUTOCONF|:|autoconf|:|$missing_dir
AUTOMAKE|:|automake|:|$missing_dir
More traces deleted
On a side note, I think we could move to the multi-line inputs if we needed to
with only a little extra work, but right now my code still counts on single line
inputs.
Now I think the structure of the comp-vars.am will need to be changed to
define some var other than DEFS to @DEFAULT_INCLUDES@ and then that var
should be included as part of the COMPILE makefile variable.
I didn't look into the details, but can't we have some variable initialized
in the top of configure.in which trigger this default behavior?
If I understood what you are suggesting, I don't think so, because the
information is stored in several of the template files. Well, you could, but
I don't think switching between template files is the right idea here. Anyhow,
as I understand things, the change I am suggesting shouldn't break backwards
compatibility. I just wanted to see if an Automake guru could confirm that I was
on the right track.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
That liberty [is pure] which is to go to all, and not to the few or the rich
alone.
- Thomas Jefferson to H. Gates, 1798.
Re: amtraces
"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 probably should too, seeing as I've been hacking on CVS for a couple of years now. :) Can someone send them to me? I'd actually be interested in learning the maintainer side of the process too since I'm probably supposed to be doing some of this for CVS, if anyone could send me a link? 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. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I wouldn't bring up Paris right now. It's poor salesmanship. - Humphrey Bogart as Rick, _Casablanca_
patch: stamp-h? files in subdirs
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? files in the Makefile.in targets, but it looked like a hassle
to get the quotes right in an m4 macro. If there's interest in this,
let me know and I'll spend some more time on it.
* m4/header.m4 (AM_CONFIG_HEADERS): fix stamp-h creation to
occur in
the correct locations
(_AM_DIRNAME): helper function which basically implements an sh
`dirname` in m4
* automake.in (scan_one_autoconf_file): change the warning
exception
for AC_CONFIG_HEADERS to match the new m4/header.m4
* stamph2.test: new
* dirname.test: new
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
The cafeteria deep fryer is not a toy.
The cafeteria deep fryer is not a toy.
The cafeteria deep fryer is not a toy...
- Bart Simpson on chalkboard, _The Simpsons_
? automake-1.4c-stamph.diff
? m4/acheader.m4.sav
? tests/stamph2.test
? tests/dirname.test
Index: ChangeLog
===
RCS file: /cvs/automake/ChangeLog,v
retrieving revision 1.963
diff -u -r1.963 ChangeLog
--- ChangeLog 2001/01/31 04:05:43 1.963
+++ ChangeLog 2001/01/31 19:10:27
@@ -1,3 +1,12 @@
+2001-01-31 Derek Price [EMAIL PROTECTED]
+
+ * m4/header.m4 (AM_CONFIG_HEADERS): fix stamp-h creation to occur in
+ the correct locations
+ (_AM_DIRNAME): helper function which basically implements an sh
+ `dirname` in m4
+ * automake.in (scan_one_autoconf_file): change the warning exception
+ for AC_CONFIG_HEADERS to match the new m4/header.m4
+
2001-01-30 Tom Tromey [EMAIL PROTECTED]
* automake.in (scan_one_autoconf_file): Don't mention
Index: automake.in
===
RCS file: /cvs/automake/automake.in,v
retrieving revision 1.839
diff -u -r1.839 automake.in
--- automake.in 2001/01/31 04:00:45 1.839
+++ automake.in 2001/01/31 19:10:31
@@ -4576,7 +4576,7 @@
# means we are actually scanning AM_CONFIG_HEADER from
# aclocal.m4.
if (/A([CM])_CONFIG_HEADERS?\s*\((.*)\)/
-$2 ne '[$1]')
+$2 !~ /^_AM_File,/)
{
am_conf_line_error
($filename, $., "\`automake requires \`AM_CONFIG_HEADER', not
\`AC_CONFIG_HEADER'")
Index: m4/header.m4
===
RCS file: /cvs/automake/m4/header.m4,v
retrieving revision 1.7
diff -u -r1.7 header.m4
--- m4/header.m42000/08/06 12:36:53 1.7
+++ m4/header.m42001/01/31 19:10:31
@@ -1,3 +1,5 @@
+# AM_CONFIG_HEADER(HEADERS..., [COMMANDS], [INIT-CMDS])
+# -
# Like AC_CONFIG_HEADER, but automatically create stamp file.
# serial 3
@@ -7,22 +9,33 @@
# that is generated. We must strip everything past the first ":",
# and everything past the last "/".
-AC_PREREQ([2.12])
+AC_PREREQ([2.49c])
AC_DEFUN([AM_CONFIG_HEADER],
-[AC_CONFIG_HEADER([$1])
- AC_OUTPUT_COMMANDS(
- ifelse(patsubst([$1], [[^ ]], []),
- [],
- [test -z "$CONFIG_HEADERS" || echo timestamp dnl
- patsubst([$1], [^\([^:]*/\)?.*], [\1])stamp-h]),
- [am_indx=1
- for am_file in $1; do
-case " $CONFIG_HEADERS " in
-*" $am_file "*)
- echo timestamp `echo $am_file | sed 's%:.*%%;s%[^/]*$%%'`stamp-h$am_indx
- ;;
-esac
-am_indx=\`expr \$am_indx + 1\`
- done])
-])
+[dnl init our file count if it isn't already
+m4_ifndef([_AM_Config_Header_Index], m4_define([_AM_Config_Header_Index],
+[0]))
+dnl prepare to store our destination file list for use in config.status
+AC_FOREACH([_AM_File], [$1],
+ [m4_pushdef([_AM_Dest], m4_patsubst(_AM_File, [:.*]))
+ m4_define([_AM_Config_Header_Index],
+m4_incr(_AM_Config_Header_Index))
+ dnl and add it to the list of files AC keeps track of, along
+ dnl with our hook
+ AC_CONFIG_HEADERS(_AM_File,
+dnl COMMANDS, [, INIT-CMDS]
+[# update the timestamp
+echo timestamp "AS_ESCAPE(_AM_DIRNAME(]_AM_Dest[))/stamp-h]_AM_Config_Header_Index["
+][$2]m4_ifval([$3], [, [$3]]))dnl AC_CONFIG_HEADERS
+ m4_popdef([_AM_Dest])])
+]) # AM_CONFIG_HEADER
+
+# _AM_DIRNAME(PATH)
+# -
+# Like AS_DIRNAME, only do it during macro expansion
+AC_DEFUN([_AM_DIRNAME],
+[m4_if(m4_regexp([$1], [^.*[^/]//*[^/][^/]*/*$]), -1,
+m4_if(m4_regexp([$1], [^//\([^/]\|$\)]), -1,
+ m4_if(m4_regexp([$1], [^/.*]), -1,
+
amtraces functionality
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. I'm a carrier. - Scott Adam's _Dilbert_
Re: patch: stamp-h? files in subdirs
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 decided that if it was good enough for AS_DIRNAME it was good enough for _AM_DIRNAME. I stripped the regex verbatim from AS_DIRNAME and figured if anyone ever updated AS_DIRNAME someone would catch _AM_DIRNAME eventually. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not drive the principal's car. I will not drive the principal's car. I will not drive the principal's car... - Bart Simpson on chalkboard, _The Simpsons_
stamp files
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; \ $(MAKE) stamp-h3; \ else :; fi stamp-h3: $(srcdir)/thirdfile.h.in $(top_builddir)/config.status @rm -f stamp-h3 stamp-h3T @echo timestamp stamp-h3T 2 /dev/null cd $(top_builddir) \ CONFIG_FILES= CONFIG_HEADERS=thirdfile.h \ $(SHELL) ./config.status @mv stamp-h3T stamp-h3 Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not aim for the head. I will not aim for the head. I will not aim for the head... - Bart Simpson on chalkboard, _The Simpsons_
Re: More an autopackage
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 using Autopackage could conceivably do all their testing on a single platform once Autopackage and the associated Automake support was finished and debugged (heh). Then a user could download a source distrobution and blindly build and/or install the platform specific package they require. An aim worth working in Bourne shell for, I'd think. Someone who wished to make such a built package available for download and do any other value add they desired (previously a package maintainer), could still do so using this tool. I expect those sort of people would still have work, but hopefully it wouldn't be more than tweaking the packages or the AP tool itself and more time could be devoted to real development. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not call my teacher "Hot Cakes". I will not call my teacher "Hot Cakes". I will not call my teacher "Hot Cakes"... - Bart Simpson on chalkboard, _The Simpsons_
Re: More an autopackage
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-install scripts are generated by automake itself. For instance, take a look at the hair required to install an info page. It would be a pain for developers to have to insert this code by hand (if they even know it exists). Good point, but the general design I pointed out should still hold. Only the generated Makefile would be the source for the data needed for spec file generation rather than the Makefile.am, whether that's passed in or scanned. The pre/post install hair should be scannable from the Makefile as well, whether that's for a shared library or info. The spec file source would want room for install hooks as well, still. That way instructions for, say, taking a daemon down and up again could be inserted before automake acquires a daemon target. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Teacher is not a leper. Teacher is not a leper. Teacher is not a leper... - Bart Simpson on chalkboard, _The Simpsons_
Another problem with BSD Make
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
*_TEXINFOS dependency that works from outside $(srcdir) for both a build
and a make dist without extra configure work.
The following configure.in code will discover if the bug is present and
set an AUTOMAKE conditional switch based on that:
# BSD's logo is a devil for a reason, hey?
AC_CACHE_CHECK(for BSD VPATH bug in make, ccvs_cv_bsd_make_vpath_bug,
[if test ! -d ac_test_dir ; then
AC_TRY_COMMAND([mkdir ac_test_dir])
fi
cat conftestmake EOF
VPATH = ac_test_dir
ac_test_target: ac_test_dep
echo BSD VPATH bug present 2
ac_test_dep: ac_test_dep_dep
EOF
touch ac_test_dir/ac_test_dep_dep
touch ac_test_dir/ac_test_dep
touch ac_test_target
# Don't know why, but the following test doesn't work under FreeBSD 4.2
# without this sleep command
sleep 1
if AC_TRY_COMMAND([make -f conftestmake 21 /dev/null
|grep ^BSD\ VPATH\ bug\ present\$ /dev/null]) ; then
ccvs_cv_bsd_make_vpath_bug=yes
else
ccvs_cv_bsd_make_vpath_bug=no
fi
AC_TRY_COMMAND([rm -rf ac_test_dir ac_test_target conftestmake])])
# We also don't need to worry about the bug when $srcdir = $builddir
AM_CONDITIONAL(MAKE_TARGETS_IN_VPATH, \
test $ccvs_cv_bsd_make_vpath_bug = no \
|| test $srcdir = .)
I used the above test to create a conditional target for my *_TEXINFOS,
but there's nothing I can do about the info_TEXINFOS targets without
sticking my fingers into the automake code again.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
#! perl
@a = ( 0x2E805,0x6B39,0x15B3,0x45993,0x153C,0x1D9F );
for ( @a ) { ( $s, $i )=( 'a', 0 ); $s++ while $i++ $_; print "$s" }
Re: Package support (RPM, deb, pkg, kits, etc.)
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://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- There is not a truth existing which I fear or would wish unknown to the whole world. - Thomas Jefferson to Henry Lee, 1826
[PATCH] Another BSD make incompatibility
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_FILES list, as used
to happen.
There're new RPMs at:
http://alumni.engin.umich.edu/~oberon/automake-1.4c-0_CVSHome_org_2.noarch.rpm
http://alumni.engin.umich.edu/~oberon/automake-1.4c-0_CVSHome_org_2.src.rpm
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
I find that the harder I work, the more luck I seem to have.
- Thomas Jefferson
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.813
diff -u -r1.813 automake.in
--- automake.in 2000/12/23 21:05:21 1.813
+++ automake.in 2000/12/29 20:30:22
@@ -3030,7 +3031,7 @@
local ($iter);
local (@deplist) = sort keys %dep_files;
- define_pretty_variable ('DEP_FILES', '', ("\@AMDEP\@", @deplist));
+ define_pretty_variable ('DEP_FILES', "\@AMDEP\@", @deplist);
# Generate each `include' individually. Irix 6 make will
# not properly include several files resulting from a
Index: ChangeLog
===
RCS file: /cvs/automake/automake/ChangeLog,v
retrieving revision 1.929
diff -u -r1.929 ChangeLog
--- ChangeLog 2000/12/23 21:42:43 1.929
+++ ChangeLog 2000/12/29 20:38:49
@@ -1,3 +1,11 @@
+2000-12-29 Derek Price [EMAIL PROTECTED]
+
+ * automake.in (handle_dependencies): switched the DEP_FILES definition
+ to use the pretty_print conditional machinery rather than shoving
+ "\@AMDEP\@" in as the first list element since BSD make doesn't seem to
+ be able to handle backslashes for continuing comments on the following
+ line
+
2000-12-28 Derek Price [EMAIL PROTECTED]
* NEWS (New in 1.4c): Added
[Fwd: Ultrix problem]
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: BA: not found WARNING: `:' is needed, and you do not seem to have it handy on your system. You might have modified some files without having the proper tools for further handling them. Check the `README' file, it often tells you about the needed prerequirements for installing this package. You may also peek at any GNU archive site, in case some other package would contain this missing `:' program. configure: WARNING: `missing' script is too old or missing Hmmm That warning looks to me like it came from the 'missing' script, but I haven't been here long. The content of the warning looks like your Ultrix system can't handle the ':' command. I didn't realize ':' was passed through 'missing' but maybe configure does something similar. I didn't think 'missing' would run until build time. Anyway, the Bourne shells (/bin/sh programs) I know of treat ':' like a noop. It's used to confuse some systems that don't like 'if's without 'else's (if there is no 'else', put one in with a command to do nothing (put in a ':' (noop))). Of course, I remember that was Ultrix they were placating, but I can't find the comments I remember with a cursory code review, so I'm confused. Maybe someone ran 'missing' from 'configure' with a ':' (noop) as a command to see if 'missing' present and working? 'missing' might expect its program to be in your path, so if it's a shell builtin it might fail? Just guessing. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- And what if you track down these men and kill them? What if you murdered all of us? From every corner of Europe hundreds, thousands, would rise to take our places. - Paul Henreid as Victor Laszlo, _Casablanca_
Re: [Fwd: --add-missing]
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'm using the following, stripped directly from my Automake generated Makefile.in's DVI targets, but I didn't research enough to know if any of the constituent elements (TEXINPUTS, MAKEINFO, makeinfo includes) vary with Makefile.am parameters: SUFFIXES = .aux .txt .pdf # texinfo based targets automake neglects to include .texinfo.pdf: TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) --pdf $ .txi.pdf: TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) --pdf $ .texi.pdf: TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) --pdf $ By the way, there may not be much demand for it any longer, but we have legacy targets to generate ASCII versions of our manuals as well. I'm told they ocassionally came in handy for mailing: .texinfo.txt: TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(MAKEINFO) $ --no-headers -o $@ .txi.txt: TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(MAKEINFO) $ --no-headers -o $@ .texi.txt: TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(MAKEINFO) $ --no-headers -o $@ Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- This is the fourth? - Thomas Jefferson's last words (he died on the 4th of July)
Re: distributing files generated by configure
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 Automake and I hadn't considered that yet. version.c is the name of the file where the information was kept before Automake. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not torment the emotionally frail. I will not torment the emotionally frail. I will not torment the emotionally frail... - Bart Simpson on chalkboard, _The Simpsons_
Re: distributing files generated by configure
"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 number string. That's a good point. They're there because I just converted this source to use Automake and I hadn't considered that yet. version.c is the name of the file where the information was kept before Automake. Although a quick glance at what it would take to switch over reveals that I would have to hook into the application's init functions or rewrite some code to change over since the VERSION is being sed'd dirtectly into a global string. I don't want to worry about that yet. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I am not a 32 year old woman. I am not a 32 year old woman. I am not a 32 year old woman... - Bart Simpson on chalkboard, _The Simpsons_
Re: BSD make and dependencies
Tom Tromey wrote:Derek Apparently BSD wants something like the following: Derek .include "file" Derek or Derek .include file 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'll ask the guy who reported this to me in the first place too. I'll let you know what I discover. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- The Christmas Pageant does not stink. The Christmas Pageant does not stink. The Christmas Pageant does not stink... - Bart Simpson on chalkboard, _The Simpsons_
Re: [PATCH] etags support
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) that was distributed with RedHat 6.2. They've removed it from the emacs package since and by default install the ctags package which contains Exuberent ctags, which doubles as an etags implementation. It turns out I upgraded to RedHat 7.0 and forgot. :) I don't mind supporting some other version of tags, but I think it would be easiest if we just introduced a new target. [snip] The `--lang=none' thing is definitely specific to the Emacs etags. That must appear in your Makefile.am though -- meaning that your Makefile.am was written to work with the Emacs etags. This isn't an uncommon practice, either. '--lang=x' isn't though. Exuberent ctags looks like it was trying to mimic the original. Not sure why there are differences. Adding configure machinery for this seems like overkill. I'm still not so sure about that. The targets are extremely similiar and the output file has the same name and is in the same format. In theory, both programs should produce identical output, with the '--lang=none' exception noted above. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Always glad to share my ignorance - I've got plenty.
distclean-generic bug
The distclean-generic target is removing the following files: stamp-h stamp-h[0-9]* The listing of 'stamp-h[0-9]*' causes 'stamp-h[0-9].in' files to be removed incorrectly. And incidentally, it would be unecessary to list stamp-h if you applied the stamp-h fix I sent to the list sometime in the last week or so (stamp-h will then never be created - the bug was that it was often created but not used). Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Conscious is what you are aware of and conscience is what you wish you weren't.
distributing files generated by configure
I have several files which are generated by configure that I want three things to happen to. 1) Created in $(srcdir) rather than $(builddir) or, alternately and second best, targets added which make the $(srcdir) counterparts dependent on the $(builddir) versions. I don't like option 2 because a lot of diffing and touching will have to be going on to avoid updating unchanged files. 2) Removed from distclean 3) Added to dist The reason for this is to allow platforms which can't run configure (Win32) to checkout from our CVS repository and build as correctly as if they had grabbed a generated distribution. The premise is that any file checked into CVS should be in $(srcdir) and should not be removed from $(srcdir) by distclean. Our version.c file is an example of one of these files - it is now generated with configure based on the AM_INIT_AUTOMAKE version. #3 is easy, but it doesn't look like it is going to be easy to get the first two. Am I missing something? Is there a prescribed way to do this? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- They are laughing at me, not with me. They are laughing at me, not with me. They are laughing at me, not with me... - Bart Simpson on chalkboard, _The Simpsons_
BSD make and dependencies
Is there any support in Automake for BSD make's style of includes? Apparently BSD wants something like the following: .include file or .include file Where and have similiar meanings to what they would have in a C program include. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Old heads as well as young may sometimes be charged with ignorance and presumption. The natural course of the human mind is certainly from credulity to skepticism. - Thomas Jefferson to Caspar Wistar, 1807
Re: ./configure .deps directory
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 it again? Besides some developer or other Derek needing sleep? ;) Derek My distribution certainly doesn't seem to need that directory Derek sitting around... This directory is needed by the dependency tracking implementation. I agree though that this macro is mysterious. Why doesn't it create `_deps' if that is what is chosen? What's $(top_builddir)/.deps get used for when there aren't any C sources in $(top_srcdir) or $(top_builddir)? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- One woman has hurt you and you'll take it out on the rest of the world? You're a coward and a weakling! - Ingrid Bergman as Elsa, _Casablanca_
vtexi.test failing
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] pen what in other times was done with the sword, [and] show that reformation is more practicable by operating on the mind than on the body of man. - Thomas Jefferson to Thomas Paine, 1792
New version of RPMs
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 PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- He always has. - Humphrey Bogart as Rick, _Casablanca_
Re: vtexi.test failing
"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 -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- This score just in: OS/2, Windows 95, LinuxPPC 2000. Index: vtexi.test === RCS file: /cvs/automake/automake/tests/vtexi.test,v retrieving revision 1.4 diff -u -r1.4 vtexi.test --- vtexi.test 1997/02/23 19:41:20 1.4 +++ vtexi.test 2000/12/21 20:54:44 @@ -24,4 +24,4 @@ $AUTOMAKE || exit 1 -grep '^textutils\.info: textutils\.texi version\.texi$' Makefile.in +grep '^textutils\.info: textutils\.texi $(srcdir)/version\.texi$' Makefile.in
Re: [PATCH] etags support
Raja R Harinath wrote: I added a macro to test for the presence of etags and whether it supports "--etags-include=file" or "-i file" 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 distribution if it gives you a "non-standard" etags (you can call the Emacs etags the "standard"). Well, there is a precedent in the support for different compiler options and I don't want to waste the time of potential CVS developers because they couldn't get their TAGS file built. A lot of CVS users are installing on RedHat Linux at the moment. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Were it left for me to decide whether we should have a government without newspapers, or newspapers without a government, I should not hesitate a moment to prefer the latter. - Thomas Jefferson (appeared http://hotwired.lycos.com/special/lawsuit/ )
Re: New version of RPMs
"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't being installed re my recent email. Regenerated. http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_7.noarch.rpm http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_7.src.rpm Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not prescribe medication. I will not prescribe medication. I will not prescribe medication... - Bart Simpson on chalkboard, _The Simpsons_
Re: BOUNCE pdftex@tug.org: Non-member submission from [Derek R. Price derek.price@openavenue.com]
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 as far as I'm concerned. *.info, *.ps, and *.pdf all build and pass cursory inspection, anyhow. Of course, now my users can miss upgrades to the distributed version of texinfo.tex and possibly useful changes in their tex distribution's operation, but I guess I can confine that argument to the Automake folks and Richard Stallman for awhile. :) Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- All work and no play makes Bart a dull boy. All work and no play makes Bart a dull boy. All work and no play makes Bart a dull boy... - Bart Simpson on chalkboard, _The Simpsons_
Re: BOUNCE pdftex@tug.org: Non-member submission from [Derek R. Price derek.price@openavenue.com]
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 answer is to put pdftexinfo.tex into the texmf/pdftex tree, and call it texinfo.tex? Actually, yeah, and that was my solution, but I was trying to help out the Automake folks who got me into this mess in the first place. :) Basically, the issue is that the GNU coding standards state that the texinfo.tex you built your docs with should be included with a source distribution so that an end user is sure to be able to build your docs too. So Automake attempts to force this issue and copy its texinfo.tex into any directory where docs are built unless it is overridden. Unfortunately, if you are attempting to build both PDFs and other types of output in the same directory from the same source files, this would disable either the building of PDFs or it would disable everything else. Anyway, I was hoping for a solution compatible with the current GNU coding standard short of putting pdftexinfo.tex texinfo.tex in different directories and overriding the TEXINPUTS path dependent on the target or barbarically renaming the files before calling texi2dvi. Aesthetically, I think coding the filename switch inside the *texi source file would be most pleasing, as the Makefile structure never has to distinguish between targets except to supply the --pdf switch, and being able to specify a complete path to a *texinfo.tex on the command line would be second best since it would avoid the forced creation of extra directories. Of course, a local structure mirroring the texmf tree structure which allowed KPATHSEA to do most of the work without changes might be the most elegant. Is any of this possible? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Conscious is what you are aware of and conscience is what you wish you weren't.
[PATCH] m4/header.m4 bug
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 to be interpreted in config.status were being interpreted in configure instead and leaving blank spots in config.status. The stamp files were still being created in the correct places in the Makefile.ins Makefiles, so it wasn't a fatal bug, but I fixed it anyway. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Southern DOS: Y'all reckon? (yep/Nope) Index: ChangeLog === RCS file: /cvs/automake/automake/ChangeLog,v retrieving revision 1.910 diff -u -r1.910 ChangeLog --- ChangeLog 2000/11/26 22:11:20 1.910 +++ ChangeLog 2000/12/15 19:55:12 @@ -1,3 +1,8 @@ +2000-12-15 Derek Price [EMAIL PROTECTED] + + * m4/header.m4 (AM_CONFIG_HEADER): This macro was broken due to + unescaped shell metachars + 2000-12-05 Derek Price [EMAIL PROTECTED] * automake.in (require_file_with_conf_line, Index: m4/header.m4 === RCS file: /cvs/automake/automake/m4/header.m4,v retrieving revision 1.7 diff -u -r1.7 m4/header.m4 --- m4/header.m42000/08/06 12:36:53 1.7 +++ m4/header.m42000/12/15 19:49:31 @@ -18,9 +18,9 @@ patsubst([$1], [^\([^:]*/\)?.*], [\1])stamp-h]), [am_indx=1 for am_file in $1; do -case " $CONFIG_HEADERS " in -*" $am_file "*) - echo timestamp `echo $am_file | sed 's%:.*%%;s%[^/]*$%%'`stamp-h$am_indx +case " \$CONFIG_HEADERS " in +*" \$am_file "*) + echo timestamp \`echo \$am_file | sed 's%:.*%%;s%[^/]*\$%%'\`stamp-h\$am_indx ;; esac am_indx=\`expr \$am_indx + 1\`
Re: depcomp fix rpm'd
I tacked in the AM_CONFIG_HEADER stamp-h fix too. The current RPMs are now: http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_3.noarch.rpm http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_3.src.rpm Derek -- Derek Price CVS 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 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 two patches I removed did, but I kept them in the source RPM in case anybody wants a look. The build source is the current CVS automake as of 20 minutes ago. http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_2.noarch.rpm http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_2.src.rpm Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- It is error alone which needs the support of government. Truth can stand by itself. - Thomas Jefferson
[PATCH] Re: [PATCH] m4/header.m4 bug
Here's the same patch again with a test case thrown in. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Nor was it uninteresting to the world that an experiment should be fairly and fully made whether freedom of discussion, unaided by power, is not sufficient for the propagation and protection of truth: whether a government conducting itself in the true spirit of its constitution with zeal and purity and doing no act which it would be unwilling the whole world should witness can be written down by falsehood and defamation. The experiment has been tried; [we] have witnessed the scene; our fellow citizens have looked on, cool and collected. They saw the latent source from which these outrages proceeded; they gathered around their public functionaries, and when 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 "Derek R. Price" wrote: 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 to be interpreted in config.status were being interpreted in configure instead and leaving blank spots in config.status. The stamp files were still being created in the correct places in the Makefile.ins Makefiles, so it wasn't a fatal bug, but I fixed it anyway. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Southern DOS: Y'all reckon? (yep/Nope) Index: ChangeLog === RCS file: /cvs/automake/automake/ChangeLog,v retrieving revision 1.910 diff -u -r1.910 ChangeLog --- ChangeLog 2000/11/26 22:11:20 1.910 +++ ChangeLog 2000/12/15 19:55:12 @@ -1,3 +1,8 @@ +2000-12-15 Derek Price [EMAIL PROTECTED] + + * m4/header.m4 (AM_CONFIG_HEADER): This macro was broken due to + unescaped shell metachars + 2000-12-05 Derek Price [EMAIL PROTECTED] * automake.in (require_file_with_conf_line, Index: m4/header.m4 === RCS file: /cvs/automake/automake/m4/header.m4,v retrieving revision 1.7 diff -u -r1.7 m4/header.m4 --- m4/header.m42000/08/06 12:36:53 1.7 +++ m4/header.m42000/12/15 19:49:31 @@ -18,9 +18,9 @@ patsubst([$1], [^\([^:]*/\)?.*], [\1])stamp-h]), [am_indx=1 for am_file in $1; do -case " $CONFIG_HEADERS " in -*" $am_file "*) - echo timestamp `echo $am_file | sed 's%:.*%%;s%[^/]*$%%'`stamp-h$am_indx +case " \$CONFIG_HEADERS " in +*" \$am_file "*) + echo timestamp \`echo \$am_file | sed 's%:.*%%;s%[^/]*\$%%'\`stamp-h\$am_indx ;; esac am_indx=\`expr \$am_indx + 1\` --- /dev/null Thu Aug 24 05:00:32 2000 +++ tests/stamph2.test Fri Dec 15 15:57:48 2000 @@ -0,0 +1,29 @@ +#! /bin/sh + +# Make sure stamp-h* files are created where we expect + +. $srcdir/defs || exit 1 + +cat configure.in 'END' +AC_INIT(Makefile.am) +AM_INIT_AUTOMAKE(nonesuch, nonesuch) +AM_CONFIG_HEADER(firstfile.h sdir/secondfile.h thirdfile.h) +AC_OUTPUT(Makefile) +END + +: Makefile.am +mkdir sdir +: firstfile.h.in +: sdir/secondfile.h.in +: thirdfile.h.in + +# Fail gracefully if no autoconf. +(autoconf --version) /dev/null 21 || exit 77 + +$ACLOCAL || exit 1 +autoconf || exit 1 +$AUTOMAKE || exit 1 +./configure || exit 1 + +(test -f stamp-h1 test -f sdir/stamp-h2 test -f stamp-h3) || exit 1 +exit 0 Index: tests/ChangeLog === RCS file: /cvs/automake/automake/tests/ChangeLog,v retrieving revision 1.308 diff -u -r1.308 tests/ChangeLog --- tests/ChangeLog 2000/11/26 01:37:30 1.308 +++ tests/ChangeLog 2000/12/15 21:02:11 @@ -1,3 +1,8 @@ +2000-12-15 Derek Price [EMAIL PROTECTED] + + * stamph2.test: new file + * Makefile.am (TESTS): Added stamph2.test + 2000-12-05 Derek Price [EMAIL PROTECTED] * depcomp.test: New File Index: tests/Makefile.am === RCS file: /cvs/automake/automake/tests/Makefile.am,v retrieving revision 1.239 diff -u -r1.239 tests/Makefile.am --- tests/Makefile.am 2000/11/26 01:37:30 1.239 +++ tests/Makefile.am 2000/12/15 21:02:12 @@ -221,6 +222,7 @@ spell3.test \ spelling.test \ stamph.test \ +stamph2.test \ stdlib.test \ subdir.test \ subdir2.test \
Re: bug: depcomp misplaced
"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 sure is easy to interpret) which is set when AC_CONFIG_AUX_DIR is noticed initially since it seemed a little silly to check _every_ use of $config_aux_dir for '.' and '' for only three places which wanted to look in a local directory rather than use AC_CONFIG_AUX_DIR's actual value. I should have specified $config_aux_dir rather than AC_CONFIG_AUX_DIR in the last reference of this explanation, as the code sets $config_aux_dir to one of the default locations (it could be '.', '..', or '../..', depending on where the first config file is found) and _this_ is what the code which now switches on $config_aux_dir_set_in_configure_in is avoiding. If AC_CONFIG_AUX_DIR was used that code will use the specified value. Hence the variable name. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- There are plenty of businesses like show business. There are plenty of businesses like show business. There are plenty of businesses like show business... - Bart Simpson on chalkboard, _The Simpsons_
bug: depcomp misplaced
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):
# Set location of depcomp.
local ($prefix) = ($config_aux_dir_specified ? $config_aux_dir
: '$(top_srcdir)');
define_variable ('depcomp', "\$(SHELL) $prefix/depcomp");
require_config_file ($FOREIGN, 'depcomp');
I'm not sure what the complete solution is, but it looks like
handle_dependencies isn't called until the first C file is encountered,
at which point require_config_file adds depcomp to '.' (which could be
a subdir of $(top_srcdir)), ignoring the fact that it just defined the
depcomp variable to '$(top_srcdir)/depcomp'.
My workaround was to copy depcomp into $(top_srcdir) myself and remove
the other copies. After that everything worked like I thought it
should. From my scan of the code, it looks like using the
AC_CONFIG_AUX_DIR macro in configure.in might also make things work, but
I never tested that theory.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
Computer Lie #1: You'll never use all that disk space.
Re: bug: depcomp misplaced
Unfortunately, not quite. This causes depcomp to be incorrectly pushed
onto DIST_COMMON in the sudir/Makefile.in when maybe_push_required_file
gets called by require_file_internal. Basically,
maybe_push_required_file expects $relative_dir to be set right and pushes
its file onto DIST_COMMON if $relative_dir/$file exists. Unfortunately
$relative_dir gets set back to normal after require_config_file returns
and then DIST_COMMON gets written out into the wrong Makefile.in. Or,
rather, the correct Makefile.in but containing the wrong 'depcomp'
reference. I'm too tired and hungry to try and decipher any more right
now. Anyone have any better ideas?
I've included my patch containing what I have so far since it fixes some
tests which should be fixed in case anyone wants to take a look before
I wake up from my nap and get something to eat. Or in case I find
something better to do since I do have that workaround and other things
I could be working on. pr87.test and subdir4.test are still failing
because of this. Sorry about the rewritten toplevel Makefile.in, but
I figured I might as well include it since it gets rewritten on the first
make after a fresh checkout right now anyhow. Oh, and I removed a hack
from automake.in that became unnecessary after $relative_dir was
redefined for require_config_file. Or what should still be an
unnecessary hack after this problem gets fixed.
Derek
--
Derek Price CVS Solutions Architect ( 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 automake.in (in the
handle_dependencies function):
# Set location of depcomp.
local ($prefix) = ($config_aux_dir_specified ? $config_aux_dir
: '$(top_srcdir)');
define_variable ('depcomp', "\$(SHELL) $prefix/depcomp");
require_config_file ($FOREIGN, 'depcomp');
I remember that playing around with $relative_dir worked at some time.
I don't have CVS automake checked out right now, but can you try
replacing the last line above
require_config_file ($FOREIGN, 'depcomp');
with the following hack
local ($save_dir) = ($relative_dir);
$relative_dir = '.';
require_config_file ($FOREIGN, 'depcomp');
$relative_dir = $save_dir;
- Hari
--
Raja R Harinath -- [EMAIL PROTECTED]
"When all else fails, read the instructions." -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing." -- Roy L Ash
? automake/automake-1.4a.tar.gz
Index: automake/Makefile.in
===
RCS file: /cvs/automake/automake/Makefile.in,v
retrieving revision 1.240
diff -u -r1.240 Makefile.in
--- Makefile.in 2000/11/18 23:58:24 1.240
+++ Makefile.in 2000/12/04 23:25:35
@@ -1,6 +1,7 @@
# Makefile.in generated automatically by automake 1.4a from Makefile.am
-# Copyright (C) 1994, 1995-9, 2000 Free Software Foundation, Inc.
+# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000
+# Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
@@ -314,6 +315,7 @@
rm -f $$i-[0-9]*; \
fi; \
done
+
install-dist_pkgdataDATA: $(dist_pkgdata_DATA)
@$(NORMAL_INSTALL)
Index: automake/automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.803
diff -u -r1.803 automake.in
--- automake.in 2000/11/26 01:39:48 1.803
+++ automake.in 2000/12/04 23:25:39
@@ -3042,22 +3042,17 @@
local ($config_aux_dir_specified) = ($config_aux_dir ne '.'
$config_aux_dir ne '');
- # Set $require_file_found{'depcomp'} if the depcomp file exists,
- # before calling require_config_file on `depcomp'. This makes
- # require_file_internal skip its buggy existence test that would
- # make automake fail (with `required file `lib/depcomp' not found')
- # when AC_CONFIG_AUX_DIR is not set. See tests/subdir4.test.
- local ($depcomp_dir) = ($config_aux_dir_specified ? $config_aux_dir
- : '.');
- $require_file_found{'depcomp'} = 1 if -f "$depcomp_dir/depcomp";
-
# Set location of depcomp.
local ($prefix) = ($config_aux_dir_specified ? $config_aux_dir
: '$(top_srcdir)');
define_variable ('depcomp', "\$(SHELL) $prefix/depcomp");
+ # set $relative_dir so depcomp gets installed in $top_srcdir
+ lo
defining recursive targets
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 remotecheck-local in each Makefile.in? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- 160. I'm not a complete idiot - several parts are missing.
[Fwd: --add-missing]
Yep. Looks like that could be used by configure to set, say, TEX_TEXINPUTS PDFTEX_TEXINPUTS and prepend include dirs differently for different targets, but I suspect that if your TeX distribution includes kpsewhich then your TeX applications can already find the appropriate texinfo.tex. Of course, I suppose this could still be used to find a more recent texinfo.tex than was included with your automake distribution, which would work slightly better than including an out-of-date texinfo.tex, but the included texinfo.tex will still render PDF targets unbuildable since texi2dvi will, by default, prefer a texinfo.tex in '.' over one elsewhere. In other words, a complete solution is probably some combination of these two, so that TEX_TEXINPUTS or PDFTEX_TEXINPUTS is used when available and the included texinfo.tex is used when the appropriate texinfo.tex can't be found. This is a little more work, but it seems much less baroque than mv'ing texinfo.tex out of the way when a better one is found. Then again, maybe you can find a way to make that work. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] 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] writes: 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 "proper" texinfo.tex file (i.e. the one installed with the texinfo package and assumedly the most recent one)? I'm afraid not. Any suggestions about how automake could find out where texinfo.tex from the texinfo package is installed, assuming it is? Well, after sifting the documentation for my distribution for several hours, I have discovered the "texmf.cnf" file. It appears to define all sorts of possible search paths dependant on the format of your input and output files. Assuming you're using teTeX (likely for most recent UNIX TeX installations), you look for things using the 'kpsewhich' program, like in kpsewhich texinfo.tex The texmf.cnf file should be treated as an internal detail. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash
Default clean files
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 cvsclient.texi and it seems to be creating a clean target that removes the 'cvs.ps' file despite the fact that 'cvs.ps' is listed in EXTRA_DIST. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- If genius is one percent inspiration and 99 percent perspiration, I sure wind up sharing elevators with a lot of bright people.
--add-missing
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 CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- When you find yourself getting irritated with someone, try to remember that all men are brothers... a noogie or an Indian burn should do the trick.
Re: texinfo.tex
"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-texinfo.tex option to disable this behavior, but is there any reason this is ever desirable? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- 170. If you try to fail, and succeed, which have you done?
Re: Targets using automake
This same applies to targets using autoconf autoheader. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- A burp is not an answer. A burp is not an answer. A burp is not an answer... - 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 I think this is very bad from a maintenance viewpoint (more questions to answer) and very rude to users. Is there some way to place any targets which make use of automake inside a conditional? i.e. I want the fact that configure discovers that automake is not installed to disable the use of automake in any targets which might use them. In this case that seems to mean the distdir Makefile.in targets. I would actually only like the portion of the distdir target that recalls automake inside the conditional since I would like the target to work otherwise. This could be a very useful tool but without this feature I cannot use it in good conscience. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- If you can read this, please flip me back over... (seen upside down, on a Jeep)
Re: Targets using automake
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' approach? What version of Automake are you using? I'm using CVS Automake for my package, and never found such problem. And I'm totally against AM_MAINTAINER_MODE :) What's the 'missing' approach? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I am not deliciously saucy. I am not deliciously saucy. I am not deliciously saucy... - Bart Simpson on chalkboard, _The Simpsons_
Re: Targets using automake
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 based on whether the tools are installed as opposed to a command line switch??? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I am not deliciously saucy. I am not deliciously saucy. I am not deliciously saucy... - Bart Simpson on chalkboard, _The Simpsons_
Re: Targets using automake
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 Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- All work and no play makes Bart a dull boy. All work and no play makes Bart a dull boy. All work and no play makes Bart a dull boy... - Bart Simpson on chalkboard, _The Simpsons_
Re: Targets using automake
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 later and thus when I uninstalled automake to test the new Makefile everything broke. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- The advertisement is the most truthful part of the paper. - Thomas Jefferson
*-local targets
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.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not conduct my own fire drills. I will not conduct my own fire drills. I will not conduct my own fire drills... - Bart Simpson on chalkboard, _The Simpsons_
