It _would_ be nice to have a more flexible, object oriented interface to Inline. Inline's UI focus (for users) has been entirely on the "use Inline" interface. Which has a "code wizard"-like fragility. Unsupported tasks require creating your own Inline module.
Python's Weave provides a second, lower-level api to help avoid this. (Eg, "Extension Modules" in http://www.scipy.org/site_content/weave/tutorial.html It's towards the bottom.) For C-code-oriented tasks, one approach is to inherit from Inline::C, modify the MAKEFILE configuration to expect extra object files (and libraries, etc), let the build directory be created, generate the extra C files, and then handoff to Inline::C. I used this approach to make Inline::SWIG http://www.vendian.org/mncharity/dir3/inline/swig/ . One might now use USING, rather than inheritance, to intercept the process. But blending two C-generating Inline ILSMs might still be... non-trivial. One approach to your task might be to try taking Inline::Flex, or Bison, and make an object-oriented interface just for it. Then teach the other to use it. But an non-declarative api is perhaps the real solution. It could be interesting to walk through Inline.pm and the ILSMs, ripping out functionality into an "Inline::Util"(?), trying to create a procedural api. Ideally an object-oriented one. Later, Inline and the ILSMs might then migrate their implementations to the new api. This is on my "infinite" todo list, but that's been true for a few years now. :( Mitchell Charity From: nadim <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Inline Config - a modularity problem Date: Sun, 20 Oct 2002 09:01:52 +0200 User-Agent: KMail/1.4.1 References: <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> Hi all, I also have a problem with how Config is used. I see Config in the following way, it's a way to control the 'make' system of Inline. Unfortunately the control is sometiles too limited for me. An example or two will help. Use Inline C => 'A' ; perl code Use Inline C => 'B' ; A and B are processed separately, this might be the right thing some times but not all the time. use Inline Flex => 'some flex code' ; use Inline Bison => 'some bison code' ; In this case the bison code is dependent on the code flex generated, what I need to have a better contol over how things get compiled and when. Worse is when I have a external dependency I want to update due to the compilation of, say, the Flex code. I simply don't know where to do it! my 2 Euro cents. Nadim.
