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-de...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
