This is something I wanted when *I* was using Inline on a project at
ActiveState some 18 months ago.
Generically, you want some type of make-like dependency, and be able to
trigger an action from it. This should be pretty easy to do. I'd like some
feedback on what the best way to do it would be, whether portability would be
a concern, etc.
I'll give it a first draft to start the discussion:
use Inline C => DATA =>
MYEXTLIB => 'foolib/mylib.a',
DEPENDS => {RULE => 'foolib/mylib.a',
ACTION => 'make -C foolib mylib.a',
};
This begs for refactoring. It allows for a lot of flexibility, but that's
probably not what you need. You probably just want it to DWIM. How about this
heuristic:
1) If you specify your library with MYEXTLIB (what a dumb name ;)
2) If the MYEXTLIB file is in a subdirectory (./foolib)
3) If the subdirectory (./foolib) contains a Makefile and an empty
file called .inline
4) Then Inline will invoke 'make ./foolib mylib.a' or some portable
variant thereof
It will be up to you to make a rule for .inline that makes sense.
The only problem I see here is that this code should be in Inline::C
which is never loaded unless the Inlined code needs to be compiled. Hmm.
We could allow you to opt in with a syntax like:
use Inline C => DATA =>
ENABLE => AUTOBUILD =>
MYEXTLIB => 'foolib/mylib.a';
I like this because other languages like Inline::Java might be able to
use it as well.
I think this needs a little more thought. Comments appreciated.
Cheers, Brian
On 29/04/02 17:06 +0100, Nicholas Clark wrote:
> I'm using Inline::C to let me write tests for a C routines I'm developing.
> I have small test wrapper C code in my perl, and it links against a library.
> However, I frequently tweak and rebuild me library without changing my
> Inline C.
>
> Is it possible to tell Inline::C that the C code "depends" on a library,
> so that it will automatically rebuild (and hence relink) the Inline
> code if the library changes. I realise one solution would be to make my
> library a shared object, but I don't want to do that.
> (because ultimately it's for writing other C programs with, and they are
> going to staticly link against it)
>
> Nicholas Clark
