Hello!
I have a small question about installing headers and I hope someone
have the time to answer. =)
My project is laid out in a heirarchy something like this:
.../src/project/foo
.../src/project/bar
.../src/project/main
Now I want to install some of my header files when I do 'make
install'.
On Mon, Jul 28, 2003 at 05:55:15PM -0500, Raja R Harinath wrote:
> Andrew Suffield <[EMAIL PROTECTED]> writes:
>
> > On Mon, Jul 28, 2003 at 05:33:43PM -0500, Raja R Harinath wrote:
>
> >> Andrew Suffield <[EMAIL PROTECTED]> writes:
> >>
> >> > autoreconf has a habit of doing silly things like r
On Tue, Jul 29, 2003 at 09:19:19AM +0200, Mattias Br?ndstr?m wrote:
>
> fooincludedir = ${prefix}/include/project/foo
> fooinclude_HEADERS = headerA.h headerB.h headerX.h
>
> I wonder if this is the conventional way to do this?
Yes. That, or the nobase_ setting you mention.
However hardcoding $(
Hello!
A question regarding building shared libraries with automake.
My project is laid out in a heirarchy something like this:
.../src/project/foo
.../src/project/bar
.../src/project/main
In each of the leaf directories i might build a static library called
for example libfoo.a or libbar.a. Al
On Tue, 2003-07-29 at 09:19, Mattias Brändström wrote:
> Hello!
>
> I have a small question about installing headers and I hope someone
> have the time to answer. =)
>
> My project is laid out in a heirarchy something like this:
>
> .../src/project/foo
> .../src/project/bar
> .../src/project/mai
On Tue, 29 Jul 2003, Alexandre Duret-Lutz wrote:
> On Tue, Jul 29, 2003 at 09:19:19AM +0200, Mattias Br?ndstr?m wrote:
> >
> > fooincludedir = ${prefix}/include/project/foo
> > fooinclude_HEADERS = headerA.h headerB.h headerX.h
> >
> > I wonder if this is the conventional way to do this?
>
> Yes.
On Tue, Jul 29, 2003 at 10:45:18AM +0200, Mattias Br?ndstr?m wrote:
> lib_LTLIBRARIES = libproject.la
> librkcone_la_LIBADD = foo/libfoo.a
>
> When I do it like these I get a warning during the build process saying:
>
> *** Warning: Linking the shared library libproject.la against the
> *** static
On Tue, 29 Jul 2003, Alexandre Duret-Lutz wrote:
> Let Libtool build the intermediary libraries.
> http://sources.redhat.com/ml/automake/2003-07/msg00064.html
>
OK, that clears things up a bit. I tried to do it the way that you
suggested but I run into some problems. This is one of my Makefile.am
On Tue, Jul 29, 2003 at 01:16:53PM +0200, Mattias Br?ndstr?m wrote:
[...]
> automake: src/rkcone/common/Makefile.am: object `Exception.lo' created
> both with libtool and without
[...]
> I suspect there is an obvious solution to this that I am missing. Can
> someone set a library building newbie on
On Tue, 29 Jul 2003, Alexandre Duret-Lutz wrote:
> On Tue, Jul 29, 2003 at 01:16:53PM +0200, Mattias Br?ndstr?m wrote:
> [...]
> > automake: src/rkcone/common/Makefile.am: object `Exception.lo' created
> > both with libtool and without
> [...]
> > I suspect there is an obvious solution to this tha
Greetings,
On Wed, 23 Jul 2003, Alexandre Duret-Lutz wrote:
...much good advice, which I can report on here.
> >>> "Norman" == Norman Gray <[EMAIL PROTECTED]> writes:
>
> Norman> How does one optionally include C++ (or any non-C)
> Norman> sources in automake?
> [...]
> Norman> The obvious
Title: X386 사랑해요...섹스하고싶어~~~
===
- Easy ! Fast ! Powerful Nmail series!
- Download site http://passkorea.net
Hello!
I have written a small macro that uses AC_LINK_IFELSE to check for a
specific library. I had expected that it would use LDFLAGS as well as
CXXFLAGS when compiling and linking my test program. As far as I can see
LDFLAGS is not used, only CXXFLAGS and LIBS. Can someone tell me why this
is?
Hi,
Mattias Brändström <[EMAIL PROTECTED]> writes:
> I have written a small macro that uses AC_LINK_IFELSE to check for a
> specific library. I had expected that it would use LDFLAGS as well as
> CXXFLAGS when compiling and linking my test program. As far as I can see
> LDFLAGS is not used, only
On Tue, Jul 29, 2003 at 02:34:14PM +0200, Mattias Br?ndstr?m wrote:
> On Tue, 29 Jul 2003, Alexandre Duret-Lutz wrote:
>
> > On Tue, Jul 29, 2003 at 01:16:53PM +0200, Mattias Br?ndstr?m wrote:
> > [...]
> > > automake: src/rkcone/common/Makefile.am: object `Exception.lo' created
> > > both with li
On 2003-07-29 17:52:32 +, Andrew Suffield wrote:
> On Tue, Jul 29, 2003 at 02:34:14PM +0200, Mattias Br?ndstr?m wrote:
> >librkcone_LDADD = common/libcommon.a
> >
> > is for some reason not a portable thing to do?
>
> A static or convenience library is usually built without -fPIC, so
> it
>>> "Andrew" == Andrew Suffield <[EMAIL PROTECTED]> writes:
[...]
Andrew> Actually, this might be hackable by stuffing -fPIC in the
Andrew> relevant CFLAGS variable - then the warning is spurious.
As explained in earlier mails, the problem disappears as soon as
you use per-target flags such as
This is an attempt to rewrite the "Building a Shared Library"
section of the manual, in order to answer some recent questions
about Libtool libraries (notably "gathering convenience
libraries", "conditional compilation using .lo files", and
"foo.lo build both with libtool and without").
All these
Alexandre,
I noticed:
>Or we could simply use an Automake conditional as follows.
>
> lib_LTLIBRARIES = libhello.la
> if LINUX
> libhello_la_SOURCES = hello-linux.c hello-common.c
> else
> libhello_la_SOURCES = hello-generic.c hello-common.c
> endif
and immedia
I'm a newbie to using autoconf & automake & Co. I'm using it for a
small project.
The build and install work fine, but when I run "make dist-all" it
produces an empty .tar.gz file (well, not quite empty, it actually
contains 20 bytes, which I guess consist of some header info).
I was wonderin
Hello.
Andrew Suffield wrote:
[snip]
> The extra calls to config.status are there because it's a damn sight
> faster this way than letting automake-generated Makefiles call
> config.status once for each subdirectory (which they would otherwise
> do on the next build) - this is "right", but not wha
Mainly a few minor language nits; I'm not a native English speaker either,
so feel free to correct me if my "feel" is off.
> Building shared libraries is a relatively complex matter. For this
Maybe make this 'Portably building shared libraries...' - if portability
isn't an issue, building shared
> Version info:
> aclocal 1.5
> automake 1.5
You may want to consider upgrading to automake 1.7.6 (I think that's
the latest version).
If that does not resolve your problem (and your remarks), at least
we'll know it's a current problem.
24 matches
Mail list logo
