[debhelper-devel] Bug#794396: Bug#794396: CMake cross compilation support

Niels Thykier niels at thykier.net
Mon Aug 10 07:21:24 UTC 2015


On 2015-08-03 07:14, Helmut Grohne wrote:
> On Sun, Aug 02, 2015 at 05:27:39PM +0200, Helmut Grohne wrote:
>> So I worked from this patch and tried to implement the same approach
>> into debhelper itself. The result is the other attached patch. Like the
>> autoconf.pm counterpart, it is only active when the build architecture
>> and the host architecture differ, so I do note expect any regressions
>> for native compilation. Yet, cross compilation never worked with CMake,
>> so I think it is safe to change the behaviour of the build system.
> 
> Guillem Jover spotted my use of an undefined architecture variable.
> Updating the patch.
> 
> Helmut
> 
> 
> 
> _______________________________________________
> debhelper-devel mailing list
> debhelper-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debhelper-devel
> 

Hi,

Thanks for looking into this.

I have not yet looked at this in fully.  However, I think it would be
prudent to use a lookup-table rather than the if-elsif-elsif-waterfall:

> +		if (dpkg_architecture_value("DEB_HOST_ARCH_OS") eq "linux") {
> +			push @flags, "-DCMAKE_SYSTEM_NAME=Linux";
> +		} elsif (dpkg_architecture_value("DEB_HOST_ARCH_OS") eq "freebsd") {
> +			push @flags, "-DCMAKE_SYSTEM_NAME=FreeBSD";
> +		} elsif (dpkg_architecture_value("DEB_HOST_ARCH_OS") eq "hurd") {
> +			push @flags, "-DCMAKE_SYSTEM_NAME=GNU";
> +		}

Also, should we fail when we do not know the value for
CMAKE_SYSTEM_NAME?  It would probably make it easier to spot missing
support for new architectures.

Thanks,
~Niels




More information about the debhelper-devel mailing list