Kohei Yoshida wrote:
On 5/30/06, Stephan Bergmann <[EMAIL PROTECTED]> wrote:
Kohei Yoshida wrote:
> Hi all,
>
> I was hoping that someone on this list could help me out on this.
>
> Here is what I'm trying to do. I have a top level module called
> 'scsolver' which provides an optimization solver component for Calc
> (or just 'Solver' for short). You don't see this in the upstream
> build since this module is still ooo-build only, just in case you're
> wondering.
>
> In this module, I need to include a set of new, private UNO IDLs to
> glue the main Solver component with an external optimization library.
> Both the main component and the external component need to be able to
> use these UNO interfaces, which means that, somehow the source files
> in this module need to be able to find the header files (*.hpp) that
> are generated from my IDLs. The external library, for now, will
> remain inside the scsolver module.
>
> So, how do I go about defining my private IDLs at module level,
> without adding them to the master list used by the entire OO.o source
> tree? I've check the source, and the chart2 module may have done
> something similar, but I'm not entirely sure how it's done.
The by far easiest approach would be to do add your UNOIDL entities to
CVS module offapi, but to not mark them as published so that they can
change over time if there is a need (you might also want to add some
comment that those are private entities that are not intended to be
published at all, and you might want to choose some appropriately named
UNOIDL module for them). That way, you do not need to fiddle with the
details of cppumaker, and your UNO types are readily available in every
UNO environment (Java, CLI, etc.) where you might need them in the
future.
Thanks for your advice Stephan. I'll follow your advice and add IDLs
to offapi. By the way, the APIs I intend to use as a glue will be
private for now, but I want them to eventually get published once they
stabilize, so that other people can easily add new backend algorithms
with much ease.
Also, is there a way to export multiple services from a single shared
library? I need to export two, or possibly more services, but I'd
rather keep them in a single shared library because those services
will be tightly coupled. Or can each shared library only export one
service?
There can be any number of services in one shared library. See
stoc/source/uriproc/component.cxx:1.4 for an example of how I organize
four services into one shared library (note that, over time, various
idioms and helpers have emerged for this, so other examples may look
rather different).
-Stephan
Thanks,
Kohei
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
