Re: [dev] Build System and visibility
On 11/17/09 19:06, Mathias Bauer wrote: Frank Schoenheit, Sun Microsystems Germany wrote: Hi Bjoern - map files - explicitly setting a compiler flag in the make file - XX_DLL_EXPORT/XX_DLL_IMPORT/XX_DLL_PRIVATE and friends However, using the XX_DLL_PRIVATE and friends should be enough for everyone, right? At least we'd need a makefile-clause for setting a default, /me thinks. For instance, for libs exporting the usual three UNO entry points component_*, I would like to have a make everything private directive, plus a PUBLIC statement for the three functions. That's possible with declaring the three fucntions XX_DLL_PUBIC and - as Björn suggested - defaulting everything else to private. Note that for a UNO component library that only exports the three component_* functions, you do not need the OOO_DLLPUBLIC_* overhead (what legacy code calls *_DLLPUBLIC, carelessly polluting the macro namespace), but just SAL_DLLPUBLIC_EXPORT (see http://wiki.services.openoffice.org/wiki/Symbol_Visibility). So far I haven't seen any case where the XX_DLL_ stuff wouldn't work. So we are still waiting for such an example. One (hopefully minor) point that comes to mind is that SAL_DLLPRVIATE is a nop on Windows, so there libraries potentially export more than necessary (and more than if they used carefully crafted map files). -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build System and visibility
On 11/19/09 14:45, Eike Rathke wrote: On Monday, 2009-11-16 15:11:16 +0100, Bjoern Michaelsen wrote: - map files AFAIK they are needed because they provide versioning information that is crucial for the SDK libraries. Stephan Bergmann probably knows all details. Yes, the one important difference between (ELF style) version map files and the DLL_EXPORT/IMPORT machinery is that the former allows for versioning of symbols while the latter does not. (With such symbol versioning, in short, client libraries can conveniently specify which version of a dependency library they actually need.) So, for libraries with stable, evolving ABIs (like the URE ones, or sofficeapp) we will probably want to continue using version map files. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build System and visibility
Hi Bjoern, On Monday, 2009-11-16 15:11:16 +0100, Bjoern Michaelsen wrote: - map files AFAIK they are needed because they provide versioning information that is crucial for the SDK libraries. Stephan Bergmann probably knows all details. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the e...@sun.com account, which I use for mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks. pgpQGk3M0daJG.pgp Description: PGP signature
Re: [dev] Build System and visibility
Hi Bjoern - map files - explicitly setting a compiler flag in the make file - XX_DLL_EXPORT/XX_DLL_IMPORT/XX_DLL_PRIVATE and friends However, using the XX_DLL_PRIVATE and friends should be enough for everyone, right? At least we'd need a makefile-clause for setting a default, /me thinks. For instance, for libs exporting the usual three UNO entry points component_*, I would like to have a make everything private directive, plus a PUBLIC statement for the three functions. For other libs, which mainly provide tools for client code, a make everything public directive would be useful. Which means that you'd still need 2 of the 3 mechanisms, and the only thing you could spare are the map files. Not sure this would be worth the effort. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build System and visibility
On Tue, 17 Nov 2009 10:32:21 +0100 Frank Schoenheit, Sun Microsystems Germany frank.schoenh...@sun.com wrote: At least we'd need a makefile-clause for setting a default, /me thinks. For instance, for libs exporting the usual three UNO entry points component_*, I would like to have a make everything private directive, plus a PUBLIC statement for the three functions. The default would be everything private. For other libs, which mainly provide tools for client code, a make everything public directive would be useful. These tools libs fall in two categories: - either they are small helper libs, in which case it is not much effort to make every PUBLIC explicit in the source. - or it is one of the bigger framework libraries, in which case you would want to only export what is absolutely needed - default: everything private. Which means that you'd still need 2 of the 3 mechanisms, and the only thing you could spare are the map files. Not sure this would be worth the effort. I do not think that we still have that many libs that are not explicitly marked PRIVATE/PUBLIC on the function. So it would be only about those few renegade libs that do not follow the convention. A very important sideeffect would be that the visibility of a function can be seen directly in the source, not by: - the source - the mapfile - the makefile - That would be a huge improvement in readability. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build System and visibility
The only caveat that comes to mind is that you would require a private/public mechanism of every compiler. That holds true for all the major platforms, though. For UNO libraries the export of only basically three symbols (plus a plethora of compiler details) is essential because there are likely to be duplicate symbols else and there is no easy way to find such clashes. For the framework libs as you called them like vcl, sfx2, svx the PRIVATE is optional in the sense that these should still work afterwards. So if you rely on compiler visibility exclusively, it might break one of the less often built platfoms. If you're asking whether one comes to mind, I don't know of any. And one more concrete problem: you'd have to ensure that all symbols reflected as not exported in the map files now actually have the corresponding PRIVATE statement; it might be that there are some that currently haven't owed to the fact that we have multiple mechanisms. However we would need to avoid duplicate symbols here, too. Just my 2 cents, pl bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: I do not think that we still have that many libs that are not explicitly marked PRIVATE/PUBLIC on the function. So it would be only about those few renegade libs that do not follow the convention. A very important sideeffect would be that the visibility of a function can be seen directly in the source, not by: - the source - the mapfile - the makefile - That would be a huge improvement in readability. Best Regards, Bjoern -- One SVN to rule them all, One SVN to check out from, One SVN to commit them all and on the harddisks bind them In Las Vegas where the server lies. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build System and visibility
Frank Schoenheit, Sun Microsystems Germany wrote: Hi Bjoern - map files - explicitly setting a compiler flag in the make file - XX_DLL_EXPORT/XX_DLL_IMPORT/XX_DLL_PRIVATE and friends However, using the XX_DLL_PRIVATE and friends should be enough for everyone, right? At least we'd need a makefile-clause for setting a default, /me thinks. For instance, for libs exporting the usual three UNO entry points component_*, I would like to have a make everything private directive, plus a PUBLIC statement for the three functions. That's possible with declaring the three fucntions XX_DLL_PUBIC and - as Björn suggested - defaulting everything else to private. For other libs, which mainly provide tools for client code, a make everything public directive would be useful. We have been there and it wasn't a good experience. There are always some functions that shouldn't be exported. All libraries that are candidates for exporting most (not everything) AFAIK are using the XX_DLL_PRIVATE/PUBLIC stuff already, especially the big ones like svx etc. So currently we have no such library. The alternative to the XX_DLL_PUBLIC/PRIVATE directives btw. was using LDUMP and filter lists. That's something we definitely should remove. Which means that you'd still need 2 of the 3 mechanisms, and the only thing you could spare are the map files. Not sure this would be worth the effort. So far I haven't seen any case where the XX_DLL_ stuff wouldn't work. So we are still waiting for such an example. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Build System and visibility
Hi List, again some stuff from the Build Environment Effort(1). While figuring out the way we build libraries with the OpenOffice.org build system it became apparent that we seem to have way to many redundant ways to set the visibility of functions. From the top of my head: - map files - explicitly setting a compiler flag in the make file - XX_DLL_EXPORT/XX_DLL_IMPORT/XX_DLL_PRIVATE and friends However, using the XX_DLL_PRIVATE and friends should be enough for everyone, right? So, it should be possible to simplify the build by only using XX_DLL_PRIVATE and friends, or does anybody see a use case that is not covered by it? If so, I would like to hear it ... ;-) Best Regards, Bjoern (1) http://wiki.services.openoffice.org/wiki/Build_Environment_Effort -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
