On 5/19/20 3:11 AM, Christophe Lyon wrote:
> IIRC, that's what ABE does too.
Abe lets you specify a branch of all tools to build, including DejaGnu.
I do this a few different ways. If the DejaGnu branch is upstream, then
just tell ABE to use that. If the branch isn't upstream, you can do what
Christophe suggested. When debugging, I often just cd to a build
directory and run "make check". In ABE world, cd to
builds/${build}/${host}/${tool}.
>> It seems to have disappeared from the Linaro wiki... is it currently
>> posted anywhere?
> ABE is still there:
> https://git.linaro.org/toolchain/abe.git/
You can also try my fork, which has a few minor changes on versions,
and uses upstream URLs for the sources instead of Linaro's. And PI support.
https://gitlab.com/rsavoye/abe.
> I'll let Rob/Ben comment on what is "sufficient" testing, I believe
> GDB is the most challenging.
GDB is where we have the most timing problems, because it's using
expect to send commands and parse the result. The CPU load on the build
machine can also effect this. For the patches currently in the queue, I
plan to test with git and the currently released GCC 9.3.0, native and
one cross test. The cross test will use my PI B3+, and QEMU, although
for you QEMU should be sufficient. I've got most of this built now, had
a few issues getting ADA to build. (which I'd never done before, had to
install GNAT)
A good release adds more variations. The toolchain has many pieces
that all have to work together. Because toolchain developers depend on
accurate test results, I usually add more cross targets (armv7a, armv8,
risc-v, mips, powerpc), and use what's current on CentOS (GCC 8.3.1),
Ubuntu/Debian (GCC 9.3.0), the soon to be next release (GCC 10.x). Also
by default we usually test just C and C++, but for a release also need
to run the testsuites for go, Java, Fortran, and now Ada.
- rob -
---
https://www.senecass.com
