Re: make dist fails
Hello Kai, * Kai Sterker wrote on Wed, May 06, 2009 at 12:02:07AM CEST: I have a strange problem with the 'make dist' target. I've been using automake 1.10.1 and autoconf 2.62. Updating to 1.10.2 and 2.63 showed exactly the same behavior. Which libltdl version is the one you're using, and which Automake version was its libltdl/Makefile.in created with? Can you post your toplevel Makefile.am? Can you also post the output of make dist SHELL=/bin/sh -x with all generated files unchanged? Thanks, Ralf
Re: make dist fails
Hello Kai, * Kai Sterker wrote on Wed, May 06, 2009 at 10:46:29AM CEST: On Wed, May 6, 2009 at 9:05 AM, Ralf Wildenhues wrote: Can you post your toplevel Makefile.am? Can you also post the output of make dist SHELL=/bin/sh -x with all generated files unchanged? Did configure in a fresh directory, then ran make dist SHELL=/bin/sh -x make-dist.log See attached files. The shell trace shows that this command is called ../adonthell/./install-sh -c -d adonthell-0.4.0-alpha-3/config adonthell-0.4.0-alpha-3/scripts It should create the two directories adonthell-0.4.0-alpha-3/config adonthell-0.4.0-alpha-3/scripts but apparently it fails to create the second directory. Unless you have an install-sh script with a scriptversion older than 2004-01-08.23, this should work as expected. If your script is older, then upgrade it using 'automake --add-missing --force-missing' and ensure that 'make dist' works for you now; otherwise, i.e., if your install-sh script is newer but things still fail, please post the output of rm -rf adonthell-0.4.0-alpha-3/config adonthell-0.4.0-alpha-3/scripts /bin/sh -x ../adonthell/./install-sh -c -d \ adonthell-0.4.0-alpha-3/config adonthell-0.4.0-alpha-3/scripts when executed in the top build directory. Thanks, Ralf
Re: make dist fails
On Wed, May 6, 2009 at 10:38 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: The shell trace shows that this command is called ../adonthell/./install-sh -c -d adonthell-0.4.0-alpha-3/config adonthell-0.4.0-alpha-3/scripts It should create the two directories adonthell-0.4.0-alpha-3/config adonthell-0.4.0-alpha-3/scripts but apparently it fails to create the second directory. Unless you have an install-sh script with a scriptversion older than 2004-01-08.23, this should work as expected. Tenebrae:~/adonthell/adonthell kai$ ls -la install-sh -rwxr-xr-x 1 kai staff 7122 Jul 21 2003 install-sh If your script is older, then upgrade it using 'automake --add-missing --force-missing' and ensure that 'make dist' works for you now; It does :-). Thanks a lot for your help ... would never have found that myself! Kai
[Patch] New target to generate cscope database
I was trying to make Automake generate a rule for creating cscope tags: http://rishi.fedorapeople.org/gnu/0001-New-target-to-generate-cscope-database.patch (also inlined below) I found a discussion involving Jesse Barnes (http://sources.redhat.com/ml/automake/2004-07/msg00051.html) which seemed inconclusive. I have tried this patch with Automake 1.10.2 and the msmtp source base and it seems to work, but my knowledge of Automake's internals and Perl is zero. I ran this through Jim Meyering on IRC and he said that it might be a good idea to try and reduce the amount of backslash escaping in the automake.in related changes. Since I am really clueless about Perl, I did not change anything yet. From 1396b3d1b8e576f00db4b82e156dffa12a9e4a06 Mon Sep 17 00:00:00 2001 From: Debarshi Ray ri...@gnu.org Date: Wed, 6 May 2009 14:37:39 +0530 Subject: [PATCH] New target to generate cscope database. * automake.in (handle_tags): Handle cscope. * doc/automake.texi (Tags): Document cscope. * lib/am/tags.am (CSCOPE): New macro. (cscope): New target. (cscope.file): Likewise. (cscopelist): Likewise. (distclean-tags): Remove `cscope.out', `cscope.in.out', `cscope.po.out' and `cscope.files'. * Makefile.in: Regenerate. * doc/Makefile.in: Likewise. * lib/Automake/Makefile.in: Likewise. * lib/Makefile.in: Likewise. * lib/am/Makefile.in: Likewise. * m4/Makefile.in: Likewise. * tests/Makefile.in: Likewise. --- Makefile.in| 52 ++-- automake.in| 18 - doc/Makefile.in| 38 +--- doc/automake.texi | 13 +++-- lib/Automake/Makefile.in | 32 +--- lib/Automake/tests/Makefile.in |2 + lib/Makefile.in| 43 +--- lib/am/Makefile.in |2 + lib/am/tags.am | 26 +++- m4/Makefile.in |2 + tests/Makefile.in |2 + 11 files changed, 166 insertions(+), 64 deletions(-) diff --git a/Makefile.in b/Makefile.in index 56a3126..ff7ae82 100644 --- a/Makefile.in +++ b/Makefile.in @@ -92,6 +92,7 @@ AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \ distdir dist dist-all distcheck ETAGS = etags CTAGS = ctags +CSCOPE = cscope DIST_SUBDIRS = $(SUBDIRS) DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) distdir = $(PACKAGE)-$(VERSION) @@ -438,6 +439,10 @@ ctags-recursive: list='$(SUBDIRS)'; for subdir in $$list; do \ test $$subdir = . || ($(am__cd) $$subdir $(MAKE) $(AM_MAKEFLAGS) ctags); \ done +cscopelist-recursive: + list='$(SUBDIRS)'; for subdir in $$list; do \ + test $$subdir = . || (cd $$subdir $(MAKE) $(AM_MAKEFLAGS) cscopelist); \ + done ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES) list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \ @@ -500,9 +505,20 @@ GTAGS: here=`$(am__cd) $(top_builddir) pwd` \ $(am__cd) $(top_srcdir) \ gtags -i $(GTAGS_ARGS) $$here +cscope: cscope.files + cd $(top_builddir) $(CSCOPE) -b -R -q -i cscope.files $(CSCOPE_ARGS) + +cscope.files: cscopelist-recursive cscopelist + +cscopelist: cscopelist-recursive $(HEADERS) $(SOURCES) $(LISP) + list='$(SOURCES) $(HEADERS) $(LISP)'; \ + for i in $$list; do \ + echo $(abs_srcdir)/$$i $(top_builddir)/cscope.files; \ + done distclean-tags: - -rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags + -rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags cscope.out cscope.in.out \ + cscope.po.out cscope.files distdir: $(DISTFILES) $(am__remove_distdir) @@ -788,26 +804,26 @@ ps-am: uninstall-am: uninstall-binSCRIPTS @$(NORMAL_INSTALL) $(MAKE) $(AM_MAKEFLAGS) uninstall-hook -.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) ctags-recursive \ - install-am install-exec-am install-strip tags-recursive \ - uninstall-am +.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) \ + cscopelist-recursive ctags-recursive install-am \ + install-exec-am install-strip tags-recursive uninstall-am .PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \ all all-am am--refresh check check-am clean clean-generic \ - ctags ctags-recursive dist dist-all dist-bzip2 dist-gzip \ - dist-hook dist-lzma dist-shar dist-tarZ dist-xz dist-zip \ - distcheck distclean distclean-generic distclean-tags \ - distcleancheck distdir distuninstallcheck dvi dvi-am html \ - html-am info info-am install install-am install-binSCRIPTS \ - install-data install-data-am install-dvi install-dvi-am \ - install-exec install-exec-am install-exec-hook install-html \ - install-html-am install-info install-info-am install-man \ - install-pdf install-pdf-am install-ps install-ps-am \ - install-strip installcheck installcheck-am installdirs
Re: [Patch] New target to generate cscope database
Hello Debarshi,
thank you for your work on this!
* Debarshi Ray wrote on Wed, May 06, 2009 at 11:17:19AM CEST:
I was trying to make Automake generate a rule for creating cscope
tags:
I found a discussion involving Jesse Barnes
(http://sources.redhat.com/ml/automake/2004-07/msg00051.html) which
seemed inconclusive. I have tried this patch with Automake 1.10.2 and
the msmtp source base and it seems to work, but my knowledge of
Automake's internals and Perl is zero.
Did you take any code from Jesse's patch? In that case, the ChangeLog
entry should list Jesse as author as well, and we might even need
copyright papers from Jesse, too.
A nit-picky review follows; I will fix up all those bits that you won't,
but the more you can do, the faster the whole thing will be done. :-)
First off, a few questions:
Does cscope offer enough additional functionality over, say,
Exuberant Ctags or gtags, to warrant being supported? Do many people
use it?
What happens if sources other than C, Lex, or Yacc are listed in
cscope.files?
What if files are listed more than once in cscope.files? If that is a
problem, you can reuse the awk construct that is used in the CTAGS and
other rules, but that will eliminate duplicates stemming from one
Makefile.am only.
The cscope.1 manpages I'm looking at allows to pass -Iincdir arguments,
which directs cscope to search for included headers in 'incdir'. What
exactly is this used for, and would it still be beneficial to use even
if all headers in the package are listed in *_HEADERS or *_SOURCES
files? Or would it even be necessary to pass suitable -I arguments in
order to prevent cscope from using older, installed or incompatible
versions of some header files?
The HACKING file from the git tree lists several bits missing from
this patch, namely tests ensuring that the new functionality works as
desired (also see tests/README), a NEWS file entry.
For example, presence of C, Lex, Yacc, and other sources should be
tested.
From: Debarshi Ray ri...@gnu.org
Date: Wed, 6 May 2009 14:37:39 +0530
Subject: [PATCH] New target to generate cscope database.
* automake.in (handle_tags): Handle cscope.
* doc/automake.texi (Tags): Document cscope.
* lib/am/tags.am (CSCOPE): New macro.
(cscope): New target.
(cscope.file): Likewise.
(cscopelist): Likewise.
(distclean-tags): Remove `cscope.out', `cscope.in.out', `cscope.po.out'
and `cscope.files'.
* Makefile.in: Regenerate.
FYI, in Automake we typically don't list any regenerated files in the
ChangeLog entry. They are only tracked in version control because that
allows to see easily how changes to the sources affect the generated
files.
diff --git a/automake.in b/automake.in
index 20ef3bd..b5133b1 100755
--- a/automake.in
+++ b/automake.in
@@ -3724,6 +3724,7 @@ sub handle_tags
{
my @tag_deps = ();
my @ctag_deps = ();
+my @cscope_deps = ();
if (var ('SUBDIRS'))
{
$output_rules .= (tags-recursive:\n
@@ -3747,6 +3748,17 @@ sub handle_tags
push (@ctag_deps, 'ctags-recursive');
depend ('.PHONY', 'ctags-recursive');
depend ('.MAKE', 'ctags-recursive');
+
+ $output_rules .= (cscopelist-recursive:\n
+ . \tlist=\'\$(SUBDIRS)\'; for subdir in \$\$list; do
\\\n
+ # Never fail here if a subdir fails; it
+ # isn't important.
+ . \t test \\$\$subdir\ = . || (cd \$\$subdir
+ . \$(MAKE) \$(AM_MAKEFLAGS) cscopelist); \\\n
+ . \tdone\n);
+ push (@cscope_deps, 'cscopelist-recursive');
+ depend ('.PHONY', 'cscopelist-recursive');
+ depend ('.MAKE', 'cscopelist-recursive');
}
Side note: the {tags,ctags,cscopelist}-recursive rules should be
factorized so their text appears only once in the output. That can be
done as a separate change, however.
if (saw_sources_p (1)
@@ -3769,7 +3781,8 @@ sub handle_tags
new Automake::Location,
CONFIG= @config,
TAGSDIRS = @tag_deps,
- CTAGSDIRS = @ctag_deps);
+ CTAGSDIRS = @ctag_deps,
+ CSCOPEDIRS = @cscope_deps);
set_seen 'TAGS_DEPENDENCIES';
}
@@ -3784,8 +3797,9 @@ sub handle_tags
# Otherwise, it would be possible for a top-level make TAGS
# to fail because some subdirectory failed.
$output_rules .= tags: TAGS\nTAGS:\n\n;
- # Ditto ctags.
+ # Ditto ctags and cscope.
$output_rules .= ctags: CTAGS\nCTAGS:\n\n;
+ $output_rules .= cscopelist:\n\n;
}
}
diff --git a/doc/automake.texi b/doc/automake.texi
index 09a5dd2..240fa84 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -312,7 +312,7 @@ Support for Test Suites
Miscellaneous Rules
-* Tags::
Re: Setting shared lib version not functioning
John Calcote john.calc...@gmail.com writes: One thing that bothers me a little is that we never really did solve Gerald's original problem. He said his library was created just fine when he was passing 2:0:0, but when he switched to 2:0:1, it created a library with a version number of 1:1:0. Now, why would Libtool do this? Granted, he didn't really want 2:0:1, but 2:0:1 isn't a bogus triplet, either. So why did Libtool convert it to 1:1:0? For the linux way of library versioning the library suffix is computed as (current-age).age.revision, thus 2:0:1 maps to 1.1.0. A libtool version of 1:1:0 whould map to 1.0.1. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Extra make rules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey This is probably in the automake manual but hey. I am wondering is it possible to say in a Makefile.am besides your bin_programs CFLAGS etc... Can you add extra things like a: make check rule - to run the bin_program(s) and grep for a certain output or is it best to write a script to do this? Thanks anyways - -Phil -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoBlXkACgkQAhcOgIaQQ2Fo8QCfaXQgDuik4T7062VOfvEPRW3q 93YAn0Jz8Wn1X2sZ1U8+gV4x4Gv5kHbs =1LVC -END PGP SIGNATURE-
Re: Setting shared lib version not functioning
On 5/6/2009 3:15 AM, Andreas Schwab wrote: John Calcotejohn.calc...@gmail.com writes: One thing that bothers me a little is that we never really did solve Gerald's original problem. He said his library was created just fine when he was passing 2:0:0, but when he switched to 2:0:1, it created a library with a version number of 1:1:0. Now, why would Libtool do this? Granted, he didn't really want 2:0:1, but 2:0:1 isn't a bogus triplet, either. So why did Libtool convert it to 1:1:0? For the linux way of library versioning the library suffix is computed as (current-age).age.revision, thus 2:0:1 maps to 1.1.0. A libtool version of 1:1:0 whould map to 1.0.1. Thanks Andreas. This is excellent information, but I'd like to understand why this is so. Can you point me to a reference that describes this transformation, and perhaps it's rationale? Thanks in advance, John
Re: Extra make rules
Hello Philip, * Philip Herron wrote on Wed, May 06, 2009 at 03:49:50PM CEST: This is probably in the automake manual but hey. I am wondering is it possible to say in a Makefile.am besides your bin_programs CFLAGS etc... Can you add extra things like a: make check rule - to run the bin_program(s) and grep for a certain output or is it best to write a script to do this? Yes, it is possible. For the most part, Makefile.am contents are copied into the resulting Makefile, so you can just use plain `make' rules as you would in a Makefile. Automake has support for test scripts and programs with the TESTS variable, see info Automake Tests. Cheers, Ralf
Re: Setting shared lib version not functioning
Hi John, * John Calcote wrote on Wed, May 06, 2009 at 02:18:10AM CEST: When I said ridiculous cases I really meant bogus triplets. I didn't think there was much you could do about valid triplets that are simply incorrect. I should think that Libtool might fail a build if a bogus triplet is passed, however. Which triplets are you thinking of that libtool should fail with, but currently doesn't? One thing that bothers me a little is that we never really did solve Gerald's original problem. He said his library was created just fine when he was passing 2:0:0, but when he switched to 2:0:1, it created a library with a version number of 1:1:0. Now, why would Libtool do this? Granted, he didn't really want 2:0:1, but 2:0:1 isn't a bogus triplet, either. So why did Libtool convert it to 1:1:0? * Andreas Schwab wrote on Wed, May 06, 2009 at 11:15:30AM CEST: For the linux way of library versioning the library suffix is computed as (current-age).age.revision, thus 2:0:1 maps to 1.1.0. A libtool version of 1:1:0 whould map to 1.0.1. Exactly. With a triplet of 2:0:1, on GNU/Linux, a version number of 1.1.0 is one that has semantics consistent with the semantics described in the Libtool manual: the library is compatible with a library that has a version number of 1.0.0; if both versions exist, the runtime linker will prefer the one with the higher middle number (more precisely: the glibc ldconfig utility will cause the libfoo.so.1 symlink to point to the libfoo.so.1.X.Y file with the highest X in that directory). * John Calcote wrote on Wed, May 06, 2009 at 06:04:20PM CEST: Thanks Andreas. This is excellent information, but I'd like to understand why this is so. Can you point me to a reference that describes this transformation, and perhaps it's rationale? John, please note that the mapping from -version-info A:B:C to system- specific version numbers is one where all that libtool guarantees is to try to map semantics as good as possible. It does not guarantee that it maps to a library with major version A or A-C or anything. It also does not guarantee that major versions are used consecutively. Of course it does not do weird things on purpose, but there are lots of possible mappings. For example, one thing libtool does is add 1 on systems where numbers may not be zero. For another example, if you move from 2:0:1 to 3:0:0, your Linux version will jump from 1.1.0 to 3.0.0. That's ok, as there are lots of integers left for remaining major version numbers. Cheers, Ralf
Re: Setting shared lib version not functioning
As and aside on this whole mess and before I blow my brains out (just kidding, I think) I tried starting the whole mess over and setting the version to 0:0:0 after doing a 'make maintainer-clean'. Well, everything compiled and looked OK when installed in /usr/local/lib libproject.a libproject.la libproject.so libproject.so.0 libproject.so.0.0.0 BUT!! Now when I try to recompile any application and execute I get the happy message: ./geodesic: error while loading shared libraries: libproject.so.0: cannot open shared object file: No such file or directory It did work before and /usr/local/lib is in /etc/ld.so.conf. Oh yes, in using applications, the HAVE_MALLOC gets turned off in config.h and #define malloc rpl_malloc gets inserted which the linker can't find---I edited out the config.h so I could get an executable. but that is a different problem --- I think(?). This whole thing is enough to drive one over the edge!! This is enough for one day, I'm just waiting for the Daily Show to get some sanity back. -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist
Re: Setting shared lib version not functioning
Hello Gerald, * Gerald I. Evenden wrote on Thu, May 07, 2009 at 02:58:28AM CEST: Well, everything compiled and looked OK when installed in /usr/local/lib libproject.a libproject.la libproject.so libproject.so.0 libproject.so.0.0.0 BUT!! Now when I try to recompile any application and execute I get the happy message: ./geodesic: error while loading shared libraries: libproject.so.0: cannot open shared object file: No such file or directory Can you show the link commands used for the recompilation? Can you also show the output of make install for libproject? It did work before and /usr/local/lib is in /etc/ld.so.conf. Hmm. Does it work after you run ldconfig once as root? What system does this happen on (Linux?), and which distribution? Oh yes, in using applications, the HAVE_MALLOC gets turned off in config.h and #define malloc rpl_malloc gets inserted which the linker can't find---I edited out the config.h so I could get an executable. but that is a different problem --- I think(?). That is a different issue. Presumably you used AC_FUNC_MALLOC but did not provide a replacement malloc.c; see info Autoconf --index-search AC_FUNC_MALLOC for what to do if you really want that. Cheers, Ralf
