[Libreoffice] npshell build / functionality [was: Re: Tinderbox failure, last success: 2011-12-05 19:05:50]

[Michael Stahl]

On 11/01/12 10:44, Rene Engelhard wrote:
> Hi,
> 
> On Wed, Jan 11, 2012 at 10:25:12AM +0100, Michael Stahl wrote:
>> On 10/01/12 23:53, Matúš Kukan wrote:
>>> On 10 January 2012 22:41, Michael Stahl <mstahl at redhat.com> wrote:
>>>> argh, there is a SYSTEM_MOZILLA_HEADERS?  completely forgot about that,
>>>> but i guess in that case changing the header isn't such a good idea
>>>> after all :(
>>>
>>> Hmm, but does anybody use --with-system-mozilla-headers ?
> 
> Yes. And actually I think *any* distro should.
> 
>> I can't see any advantage over internal headers. (But I can't see many things.)
> 
> The advantage is that you use from system what belongs to the system. Not
> LibreOffice itself.
> 
>>> I'd say, let's just remove SYSTEM_MOZILLA_HEADERS and change the internal ones.
>>
>> hmmm.... that is also an option... actually it looks like there are both
>> headers and source files in np_sdk, and if SYSTEM_MOZILLA_HEADERS is
> 
> and the headers were always and still are a bug imho.

so how would you build the plugin on windows?

>> set, source files are still compiled, but not against the headers in
>> np_sdk, but against the system headers.
> 
> This is *exactly the point* of the option.
> You say you want SYSTEM_MOZILLA_HEADERS, so they get used.

well, almost all SYSTEM_FOO options enable taking both the headers and
the actual code from the system, so this one is weird.

> What exactly is your problem?

hmmm... thinking about it a bit more, it now looks like
SYSTEM_MOZILLA_HEADERS isn't a problem after all, because it is not used
on Windows, where the missing __declspec(dllexport) bites us; at least
on Linux GCC does not complain about the inconsistency (and on ELF based
platforms there is no equivalent of __declspec(dllimport) anyway).

so let's do the following:
- add SAL_DLLPUBLIC_EXPORT to the internal np_sdk headers
- add a check to configure.in to disable SYSTEM_MOZILLA_HEADERS if the
host platform is windows (just to be safe)

any objections?

>> this doesn't seem to make all that much sense to me, so i'll change my
>> opinion again: let's remove SYSTEM_MOZILLA_HEADERS option.
> 
> NO. Why on earth do people always want to remove options to make the build
> sane and instead rely on copies headers from system stuff? (Which the npapi
> headers are, no matter what you argue)
> 
> Stop this nonsense, please.
> 
> [ But yes, I needed http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=patches/getMIMEDescription-mismatch.diff;h=9924877e8501d0f0e2175f6c521c0bf88a1301ba;hb=refs/heads/debian-experimental-3.5 with recent headers ]

hmm... i've got a /usr/include/xulrunner-sdk-2/npapi.h here that also
looks like it would need this change.  can you commit it on master (and
adapt np_sdk/inc/npapi.h to match)?

> Yes, I use --with-system-mozilla-headers. Like I use *any* system-lib
> or -header possible (also for sane, x11, etc.)
> 
> Regards,
> 
> Rene