RE: Looking for a makefile sample to generate a simple dll
Hi Ariel, Thanks for the quick response. I will check out the two approaches. Regards, Mangesh -Original Message- From: Ariel Constenla-Haile [mailto:arie...@apache.org] Sent: Wednesday, January 23, 2013 6:00 AM To: api@openoffice.apache.org Subject: Re: Looking for a makefile sample to generate a simple dll Hi Mangesh, On Tue, Jan 22, 2013 at 01:44:30PM +, Shukla, Mangesh wrote: > Hi , I am a newbie and have started working on a simple DLL, which > interacts with OpenOffice.org. My DLL does not add any new types to > the Application, but only populates information in the spreadsheet > from an external application. I have been able to create Visual > Studio project to create the DLL and it is working fine. Now I would > like to use the Makefile to generate the same as the DLL needs to be > ported on Mac as well as Linux. I am unable to get a Makefile which > could be a good starting point. I have looked at the SDK samples > makefiles, but they are either generating an EXE or building a > component DLL. I am looking for a sample which generates an external > DLL. > > I would be grateful if someone could share a sample for the same. Assuming that your library is only linked to the standard libraries, with no external dependencies, simply copy the rules to make the UNO component libraries, but remove the code that links the library to the URE libraries. The only example I've in mind right now is the MySQL SDBC driver extension, that builds both the C/Connector and the C++/Connector: http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/source/browse/source/external.mk though it's a little more complex, it does what you're trying to do. The driver is not linked to the C++/Connector, it loads the library at runtime, and uses function pointers. Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: Looking for a makefile sample to generate a simple dll
Hi Mangesh, On Tue, Jan 22, 2013 at 01:44:30PM +, Shukla, Mangesh wrote: > Hi , I am a newbie and have started working on a simple DLL, which > interacts with OpenOffice.org. My DLL does not add any new types to > the Application, but only populates information in the spreadsheet > from an external application. I have been able to create Visual > Studio project to create the DLL and it is working fine. Now I would > like to use the Makefile to generate the same as the DLL needs to be > ported on Mac as well as Linux. I am unable to get a Makefile which > could be a good starting point. I have looked at the SDK samples > makefiles, but they are either generating an EXE or building > a component DLL. I am looking for a sample which generates an > external DLL. > > I would be grateful if someone could share a sample for the same. Assuming that your library is only linked to the standard libraries, with no external dependencies, simply copy the rules to make the UNO component libraries, but remove the code that links the library to the URE libraries. The only example I've in mind right now is the MySQL SDBC driver extension, that builds both the C/Connector and the C++/Connector: http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/source/browse/source/external.mk though it's a little more complex, it does what you're trying to do. The driver is not linked to the C++/Connector, it loads the library at runtime, and uses function pointers. Regards -- Ariel Constenla-Haile La Plata, Argentina pgp9MxerottGY.pgp Description: PGP signature
Looking for a makefile sample to generate a simple dll
Hi , I am a newbie and have started working on a simple DLL, which interacts with OpenOffice.org. My DLL does not add any new types to the Application, but only populates information in the spreadsheet from an external application. I have been able to create Visual Studio project to create the DLL and it is working fine. Now I would like to use the Makefile to generate the same as the DLL needs to be ported on Mac as well as Linux. I am unable to get a Makefile which could be a good starting point. I have looked at the SDK samples makefiles, but they are either generating an EXE or building a component DLL. I am looking for a sample which generates an external DLL. I would be grateful if someone could share a sample for the same. Thanks, Mangesh
Re: Incompatible change for extensions
Hi *, Replaying in general to the thread, that is based mainly on bug 121577. The discussion about incompatibility, centered on this bug, is meaningless: bug https://issues.apache.org/ooo/show_bug.cgi?id=121582 is the real code-incompatible change, every extension developer will have to check the code and adapt it to API changes introduced by this task. It would be interesting to hear arguments against implementing the changes needed to perform the task for bug 121582. On Thu, Jan 17, 2013 at 12:24:15PM +0100, Bernard Marcelly wrote: > Of course an extension packager can be modified to the new addon syntax. > The problem is not here, it is that all existing extensions will not > work as designed unless they are each modified. Well, this is the concept of a mayor version change. Note that the mayor version change was not decided for these API/extension related changes; on the contrary, the mayor version change is a chance to perform API clean-up task that may imply incompatible API changes. Bug 121582 is one of these tasks, there are several other tasks for cleaning-up the API but human resources to perform them are small. > And modified extensions will not be compatible with previous versions > or with LibreOffice. Being compatible with LO is not OpenOffice's concern; in fact, they've introduced new API since early versions[1]; so the fact that extension can be installed on both programs is just a question of luck. [1] An example: http://api.libreoffice.org/docs/common/ref/com/sun/star/table/BorderLine2.html Regards -- Ariel Constenla-Haile La Plata, Argentina pgpdfgIcPDtUv.pgp Description: PGP signature
RE: Incompatible change for extensions
Jürgen, > The change is really easy and no big thing. Right, the change as such is very small and the benefits are negligible - but the effect is very large. The cost-benefit-relation is near catastrophic. Who will gain? A handful of developers who program extensions that are designed to work in more than one component. Listen to Bernhard Marcelly! He is a very renowned developer of extensions and right about the fact that most extensions are written for only one component. What will be gained? About 3 minutes of time saving. Who will lose? The overwhelming majority of extension developers, their users and/or customers, and the reputation of OpenOffice in general. Why is this a big thing in the real world, and a bad one? Again, listen to Bernhard Marcelly. Or listen to me. For more than 20 years I make a living out off a successful commercial product for schools and teachers at home that comes as an add-in/extension either for Microsoft Word (VBA, formerly WordBasic) or OpenOffice Writer (StarBasic). My tool is large, it adds about 65 teacher-specific functions to these word processors, it comes with a lot of additional components, documents, fonts, etc.. So I, too, know what I'm talking about. And moreover I have to deal with complex mixed system and office environments in schools and among their teachers. 1. Users Schools and teachers are mostly inexperienced users. Therefore many of them like to stick to working systems, they are certainly not at the front of technological change. Backwards compatibility is an absolute must, where you have to deal with a user scenario like this. My product is currently compatible with Microsoft Word 2000 to 2010 and OpenOffice Writer 3.0 to 3.4. Your proposed "small" change will break backwards compatibility completely. Consider the following example: School "Little Primary School" buys a school license, use at teachers' homes is included, because the main part of lesson preparation is generally done at home. Some teachers are using rather old versions of OpenOffice at home because they don't dare to update, or there are even a lot of old computers at school, where nobody has the time to update. With your proposed change, both I and the person who is responsible at school would have to explain which version of my extension to install on which OpenOffice version. That will literally swamp half of the school's teachers, who often have difficulties to even tell which version of OpenOffice they're using. Believe me, I know my customers! 2. Extension developers a) We extension developers are caught between all stools. Office developers have to write the programming environments for us but generally don't really know what we are doing. Knowing this, even otherwise arrogant Microsoft (Office for Windows department only) always took great care to ensure close connections to VBA developer communities and backwards compatibility for VBA. E.G. parts of our code are very old (1992) and written in WordBasic, but still work perfectly well. On the other hand, Microsoft's Office for Mac department never came to understand the importance of VBA, which resulted in Office for Mac 2008 coming without VBA at all. We decided to develop an alternative, an extension for OpenOffice, which I already had had in mind for some time then. This was really hard and took much longer than I thought, because the learning curve in OpenOffice is unbelievably steep, much more so than with VBA or scripting languages. (BTW, therein lies the problem you should really care about.) What I want to say is: Please don't follow the way of the Office for Mac department at Microsoft, don't be arrogant about the wishes and complaints of extension developers. Listen to Bernhard Marcelly, listen to us! b) Your proposed small change will give a lot of us a lot of headache. Not because of the change as such, but because of a lot of extra work we have to do for a new release, because our users being confronted with more update complexity, and we being confronted with growing need for support. 3. Online update mechanism for extensions Of course this could work, in an ideal world. But how many of the old but still valuable extensions in the repository have it even implemented? Not many, I think. Now, I do have it implemented. But will it really work? I remember the time when I first published the OpenOffice extension of our commercial tool. On Windows systems, which are used by most of our customers, part of our package was a third party tool for license validity checks that made use of the Windows registry. 3 month later OpenOffice 3.3 broke the way, StarBasic in all former OpenOffice versions had given access to the Windows registry, the way that was officially recommended and explained in a sample StarBasic module. How did this happen? Well, it was a fix gone wrong for some data type, something that had never caused a problem before but was thought of a
