How to support WAF cross-answers (cross compile) cleanly in ebuilds

[Zentaro Kavanagh]

Samba and it's sub packages (talloc, tevent, tdb, ldb) I think are the only packages in Chrome OS that use WAF for the build system. Right now we don't support ARM for these packages. I've got some changes that work, but they aren't ideal. I'm looking for feedback on the right way to do this and ideally in a way that we can cleanly push back to gentoo.

For cross compilation WAF doesn't support just overriding an environment variable like autoconf does. It needs to be passed an answers file to configure, eg "--cross-compile --cross-answers=<path to answer file>" which we've previously done when building for NaCl and Android.

Here is what I've done that works (but is not the right solution).

1. Put the file arm_answers in <package root>/files
2. In src_prepare() do use arm && cp "${FILESDIR}/arm_answers" "${S}" (NOTE: it copies because configure reads and then writes back to the file)
3. In src_configure() do something similar to this. use arm && myconfargs+=( --cross-compile --cross-answers=arm_answers )

Some of the problems with this.

1. The check for cross compilation should be more robust. ie target is arm and host is not.
2. Instead of putting the answers file in each package, for CrOS it probably could be only once in a common location for the platform. Where would be the best place to put that?
3. Itshould be general and less arm specific.
4. As is, especially if changed due to (2) probably is too specific to push upstream to gentoo.

So firstly is it worth trying to get a change that we can push upstream or is this out of scope for gentoo and we should just move all the packages to chromiumos-overlay and customize for CrOS.

Would a solution more like this be suitable?

• In the ebuild check an environment variable for a path/filename for the cross answers. If it is set and not empty then copy that file to the source tree and point the configure options to it.
• In this case the ebuild can remain platform agnostic and let the builder/environment be responsible for setting it appropriately.
• Put a <platform>_cross_answers file in a common location in chromeos tree for each platform.
• Use the chromeos/config/env to appropriately set this environment variable during the Chrome OS build.

Is there a better solution?

[Mike Frysinger]

do you have an example of the required answers file ?  chances are pretty good that trying to hardcode things "for arm" won't even work.

i feel like last time i came across waf i just gave up because of its bootstrapping nonsense and their insistence on writing yet-another-build-system because "they can do it better" while simultaneously screwing up everything that was working for years (like cross-compiling).

-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Zentaro Kavanagh]

This is the answers file I'm using. It's a shame to have to hard code these configure options, though we can also have different answers per board if for some reason these are not consistent among the ARM devices we have. The config.log also includes detail about what each of these is actually trying to compile and execute.

Checking uname sysname type: "Linux"

Checking uname machine type: "arm"

Checking uname release type: "Linux"

Checking uname version type: "Linux"

Checking simple C program: OK

Checking for large file support without additional flags: OK

Checking for HAVE_SECURE_MKSTEMP: OK

rpath library support: OK

-Wl,--version-script support: OK

Checking for working strptime: OK

Checking for C99 vsnprintf: OK

Checking for HAVE_SHARED_MMAP: OK

Checking for HAVE_MREMAP: OK

Checking getconf LFS_CFLAGS: FAIL

Checking correct behavior of strtoll: OK

Checking for HAVE_INCOHERENT_MMAP: FAIL

Checking for HAVE_IFACE_GETIFADDRS: FAIL

Checking for HAVE_IFACE_IFCONF: FAIL

Checking for HAVE_IFACE_IFREQ: FAIL

Checking value of NSIG: "65"

Checking value of _NSIG: "65"

Checking value of SIGRTMAX: "64"

Checking value of SIGRTMIN: "35"

Checking errno of iconv for illegal multibyte sequence: FAIL

Checking for kernel change notify support: OK

Checking for Linux kernel oplocks: OK

Checking for kernel share modes: OK

Checking whether POSIX capabilities are available: OK

Checking if can we convert from CP850 to UCS-2LE: OK

Checking if can we convert from UTF-8 to UCS-2LE: OK

vfs_fileid checking for statfs() and struct statfs.f_fsid: OK

Checking whether we can use Linux thread-specific credentials with 32-bit system calls: OK

Checking whether fcntl locking is available: OK

Checking whether fcntl lock supports open file description locks: OK

Checking for the maximum value of the 'time_t' type: OK

Checking whether the realpath function allows a NULL argument: OK

Checking for ftruncate extend: OK

getcwd takes a NULL argument: OK

Checking whether the WRFILE -keytab is supported: OK

[Mike Frysinger]

yeah, many of those are not tied to "is this an arm build", and annoyingly, the majority of those can easily be checked by compile and link tests (which is what configure used to do).  making people generate these files by hand is dumb and is just begging for people to copy & paste some random file off an internet forum until the build passes.  the samba guys really screwed up here, but i guess they don't care about the subset of users that need to cross-compile anymore.

there is no clean solution for distros either.  for CrOS, we might just have to hack it in and save that single file for our needs and assume that the toolchain/C library/runtime are fairly static.

-mike