Re: Testing GLib cross compilation

[Owen Taylor <otaylor redhat com>]

Tor Lillqvist <tml iki fi> writes:

> Owen Taylor writes:
>  > Probably the build/ directory needs some help for cross-compilation;
>  > probably simply adding:
>  > 
>  >  AC_CHECK_TOOL(WINRES, winres)
>  > 
>  > to configure.in, and then using $(WINRES) instead of winres
>  > in the Makefile.am.
> 
> (It's windres, not winres)
> 
> Actually, as windres is used to compile the resource file which only
> contains version (and copyright) information, the resources could
> without harm be left out from the DLLs completely when building "just
> for yourself". I would say they are meaningful only when building for
> public distribution, so that end-users can check from
> Properties:Version what version (and "build number") a DLL actually
> is.
> 
> It would probably be easiest to check for windres in configure.in, and
> if not found, don't define G_LIB_WIN32_RESOURCE at all, and/or bypass
> related rules with an automake conditional.

As far as I know (and that's not very far) windres will always 
be present on a build chain targeting mingw32; it's just that
on a cross build chain, it gets a prefixed name, like the rest 
of the tools.

So, there doesn't seem to be any real need to make it optional; it
just takes a bit of standard autoconfigury to find the right name.

> And, there is ample room for improvements and redesign in the whole
> admittedly very hackish and crappy setup with the compile-resource and
> lt-compile-resource scripts, including the mess with different
> versions of libtool using either small script snippets or copies of
> the .o files as .lo files... Note the comment in compile-resource:
> 
> # This is just my (tml iki fi) idea, if somebody comes up with a
> # better way to generate version number resources, don't hesitate to
> # suggest.

For lt-compile-resource, the right direction seems to definitely be to
get resource support into libtool; might take a little while, but once
it was in, you could reduce the complexity a bunch.

For the build number stuff -- well, my idea would be that it seems a
bit too automagical to be part of the distribution; my suggestion
would be to add simply --with-build-number configure option, then
maybe you could keep a shell script that automatically kept track of
build numbers and ran configure appropriately.

The current stuff isn't awful, but I can't imagine it ever being part
of a clean solution that we could get upstream into libtool.

Regards,
                                        Owen