.la files from outside the current project

When I put the following: bin_PROGRAMS = foo foo_SOURCES = src/foo.cc foo_LDADD = libbar.la into a Makefile.am, the foo_DEPENDENCIES target gets libbar.la added - even though it's not included in the source. libbar.la is present in /usr/lib or /usr/local/lib. How can I avoid the auto-setting of

RE: nobase_ room for improvement

> -Original Message- > From: Tom Tromey [mailto:[EMAIL PROTECTED]] > Sent: Sunday, April 14, 2002 10:40 AM > Rob> While defining a new target to be $(includedir)/foo lets > you work > Rob> around this, it would be great to do something like: > Rob> nobase_preserve_foo_HEADERS = ...

Re: nobase_ room for improvement

> "Rob" == Robert Collins <[EMAIL PROTECTED]> writes: Rob> Installation of headers in subdirectories is more complex than it Rob> could be (IMO). Thanks for this info. Rob> The nobase_ prefix allows utilising an existing directory tree, Rob> but a non-recursive build will almost always have

Re: Seeking simple example for "shallow" tree

> "Ian" == Ian Pilcher <[EMAIL PROTECTED]> writes: Ian> Here is the simplest example I can come up with. Thanks. I made this into a test case and it worked fine with 1.6.1. >> Also, what version of automake are you using? Ian> automake-1.4p5-2 on Red Hat 7.2. This is the problem. This s

Re: make install doesn't?

> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: Bruce> Should this override inhibit the "install: install-am" line? adl> You've supplied a rule for a target that is usually output by adl> Automake, so Automake assumes that you know what you do and try adl> not to override yours

Re: make install doesn't?

> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: Bruce> Yep. It seems to be "install-recursive" related: Bruce> $ egrep install-recursive ag/autoopts/Makefile Bruce> install-exec-recursive installdirs-recursive install-recursive \ Bruce> There does not seem to be an "install-recursive"

Re: make install doesn't?

>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: [...] >> You've supplied a rule for a target that is usually output by >> Automake, so Automake assumes Bruce> Um, no, I did not supply a rule. I supplied a Bruce> *dependency*. Rules are followed by shell scripts. Bruce> That is

Re: make install doesn't?

Alexandre Duret-Lutz wrote: > Bruce> install : install-man3 > Bruce> Should this override inhibit the "install: install-am" line? > > I think so. > > Bruce> Why? > > You've supplied a rule for a target that is usually output by > Automake, so Automake assumes Um, no, I did not supply

Re: distcheck with libtool

Can you try Automake 1.6.1? It should clean subdir libtool objects correctly. -- Alexandre Duret-Lutz

distcheck with libtool

Using $ autoconf --version autoconf (GNU Autoconf) 2.53 $ automake --version automake (GNU automake) 1.6 $ libtoolize --version libtoolize (GNU libtool) 1.4e With the appended Makefile.am and configure.in, make distcheck fails with === ERROR: files left after distclean: ./src/.libs/GetOption.o .

nobase_ room for improvement

Just an idea. I use automake to make non-recursive build environments fairly routinely now. (Recursive-make-considered-bad ...) Installation of headers in subdirectories is more complex than it could be (IMO). The nobase_ prefix allows utilising an existing directory tree, but a non-recursive b

Re: make install doesn't?

>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: Bruce> install : install-man3 >> Without this override the generated Makefile should have: Bruce> Should this override inhibit the "install: install-am" line? I think so. Bruce> Why? You've supplied a rule for a target that is usu