LibreOfficeKit header files include directives

classic Classic list List threaded Threaded
14 messages Options
Sander Maijers Sander Maijers
Reply | Threaded
Open this post in threaded view
|

LibreOfficeKit header files include directives

At this revision
(https://github.com/LibreOffice/online/tree/341c9dcc96dcf84cadfabcce2c3eabc09c1bf8d1/bundled/include/LibreOfficeKit),
I can’t generate bindings for Rust from LibreOfficeKit header files. The
reason is that I have no way to specify include paths while the
LibreOfficeKit header files assume their sibling header files are to be
found in the system include paths, based on the `< >` include directive
syntax. I think that’s incorrect since LibreOfficeKit is a unit itself;
all header files are supposed to be adjacent in the same directory tree.
I found support for my view in this previous discussion
(https://lists.freedesktop.org/archives/libreoffice/2017-October/078601.html).

I propose the attached patch. With it, generating Rust bindings for
LibreOfficeKit has been tested to succeed.


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

libreofficekit_non_system_header_files.patch (1K) Download Attachment
jan iversen-5 jan iversen-5
Reply | Threaded
Open this post in threaded view
|

Re: LibreOfficeKit header files include directives

Hi

your patch does not work with the iOS modules. I also did a short rust search, and it seems include path is supported:

I recommend not to activate this patch.

RGDS
Jan I

On Sun, 11 Feb 2018 at 18:04, Sander Maijers <[hidden email]> wrote:
At this revision
(https://github.com/LibreOffice/online/tree/341c9dcc96dcf84cadfabcce2c3eabc09c1bf8d1/bundled/include/LibreOfficeKit),
I can’t generate bindings for Rust from LibreOfficeKit header files. The
reason is that I have no way to specify include paths while the
LibreOfficeKit header files assume their sibling header files are to be
found in the system include paths, based on the `< >` include directive
syntax. I think that’s incorrect since LibreOfficeKit is a unit itself;
all header files are supposed to be adjacent in the same directory tree.
I found support for my view in this previous discussion
(https://lists.freedesktop.org/archives/libreoffice/2017-October/078601.html).

I propose the attached patch. With it, generating Rust bindings for
LibreOfficeKit has been tested to succeed.

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
--
Sent from My iPad, sorry for any misspellings.

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Sander Maijers Sander Maijers
Reply | Threaded
Open this post in threaded view
|

Re: LibreOfficeKit header files include directives

What does not work with the iOS modules?


On 11-02-18 21:51, jan iversen wrote:
Hi

your patch does not work with the iOS modules. I also did a short rust search, and it seems include path is supported:

I recommend not to activate this patch.

RGDS
Jan I

On Sun, 11 Feb 2018 at 18:04, Sander Maijers <[hidden email]> wrote:
At this revision
(https://github.com/LibreOffice/online/tree/341c9dcc96dcf84cadfabcce2c3eabc09c1bf8d1/bundled/include/LibreOfficeKit),
I can’t generate bindings for Rust from LibreOfficeKit header files. The
reason is that I have no way to specify include paths while the
LibreOfficeKit header files assume their sibling header files are to be
found in the system include paths, based on the `< >` include directive
syntax. I think that’s incorrect since LibreOfficeKit is a unit itself;
all header files are supposed to be adjacent in the same directory tree.
I found support for my view in this previous discussion
(https://lists.freedesktop.org/archives/libreoffice/2017-October/078601.html).

I propose the attached patch. With it, generating Rust bindings for
LibreOfficeKit has been tested to succeed.

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
--
Sent from My iPad, sorry for any misspellings.


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Sander Maijers Sander Maijers
Reply | Threaded
Open this post in threaded view
|

Non-portable configure.ac

In reply to this post by jan iversen-5

./configure fails on my system because configure.ac does not work when /bin/sh is not Bash but a POSIX shell such as dash.

Please review the attached patch.

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

portable_configure_ac.patch (551 bytes) Download Attachment
Sander Maijers Sander Maijers
Reply | Threaded
Open this post in threaded view
|

How to disable libexttextcat?

In reply to this post by jan iversen-5
Building fails for me because of this issue
https://github.com/LibreOffice/libexttextcat/issues/2 .

libexttextcat does not seem like a critical component for a slimmed down
LibreOffice build for development purposes. May I disable this
dependency, and if so, how?
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Tor Lillqvist-2 Tor Lillqvist-2
Reply | Threaded
Open this post in threaded view
|

Re: Non-portable configure.ac

In reply to this post by Sander Maijers
On what OS is this? If Linux, what distro? Debian has dash as /bin/sh, but there are plenty of people building LibreOffice on Debian that haven't reported this issue. What configuration parameters do pass to autogen.sh (or ./configure)? Is this related to what PRODUCTNAME_WITHOUT_SPACES ends up containing in config_host.mk? Do you use a --with-product-name="Something With Spaces" option?

--tml


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
David Tardon David Tardon
Reply | Threaded
Open this post in threaded view
|

Re: How to disable libexttextcat?

In reply to this post by Sander Maijers
Hello,

On Wed, 2018-02-14 at 18:19 +0100, Sander Maijers wrote:
> Building fails for me because of this issue
> https://github.com/LibreOffice/libexttextcat/issues/2 .
>
> libexttextcat does not seem like a critical component for a slimmed
> down
> LibreOffice build for development purposes. May I disable this
> dependency, and if so, how?

No, you can't. LibreOffice does have a bazillion of dependencies.
Adding flags to disable each one of them separately would only make the
situation worse, as most of the combinations would be never or rarely
used and likely broken. We need less configure options, not more.

D.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Sander Maijers Sander Maijers
Reply | Threaded
Open this post in threaded view
|

Re: Non-portable configure.ac

In reply to this post by Tor Lillqvist-2

Linux Host 4.15.3-2-ARCH #1 SMP PREEMPT Thu Feb 15 00:13:49 UTC 2018 x86_64 GNU/Linux

LSB_VERSION=1.4
DISTRIB_ID=Arch
DISTRIB_RELEASE=rolling
DISTRIB_DESCRIPTION="Arch Linux"

Build script: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=libreoffice-slim-git

I have set dash as /bin/sh.

./configure fails due a syntax error, since `${PRODUCTNAME// /}` not a portable syntax. So the issue does not depend on the particular product name, which becomes ‘LibreOfficeDev’ by the way.


On 14-02-18 19:51, Tor Lillqvist wrote:
On what OS is this? If Linux, what distro? Debian has dash as /bin/sh, but there are plenty of people building LibreOffice on Debian that haven't reported this issue. What configuration parameters do pass to autogen.sh (or ./configure)? Is this related to what PRODUCTNAME_WITHOUT_SPACES ends up containing in config_host.mk? Do you use a --with-product-name="Something With Spaces" option?

--tml



_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Eike Rathke-2 Eike Rathke-2
Reply | Threaded
Open this post in threaded view
|

Re: Non-portable configure.ac

Hi Sander,

On Wednesday, 2018-02-21 14:03:49 +0100, Sander Maijers wrote:

> I have set dash as /bin/sh.

"Funny", because Debian has dash there as well and no problem.

Anyway.. this

> ./configure fails due a syntax error, since `${PRODUCTNAME// /}` not a
> portable syntax.

has been changed to
PRODUCTNAME_WITHOUT_SPACES=$(printf %s "$PRODUCTNAME" | sed 's/ //g')

on master.

  Eike

--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (849 bytes) Download Attachment
Sander Maijers Sander Maijers
Reply | Threaded
Open this post in threaded view
|

Re: Non-portable configure.ac

Thanks!

Note that checkbashisms 2.17.12-1 failed to catch this when I debugged this issue.

https://www.archlinux.org/packages/community/any/checkbashisms/

Also note that on Arch Linux, I used dash 0.5.9.1-1, whereas Debian only has various older versions

https://packages.debian.org/search?keywords=dash

Running shellcheck and checkbashisms regularly is advisable even for autoconf generated scripts.


On 22-02-18 12:07, Eike Rathke wrote:
Hi Sander,

On Wednesday, 2018-02-21 14:03:49 +0100, Sander Maijers wrote:

I have set dash as /bin/sh.
"Funny", because Debian has dash there as well and no problem.

Anyway.. this

./configure fails due a syntax error, since `${PRODUCTNAME// /}` not a
portable syntax.
has been changed to
PRODUCTNAME_WITHOUT_SPACES=$(printf %s "$PRODUCTNAME" | sed 's/ //g')

on master.

  Eike



_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Jan-Marek Glogowski Jan-Marek Glogowski
Reply | Threaded
Open this post in threaded view
|

Re: Non-portable configure.ac

Am 22.02.2018 um 18:36 schrieb Sander Maijers:

> Note that checkbashisms 2.17.12-1 failed to catch this when I debugged
> this issue.
>
> https://www.archlinux.org/packages/community/any/checkbashisms/
>
> Also note that on Arch Linux, I used dash 0.5.9.1-1, whereas Debian only
> has various older versions
>
> https://packages.debian.org/search?keywords=dash
>
> Running shellcheck and checkbashisms regularly is advisable even for
> autoconf generated scripts.

On my Ubuntu I also have sh -> dash. But I guess, like most people, I
use autogen.sh to run configure with flags from autogen.input.

And autogen.sh is really a Perl script, and Perls system call runs
configure by calling "bash ./configure …". That's probably why nobody
caught this yet. Now I have no idea why Perls system function uses bash
as shell…

Jan-Marek
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Sander Maijers Sander Maijers
Reply | Threaded
Open this post in threaded view
|

Re: Non-portable configure.ac

I must say autogen.sh being a Perl script surprised, even dismayed me.

Problems suchs as the one you describe are only to be expected when bolting on Perl for this purpose.

Have any arguments been made against getting rid of Perl, in this instance?


On 22-02-18 19:29, Jan-Marek Glogowski wrote:
Am 22.02.2018 um 18:36 schrieb Sander Maijers:
Note that checkbashisms 2.17.12-1 failed to catch this when I debugged
this issue.

https://www.archlinux.org/packages/community/any/checkbashisms/

Also note that on Arch Linux, I used dash 0.5.9.1-1, whereas Debian only
has various older versions

https://packages.debian.org/search?keywords=dash

Running shellcheck and checkbashisms regularly is advisable even for
autoconf generated scripts.
On my Ubuntu I also have sh -> dash. But I guess, like most people, I
use autogen.sh to run configure with flags from autogen.input.

And autogen.sh is really a Perl script, and Perls system call runs
configure by calling "bash ./configure …". That's probably why nobody
caught this yet. Now I have no idea why Perls system function uses bash
as shell…

Jan-Marek


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Tor Lillqvist-2 Tor Lillqvist-2
Reply | Threaded
Open this post in threaded view
|

Re: Non-portable configure.ac

Perl is great.

--tml

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Miklos Vajna-4 Miklos Vajna-4
Reply | Threaded
Open this post in threaded view
|

Re: Non-portable configure.ac

In reply to this post by Sander Maijers
Hi,

On Thu, Feb 22, 2018 at 08:42:51PM +0100, Sander Maijers <[hidden email]> wrote:
> I must say autogen.sh being a Perl script surprised, even dismayed me.

Look at the git history of the file
(1e5339ec9209a5c89851f79adb1c49f169b6d3e5), especially the part that
reads arguments from autogen.input and (currently) handles whitespace in
them correctly. It's not impossible to do the same in bash, but
re-introducing code like

-    p=`echo "$param" | sed "s/'/'\\\\\\''/g"`

would not be ideal.

Regards,

Miklos

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (188 bytes) Download Attachment