Re: [PATCH] etags support
Index: m4/init.m4
===
RCS file: /cvs/automake/automake/m4/init.m4,v
retrieving revision 1.20
diff -u -r1.20 m4/init.m4
--- m4/init.m4 2000/10/10 00:18:52 1.20
+++ m4/init.m4 2000/12/21 18:07:02
@@ -54,6 +54,7 @@
# some platforms.
AC_REQUIRE([AC_PROG_AWK])dnl
AC_REQUIRE([AC_PROG_MAKE_SET])dnl
+AC_REQUIRE([AM_PROG_ETAGS])
Missing a dnl here.
--- /dev/null Thu Aug 24 05:00:32 2000
+++ m4/etags.m4 Thu Dec 21 17:32:23 2000
@@ -0,0 +1,61 @@
+#
+# Find some information about the etags program
+#
+# Sets
+#ETAGS = path to etags
+#ETAGS_INCLUDE_OPTION = option to pass to etags with arg for includes
+#
+
+AC_DEFUN([AM_PROG_ETAGS],
+[AC_BEFORE([$0], AM_PROG_ETAGS_WORKS)
You must quote AM_PROG_ETAGS_WORKS here. And dnl too :)
+AC_CHECK_PROG(ETAGS, etags, etags)
+if test -z "$ETAGS"; then
+ AC_CHECK_PROG(ETAGS, ctags, ctags -e)
+fi
+if test -n "$ETAGS"; then
+ AM_PROG_ETAGS_WORKS
+ if test "$am_cv_prog_etags_works" = yes ; then
+ AM_PROG_ETAGS_INCLUDE_OPTION
+ else
+ AM_MISSING_PROG(ETAGS, etags)
+ fi
+else
+ AM_MISSING_PROG(ETAGS, etags)
+fi])
+
+
+AC_DEFUN([AM_PROG_ETAGS_WORKS],
Internal macros such as this one should be named _AM_ something.
+[AC_CACHE_CHECK([whether etags works], [am_cv_prog_etags_works],
+[cat conftest.c EOF
+int globalvar;
+EOF
+if AC_TRY_COMMAND(${ETAGS-etags} -f - conftest.c) |egrep "^int globalvar;"
/dev/null 21; then
Using AC_TRY_COMMAND is excellent, but I'd either use it several
times, or for the whole command:
if AC_TRY_COMMAND([${ETAGS-etags} -f - conftest.c]) |
AC_TRY_COMMAND([egrep "^int globalvar;" 2]); then
or
if AC_TRY_COMMAND([${ETAGS-etags} -f - conftest.c |
egrep "^int globalvar;" 2]); then
so that CVS Autoconf report some logs. That's also why I sent it to
stderr (which is logged) instead of /dev/null.
FYI:
| /tmp % cat configure.in
| AC_INIT
| AC_TRY_COMMAND([echo toto]) | AC_TRY_COMMAND([grep toto 2])
| AC_TRY_COMMAND([echo toto; exit 1]) | AC_TRY_COMMAND([grep toto 2])
| AC_TRY_COMMAND([echo toto]) | AC_TRY_COMMAND([grep ta 2])
| /tmp % ace
| /tmp % ./configure
| /tmp % cat config.log
| This file contains any messages produced by compilers while
| running configure, to aid debugging if configure makes a mistake.
|
| It was created by configure 2.49c, executed with
| ./configure
|
| ## -- ##
| ## Platform. ##
| ## -- ##
|
| hostname = nostromo
| uname -m = i686
| uname -r = 2.2.17
| uname -s = Linux
| uname -v = #1 Sat Sep 9 12:42:22 EST 2000
|
| /usr/bin/uname -p =
| /bin/uname -X =
|
| /bin/arch = i686
| /usr/bin/arch -k =
| /usr/convex/getsysinfo =
| hostinfo =
| /bin/machine =
| /usr/bin/oslevel =
| /bin/universe =
|
| PATH =
|/tmp/lt/bin/:/usr/local/bin/akim:/home/lrde/prof/akim/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/X11R6/bin:/usr/local/kde/bin
|
| ## ##
| ## Core tests. ##
| ## ##
|
| configure:833: echo toto
| configure:836: $? = 0
| configure:837: grep toto 2
| toto
| configure:840: $? = 0
| configure:842: echo toto; exit 1
| configure:845: $? = 1
| configure:846: grep toto 2
| toto
| configure:849: $? = 0
| configure:851: echo toto
| configure:855: grep ta 2
| configure:854: $? = 0
| configure:858: $? = 1
| configure: exit 1
Re: [PATCH] etags support
On 21 Dec 2000, Tom Tromey wrote: "Derek" == Derek R Price [EMAIL PROTECTED] writes: creche. etags --version etags (GNU Emacs 20.5) Copyright (C) 1996 Free Software Foundation, Inc. and Ken Arnold This program is distributed under the same terms as Emacs It is pretty lame that the exuberant tags people chose to use the name `etags' for their program. The Emacs etags has been around since 1984 actually (it's been quite a while since I looked for variants - 1994 - to find a good version, though at that time, I chose one of them), there's been more than one program named 'etags' (ditto for tags++). exuberant tags is doing what some others do: when invoked by that name, it handles the corresponding format. -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
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.
Re: [suggestion] new target GTAGS.
"" == Shigio Yamaguchi [EMAIL PROTECTED] writes: In BSD system, '/usr/obj' + current directory is used for build directory. (from now on, I say it 'obj' directory.) If there is a convention in automake, I can support it. There isn't a simple convention like this. The person building the package can put the build directory anywhere he wants. Tom
Handle Libtool from multi-language-branch
Hi,
The following patch adds minimal support for Libtool from the
multi-language-branch.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.810
diff -u -p -u -r1.810 automake.in
--- automake.in 2000/12/22 05:52:37 1.810
+++ automake.in 2000/12/22 20:45:26
@@ -194,6 +194,8 @@ $libtool_line = 0;
# Files installed by libtoolize.
@libtoolize_files = ('ltmain.sh', 'config.guess', 'config.sub');
+# ltconfig appears here for compatibility with old versions of libtool.
+@libtoolize_sometimes = ('ltconfig', 'ltcf-c.sh', 'ltcf-cxx.sh', 'ltcf-gcj.sh');
# TRUE if we've seen AM_MAINTAINER_MODE.
$seen_maint_mode = 0;
@@ -6657,9 +6659,7 @@ sub initialize_global_constants
"config.guess", "config.sub", "AUTHORS", "BACKLOG", "ABOUT-GNU",
"libversion.in", "mdate-sh", "mkinstalldirs", "install-sh",
'texinfo.tex', "ansi2knr.c", "ansi2knr.1", 'elisp-comp',
- # ltconfig appears here for compatibility with old versions
- # of libtool.
- 'ylwrap', 'acinclude.m4', @libtoolize_files, 'ltconfig',
+ 'ylwrap', 'acinclude.m4', @libtoolize_files, @libtoolize_sometimes,
'missing', 'depcomp', 'compile', 'py-compile'
);
- 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
Re: ./configure .deps directory
Derek What's $(top_builddir)/.deps get used for when there aren't any C Derek sources in $(top_srcdir) or $(top_builddir)? Thanks, I checked in the fix. Tom
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: distributing files generated by configure
Hi, Derek R. Price [EMAIL PROTECTED] writes: I have several files which are generated by configure that I want three things to happen to. 1) Created in $(srcdir) Then they shouldn't be created by 'configure' :-) 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. Here's what's in Makefile.am of autoconf's latest CVS version. ## -- ## ## Maintainer rules. ## ## -- ## ## acversion.m4. ## # - acversion.m4 needs to be updated only once, since it depends on # configure.in, not on the results of a 'configure' run. # - It is guaranteed (with GNU Make) that when the version in configure.in # is changed, acversion.m4 is built only after the new version number is # propagated to the Makefile. (Libtool uses the same guarantee.) acversion.m4: $(srcdir)/acversion.m4.in $(srcdir)/configure.in sed 's,@VERSION\@,$(VERSION),g' $(srcdir)/acversion.m4.in acversion.tm4 mv acversion.tm4 $(srcdir)/acversion.m4 I think this exactly mirrors your requirements for version.c and CVSvn.texi. The idea is that only the maintainer needs to run these rules, since every 'configure' run with that package will generate the same file, anyway. That's why I said that these probably shouldn't be created by configure. The only downside being the necessity of an explicit rule with a 'sed' command, which I don't see as being too onerous. 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. - 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
