[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

My experience with autoconf master

From: Ross Burton
Subject: My experience with autoconf master
Date: Thu, 26 Mar 2020 16:47:53 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0


When I heard that there were plans to release a new autoconf I decided to spend a little time rebuilding OpenEmbedded Core with it. OE is a little special in that apart from a few special cases we autoreconf *everything* that uses autotools.

So far I've built the bulk of oe-core with a snapshot of autoconf from last week with the following failures:

- flex. dnl in AC_CHECK_FUNCS, already fixed in upstream git
- curl. Pointless AC_REQUIRE([AC_RUN_IFELSE]) now causing failure.
- libsdl. Used $CPP without explicit call of AC_PROG_CPP which now is not being called implicitly. - nasm. Failure from AC_CHECK_HEADERS formatting (fix is to add a newline in the middle of ])]). Seems like it could be a regression to me.
- ruby.  Not investigated yet.
- apr. "could not determine the string function for int64_t", not investigated yet.
- apt. The AC_PROG_EGREP thing discussed earlier.
- babeltrace. Something about how bison is being detected: very much bad code in babeltrace not autoconf.
- ghostscript. "cannot find install-sh". Not investigated yet.

We're carrying several patches but some are very specific to us (prefering bash over sh for consistency, or adding new stages to autoreconf) and some most likely need further discussion. I don't see any patches that should be upstreamed as-is, at least.

If anyone wants to see what I'm up to, my branch is at


reply via email to

[Prev in Thread] Current Thread [Next in Thread]