[Top][All Lists]

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

Re: Vala support for automake

From: Ralf Wildenhues
Subject: Re: Vala support for automake
Date: Sat, 18 Apr 2009 18:57:33 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Jürg,

* Jürg Billeter wrote on Thu, Apr 16, 2009 at 09:19:13PM CEST:
> On Thu, 2009-04-16 at 21:09 +0200, Ralf Wildenhues wrote:
> > What about shared libraries, do they have .vapi's, too?
> Yes, shared libraries have .vapi files, too. They are installed
> into /usr/share/vala/vapi/ by default.
> The .so name and the .vapi name do not need to match in any way, the
> convention for shared libraries is to use the pkg-config name, if
> applicable. When writing the .vapi file, the compiler just uses the
> argument of the --library option and appends .vapi.

OK.  What if, as is common for libraries generated by libtool, there is
both a static and a shared library, from the same sources.  Will the
.vapi file be applicable (i.e., be the same) for both?

> > What if I want to build one big shared (or static) library from a set of
> > convenience archives (uninstalled .a libraries with PIC code)?  Do you
> > have means to generate a .vapi for the big library from the .vapi's of
> > the several small ones (plus maybe a couple of loose objects, too)?
> That's where it starts getting a bit tricky. While generating the
> big .vapi file is as simple as concatenating the .vapi files of the
> convenience libraries, I don't know how we can avoid a manual `cat' rule
> without making it a lot more complex.

Well, automake and/or libtool might be able to help out here.
This situation is a bit similar to C++ compilers needing pre-linking
actions like collecting template instantiations.

Doing something like this automatically in autotools will likely require
that we know the library name to .vapi name mapping though.


reply via email to

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