adl> 2001-10-16 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
adl> * automake.in (am_install_var): Don't strip nobase_ from $X, do
adl> this with $nodir_name only.
Here is an update of this patch, which, I beleive, should fix
the bug reported by Braden McDaniel about nodist_noinst.
2001-10-17
On Tue, Oct 16, 2001 at 08:06:53AM -0400, [EMAIL PROTECTED] wrote:
>
> On Tue, 16 Oct 2001, Raja R Harinath wrote:
>
> > [EMAIL PROTECTED] writes:
> > > On Mon, 15 Oct 2001, Gary V. Vaughan wrote:
> > >> On Sun, Oct 14, 2001 at 10:03:38PM -0400, [EMAIL PROTECTED] wrote:
> > >> > Is there a way t
On Tue, 2001-10-16 at 14:16, Raja R Harinath wrote:
> Braden McDaniel <[EMAIL PROTECTED]> writes:
> > So I tried nodist_noinst_HEADERS. This had the unexpected effect of
> > installing the headers in the root directory!
>
> That seems to be a bug in automake. Can you file a bug report?
Yup. Any
Hi,
Braden McDaniel <[EMAIL PROTECTED]> writes:
> I have some generated headers that should not be installed, and should
> not be included in the distribution of my package.
[snip]
> noinst_HEADERS keeps them from being installed, but they wind up in the
> distribution.
Right.
> So I tried nodi
I have some generated headers that should not be installed, and should
not be included in the distribution of my package.
BUILT_SOURCES doesn't work because these headers have dependecies in
SUBDIRS, and automake wants to built BUILT_SOURCES before building
SUBDIRS.
noinst_HEADERS keeps them fro
Hello,
I've discovered some problem with depcomp file. If I haven't it in my
root and run automake --foreign -a, it will be created, but it will not
be listed in DIST_COMMON files of Makefile.in. As a result, it is
missing in distribution package and it cannot be successfully built. If
I
Your problem is probably not with sed, but with a broken AM_AUX_DIR macro
definition under zsh (which is what /bin/sh on MacOS X is). This
discussion has been going on for several days. If you add to a
configure.ac or acinclude.m4 the following, it will work:
AC_DEFUN([AM_AUX_DIR_EXPAND], [
# ex
le mar 16-10-2001 at 14:52 Robert Collins a écrit :
> Just link against the .la file.
>
> Automake then gets libtool to do the rest.
>
> Rob
Ok, thanks Robert, it worked.
I tried this a few days ago but gave up after a few errors
due to syntax (i tried something like remodl_LDADD = -L. -l libia
Just link against the .la file.
Automake then gets libtool to do the rest.
Rob
- Original Message -
From: "Stéphane Genaud" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 16, 2001 10:44 PM
Subject: linking against a freshed libtoolized library
Hi,
I would like my M
Hi,
I would like my Makefile.am to build a library (say libiasp)
with libtool, and then build a binary using functions
from that library, before the library has been installed
into its definitive directory.
However, i don't know if a correct way to proceed is to
link my binary with the libiasp.
On Tue, 16 Oct 2001, Raja R Harinath wrote:
> [EMAIL PROTECTED] writes:
> > On Mon, 15 Oct 2001, Gary V. Vaughan wrote:
> >> On Sun, Oct 14, 2001 at 10:03:38PM -0400, [EMAIL PROTECTED] wrote:
> >> > Is there a way to tell libtool that it needs to set some additional
> >> > runtime variables i
[Please keep this discussion public.]
Martin Frydl <[EMAIL PROTECTED]> writes:
> Hello Alexandre,
> thank you for the patch. Now it does not complain about unknown
> variables, but another problem emerged. When installation is run, it
> does not create the subdirectories for those header file
>>> "Martin" == Martin Frydl <[EMAIL PROTECTED]> writes:
[...]
Martin> nobase_include_HEADERS = dir1/file1.h dir2/file2.h
Martin> but I get errors:
Martin> include/Makefile.am:: variable `include_HEADERS' not defined
IMHO, Automake is stripping the 'nobase_' prefix at places it'd
rather no
13 matches
Mail list logo
