problems with "aoutoload" in 3.1.55
Carlo de Falco
carlo.defalco at gmail.com
Mon May 25 02:12:00 CDT 2009
On 25 May 2009, at 07:49, Jaroslav Hajek wrote:
> On Fri, May 22, 2009 at 10:11 PM, Carlo de Falco
> <carlo.defalco at gmail.com> wrote:
>>
>> On 22 May 2009, at 22:08, John W. Eaton wrote:
>>
>>> On 22-May-2009, Carlo de Falco wrote:
>>>
>>> | If you decide to take this approach, could you suggest a way to
>>> | modify my package so that the autoladed version is used by default
>>> and
>>> | the m-file is only kept as a backup resource?
>>>
>>> Create a single .oct file for each function you wish to define
>>> instead
>>> of autoloading them from a single .oct file?
>>
>> Yes, that's what I am usually doing. But in this case the functions
>> in
>> the .oct file depend on each other,
>> so I had to put them in the same file to avoid using to many calls to
>> feval...
>>
>>> jwe
>> c.
>
> In that case, you can create a separate source with the core
> functions, and then just wrap them in DLDs, one per .oct file (linked
> with the "common" file).
> mkoctfile -c common.cc
> mkoctfile func1.cc common.o
> mkoctfile func2.cc common.o
> etc.
>
> That's called "software engineering" (nah, I'm kidding, it's called "a
> trick to make stuff work").
>
> regards
>
Jaroslav,
Thanks that's a cool idea!
I was actually thinking of creating a shared library with the core
functions and link to it
but I didn't know how to do it in a portable way. Static linking is
much simpler.
Thanks,
Carlo
More information about the Bug-octave
mailing list