+*
+ Alexandre Oliva:
+ > Hmm... Interesting. It must have been a side effect of the enabling
+ > of forced `relink' on GNU/Linux/x86. Anyway, on platforms that
+ > actually require relinking, this problem remains, and I see no way to
+ > overcome it other than arranging for automake to install libraries
+ > before executables, as you suggest. This shouldn't be a big problem,
+ > anyway.
+ >
+ > A bigger problem could show up if two libraries in the same directory,
+ > one dependent on the other, are installed concurrently. If relinking
+ > is needed for the dependent library, we have a problem. It appears to
+ > me that user will have to live without `make -j install', in this
+ > case.
+
+ Alex Hornby
+ > Here's an Automake patch and changelog entry allow make -j install on
+ > such degenerate systems (and Linux with buggy libtool <g>)
+ >
+ > If you install to locations other that bin_ and lib_ then a larger fix
+ > is necessary, but this should fix the 90% case.
+
* in depend2.am, in specialization case, what if @SOURCE@ is found
in srcdir? We can't depend on $<! We must search explicitly.
this is a very serious problem!
Doing this requires rewriting macros before generating Makefile.in.
from joerg-martin schwarz:
- -- If Makefile.am contains $(CC), $(COMPILE), $(YLWRAP), ....
+ -- If Makefile.am contains $(CC), $(COMPILE), $(YLWRAP), ....
in an explicitly written rule, you should emit the corresponding
Makefile variables automatically.
}
}
+ if (&variable_defined('lib_LTLIBRARIES') &&
+ &variable_defined('bin_PROGRAMS'))
+ {
+ $output_rules .= "install-binPROGRAMS: install-libLTLIBRARIES\n\n";
+ }
# Print definitions users can use.
&do_one_merge_target ('install-exec', @install_exec);
$output_rules .= "\n";