Re: [udk-dev] Private UNO API for Integrated components
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? Thanks, Kohei -- Kohei Yoshida, OpenOffice.org Calc Hacker [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Private UNO API for Integrated components
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]
Re: [udk-dev] Private UNO API for Integrated components
On 5/30/06, Stephan Bergmann [EMAIL PROTECTED] wrote: 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). I will take a look at that. Thanks Stephan. :-) Kohei -- Kohei Yoshida, OpenOffice.org Calc Hacker [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
