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

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@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