automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: question using VPATH'S ...


From: Stepan Kasal
Subject: Re: question using VPATH'S ...
Date: Tue, 1 Jul 2008 12:39:54 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hello,

On Wed, Jul 02, 2008 at 02:07:36AM +1930, Roberto Alejandro Espí Muñoz wrote:
> Ok, I thinks I didn't explain myself correctly then ... From what I
> saw there I can use either bindir, libdir or includedir for when I'm
> installing the completed targets.  What I want to do is to locate them
> before that moment.

> What I would like to do is
> determine exactly where my targets end up in my project directory
> before I install them.  All my binaries on a bin subdirectory for
> example, or my shared objects in a lib directory, my object files in a
> obj directory.

we hear this a lot, since many people are accustomed to this type of
setup.  Automake does not support this: the object file is placed
next to each source file, or better in a correcponding directory in
the build tree.  When you are going to build for more platforms, you
just create several build trees and run configure on each platform in
a separate subdirectory.

We believe that this style is more practical than the one with
subdirs bin lib, etc., once you get accustomed to it.
In any case, this style is an integral part of Automake design and
it's hard to talk Automake into something else.

> I noticed that all my libs and binaries are
> ending up in a hidden .libs directory.

Oh, that!  That seems confusing, and it looks as if it did not
corresponded to what I said above.

This is done by libtool.  Libtools is dedicated to portable build and
install shared libraries.  Not all platforms use GNU linker: some
platforms cannot handle dependecies of dynamic libraries, so the
complete recursively evaluated list has to be present on the command
line; some platforms even require special change to the linked
dynamic library when it is installed, depending on the desttination
directory.  Libtool is able to transparently handle all of this.

But the price for this is that you have to use *.lo files as handles
for object files, and *.la files as handles for linked libraries.
The la file is a common handle for static and dynamic library;
actually, this is another benefit: you do not have to think about
static and dynamic library separately, the *.la file represents both.
And since the compile options for static and dynamic libraries often
differ, the *.lo is often also representing two physical object
files.

The real objeck files and static and dynamic libraries are hidden
in subdir .libs/, but you should pretend you do not know.  ;-)
The game is that you are using *.la and *.lo files all the time, and
that you use "./libtool compile" and "./libtool link" as your
compiler and linker, respectively.

(Yes, some distributions have a rule that *.la files may not be
part of the resulting package, but that has little to do with
this---you just remove *.la from the installed tree at the very end
of your build.)

The above paragraphs cannot teach you how to use libtool, but I hope
they help to clear the confusion: .libs is in no way similar to the
"bin lib" setup you mentioned in another part of your mail.

Have a nice day,
        Stepan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]