[autotools] gtk-doc.m4 - cross compile support

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[autotools] gtk-doc.m4 - cross compile support

Gtk+ - Documentation mailing list
Hello,

gtk-doc.m4[1] is using pkg-config to locate the gtk-doc tool. This is
working for native build, however, when cross compiling the gtk-doc
tool should be installed on the build and not host, hence it is not
available at pkg-config.

It seems like pkg-config is just used for testing version
compatibility, this can be replaced by executing a tool with version
argument or when cross compiling require an environment variable with
version of the tool to bypass.

What do you think the best way to support cross compile?

Thanks,
Alon

[1] https://github.com/GNOME/gtk-doc/blob/master/buildsystems/autotools/gtk-doc.m4
_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: [autotools] gtk-doc.m4 - cross compile support

Gtk+ - Documentation mailing list
On Sat, 6 Oct 2018 at 18:50, Alon Bar-Lev via gtk-doc-list
<[hidden email]> wrote:
> What do you think the best way to support cross compile?

I'm not an expert at all, but my understanding is that gtk-doc can't
really work properly in a cross compiler.

It needs to read the gir file for a project, and the gir file is made
by both scanning source code and doing run-time introspection. Source
code scans are obviously fine, but run time introspection won't work.

Rather than trying to generate docs in the target, I build my docs in
the host and copy the formatted output over.

John
_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: [autotools] gtk-doc.m4 - cross compile support

Gtk+ - Documentation mailing list
On Sun, Oct 7, 2018 at 3:53 PM John Cupitt via gtk-doc-list
<[hidden email]> wrote:

>
> On Sat, 6 Oct 2018 at 18:50, Alon Bar-Lev via gtk-doc-list
> <[hidden email]> wrote:
> > What do you think the best way to support cross compile?
>
> I'm not an expert at all, but my understanding is that gtk-doc can't
> really work properly in a cross compiler.
>
> It needs to read the gir file for a project, and the gir file is made
> by both scanning source code and doing run-time introspection. Source
> code scans are obviously fine, but run time introspection won't work.
>
> Rather than trying to generate docs in the target, I build my docs in
> the host and copy the formatted output over.

When cross compiling both the build and host are available for you,
the build is the native compiler and utilities and the host is the
target architecture.
This means that you can run the gtk utilities that are installed on
the build part to generate documentation.
The only problem with this gtk-doc.m4 is that it uses pkg-config to
check for existence and version of the tools, while the pkg-config is
reporting packages installed on the host and not on the build.
_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: [autotools] gtk-doc.m4 - cross compile support

Nicola Fontana-3
Il giorno dom, 07/10/2018 alle 16.09 +0300, Alon Bar-Lev via gtk-doc-list ha
scritto:

> On Sun, Oct 7, 2018 at 3:53 PM John Cupitt via gtk-doc-list
> <[hidden email]> wrote:
> > ...
> > Rather than trying to generate docs in the target, I build my docs in
> > the host and copy the formatted output over.
>
> ...
> This means that you can run the gtk utilities that are installed on
> the build part to generate documentation.
> ...

Hi,

you say that you can/should run gtk-doc on the build side, and I fail to
understand what makes you think so.

In particular, AFAIK gtkdoc-scangobj must compile and run a program to
introspect the hierarchy, and I don't see how this can be possible if
you are on the build side. Maybe you can workaround that, but I'm pretty
sure it is as straightforward as you seem to think.

I double John's suggestion: build on the host and copy the result.

Ciao.
--
Nicola


_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: [autotools] gtk-doc.m4 - cross compile support

Nicola Fontana-3
> ...
> sure it is as straightforward as you seem to think.
> ...

It is *not* as stringhtforward.

Ciao.
--
Nicola


_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: [autotools] gtk-doc.m4 - cross compile support

Gtk+ - Documentation mailing list
In reply to this post by Nicola Fontana-3
On Sun, Oct 7, 2018 at 11:04 PM Fontana Nicola <[hidden email]> wrote:

>
> Il giorno dom, 07/10/2018 alle 16.09 +0300, Alon Bar-Lev via gtk-doc-list ha
> scritto:
> > On Sun, Oct 7, 2018 at 3:53 PM John Cupitt via gtk-doc-list
> > <[hidden email]> wrote:
> > > ...
> > > Rather than trying to generate docs in the target, I build my docs in
> > > the host and copy the formatted output over.
> >
> > ...
> > This means that you can run the gtk utilities that are installed on
> > the build part to generate documentation.
> > ...
>
> Hi,
>
> you say that you can/should run gtk-doc on the build side, and I fail to
> understand what makes you think so.
>
> In particular, AFAIK gtkdoc-scangobj must compile and run a program to
> introspect the hierarchy, and I don't see how this can be possible if
> you are on the build side. Maybe you can workaround that, but I'm pretty
> sure it is as straightforward as you seem to think.
>
> I double John's suggestion: build on the host and copy the result.

OK, so no gtk-doc when cross comping, will disable gtk-doc when cross
compiling for packages I maintain in gentoo.

BTW: just a thought, if you compile on demand the scanobj, then you
can use the build CC/LD and it will compile, it can analyze the host
format, just like any toolchain tool.

Thanks!
Alon
_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: [autotools] gtk-doc.m4 - cross compile support

Nicola Fontana-3
Il giorno mer, 10/10/2018 alle 09.20 +0300, Alon Bar-Lev ha scritto:
> ...
> BTW: just a thought, if you compile on demand the scanobj, then you
> can use the build CC/LD and it will compile, it can analyze the host
> format, just like any toolchain tool.

Yes, and you'll also need a launcher (i.e. some kind of virtualization
environment maybe you already have in place) to execute that binary
from the build machine.

I never tried but I think it is feasible because `gtkdoc-scangobj`
seems to have all the options needed: --cc and --ld for
cross-compilation and --run for the launcher.

Ciao.
--
Nicola


_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: [autotools] gtk-doc.m4 - cross compile support

Gtk+ - Documentation mailing list
On Wed, 10 Oct 2018 at 07:39, Fontana Nicola <[hidden email]> wrote:
> Il giorno mer, 10/10/2018 alle 09.20 +0300, Alon Bar-Lev ha scritto:
> > BTW: just a thought, if you compile on demand the scanobj, then you
> > can use the build CC/LD and it will compile, it can analyze the host
> > format, just like any toolchain tool.
>
> Yes, and you'll also need a launcher (i.e. some kind of virtualization
> environment maybe you already have in place) to execute that binary
> from the build machine.

Yes, I've considered that too, but never tried to implement it.

For abstract things like the class hierarchy, you could also do a
separate native build and introspect that, but unfortunately .gir
files are not cross-platform. They include things like struct member
offsets, which really tie them to a specific binary.

John
_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: [autotools] gtk-doc.m4 - cross compile support

Gtk+ - Documentation mailing list
On Wed, Oct 10, 2018 at 10:18 AM <[hidden email]> wrote:

>
> On Wed, 10 Oct 2018 at 07:39, Fontana Nicola <[hidden email]> wrote:
> > Il giorno mer, 10/10/2018 alle 09.20 +0300, Alon Bar-Lev ha scritto:
> > > BTW: just a thought, if you compile on demand the scanobj, then you
> > > can use the build CC/LD and it will compile, it can analyze the host
> > > format, just like any toolchain tool.
> >
> > Yes, and you'll also need a launcher (i.e. some kind of virtualization
> > environment maybe you already have in place) to execute that binary
> > from the build machine.
>
> Yes, I've considered that too, but never tried to implement it.
>
> For abstract things like the class hierarchy, you could also do a
> separate native build and introspect that, but unfortunately .gir
> files are not cross-platform. They include things like struct member
> offsets, which really tie them to a specific binary.
>
> John

I am not expert in this gtk-doc package, so forgive me if I am wrong.
I suggest the following...
Split the tools that are architecture specific to an autoconf
subpackage, by default the gtk-doc will also build the subpackage with
same settings, producing native binaries as done today.
These tools will be cross compile aware, they will run on build and
inspect target formats, just like arm-unknown-linux-gnueabi-objdump
tool on x86_64-pc-linux-gnu, which runs on the build
(x86_64-pc-linux-gnu) but inspect arm-unknown-linux-gnueabi objects,
no need for virtualization.
This can be achieved by including the architecture format from the
SYSROOT while building.
The name of the tool should have prefix of "${HOST}-", the native tool
can have a symlink without the prefix if it is helpful.
The gtk-doc should be target aware, and execute the "${TARGET}-" tool
to inspect objects.

Sequence for example:
cd gtk-doc
./configure
make install

at this point you will have:
/usr/bin/gtk-doc
/usr/libexec/gtk-doc/tool1 -> x864_64-pc-linux-gnut-tool1
/usr/libexec/gtk-doc/x864_64-pc-linux-gnut-tool1

cd gtk-arch-tools
./configure --target=arm-unknown-linux-gnueabi-objdump
make install

Now you will have:
/usr/bin/gtk-doc
/usr/libexec/gtk-doc/tool1 -> x864_64-pc-linux-gnut-tool1
/usr/libexec/gtk-doc/x864_64-pc-linux-gnut-tool1
/usr/libexec/gtk-doc/arm-unknown-linux-gnueabi-objdump-tool1

When invoking gtk-doc add environment variable such as target, when
available it will execute the target- tool, when not it will execute
the tool.

What do you think?
Alon
_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: [autotools] gtk-doc.m4 - cross compile support

Stefan Sauer-4
In reply to this post by Gtk+ - Documentation mailing list
On 10/10/2018 09:18 AM, John Cupitt via gtk-doc-list wrote:

> On Wed, 10 Oct 2018 at 07:39, Fontana Nicola <[hidden email]> wrote:
>> Il giorno mer, 10/10/2018 alle 09.20 +0300, Alon Bar-Lev ha scritto:
>>> BTW: just a thought, if you compile on demand the scanobj, then you
>>> can use the build CC/LD and it will compile, it can analyze the host
>>> format, just like any toolchain tool.
>> Yes, and you'll also need a launcher (i.e. some kind of virtualization
>> environment maybe you already have in place) to execute that binary
>> from the build machine.
> Yes, I've considered that too, but never tried to implement it.
>
> For abstract things like the class hierarchy, you could also do a
> separate native build and introspect that, but unfortunately .gir
> files are not cross-platform. They include things like struct member
> offsets, which really tie them to a specific binary.
gtkdoc does not need the gir files.
So far the approach has been to not cross compile doc builds. I know
that this causes problems if some of the API is conditionally
enabled/disabled from architectures, but this is really not simple to solve.

Stefan

>
> John
> _______________________________________________
> gtk-doc-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-doc-list


_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list