check_LTLIBRARIES and -rpath
I tried to use
check_LTLIBRARIES = libfoo.la
but found it added "-rpath $(checkdir)" to the libtool link, which
didn't work since $(checkdir) doesn't exist.
I thought to use this as a convenience library built only under a
"make check". If this is how it's meant to be used then I think it
should omit -rpath, the same as noinst_LTLIBRARIES.
* automake.in (handle_ltlibraries): Omit -rpath from
check_LTLIBRARIES, as per noinst_LTLIBRARIES.
--- automake.in.old Thu Jan 4 09:48:13 2001
+++ automake.in Thu Jan 4 09:46:04 2001
@@ -2049,7 +2049,8 @@
}
local ($rpath);
- if ($instdirs{$onelib} eq 'EXTRA' || $instdirs{$onelib} eq 'noinst')
+ if ($instdirs{$onelib} eq 'EXTRA' || $instdirs{$onelib} eq 'noinst'
+ || $instdirs{$onelib} eq 'check')
{
# It's an EXTRA_ library, so we can't specify -rpath,
# because we don't know where the library will end up.
Re: [patch] libtoolize --acdir --ltdir
> > Did this patch go in to libtool? > > Not yet. Having it posted to the right mailing list > ([EMAIL PROTECTED]) *might* help accelerating the process, since > then other maintainers of libtool might look into it. Thanks; I just sent the libtoolize parts of the patch to that list. --Rusty
Re: noinst_JAVA
> > Hey, a thing that's bothered me for a while is that noinst_JAVA
> > is broken.
>
> Thanks, I checked in your patch.
One problem with the patch is that since the noinst_JAVA stuff is "noinst",
there's no install-data-am dependency on "install-noinstJAVA" or
classnoinst.stamp, so a "make install" doesn't build the class files. This
means if you have a rule for building a .jar file which just jars up the
existing class files, it will be disappointingly empty unless you do a
"make" before "make install".
This can be fixed by adding "install-data-am: classnoinst.stamp" to
Makefiles which use noinst_JAVA, but I don't know where the right place
to do this in automake is. (In the stuff I work on, we add it afterward
with a kludgy AC_OUTPUT script.)
> Really for Java we should have something that makes it as
> easy to make jar files as it is to make .a libraries.
That would be nice, but it seems a lot uglier than building .a's. You
can't easily go foo_jar_SOURCES = ..., since your source files are likely
to be scattered among subdirectories, along with properties files, images,
& other build & unbuilt files which should go in the jar file. (Or maybe
you can do that... except for the problem of not knowing which .class files
came from the .java files you compiled.) Even if you can say
"foo_jar_SOURCES = foo/Bar.java foo/Baz.java", and build those files in the
current directory, you'd still have to list Bar.java and Baz.java again in
foo/Makefile.am's EXTRA_DIST.
Maybe that wouldn't be too bad, though. Does automake have other targets
which already handle this sort of thing?
> > It seems like multiple _JAVA directories could be allowed if
> > the install & uninstall rules transformed each _JAVA file name
> > from Foo.java to "Foo.class Foo\$*.class"; are there some class
> > files that would miss?
>
> Yes. Consider `bar.java':
>
> class foo { }
> public class bar { }
>
> Here you could miss `foo.class'.
Hey, you're right. Not sure why I thought javac didn't allow that.
--Rusty
autoconf, automake and gettext
And the url of that starters goodie is (yes I'm a dullard): http://gallery.uunet.be/Francis.Meyvis/ Sorry of the fuzz. -- Regards, Francis Meyvis -- Address: Laarbeekln 75/4, B-1731 Zellik, Belgium.Tel/fax: (32) 2 463 58 80
autoconf, automake and gettext
Hello, I wrote a little starters tutorial on the combination autoconf, automake and gettext. It is supposed to supplement existing documentation. It comes together with an example hello package, containing the minimal structure to build it. The configuration files in that packages are well commented (I hope). The doc directory contains the tutorial as hello.texi. Any complaints and suggestions are welcome. Have fun. -- Regards, Francis Meyvis -- Address: Laarbeekln 75/4, B-1731 Zellik, Belgium.Tel/fax: (32) 2 463 58 80
[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
