Hey,
On 04/24/2017 10:00 AM, smlng wrote:
>>> It might be that this is equivalent to what we now call "features". ;)
>>
>> A good idea, we could introduce just introduce more features and wire
>> the features_required checks to be available from the command line.
>> `make buildtest TAGS=kinetis`
>
Hi Joakim, Kaspar, and all,
> Am 24.04.2017 um 09:52 schrieb Joakim Nohlgård :
>
>> That way we could use our buildtests like:
>>
>>$ make buildtest TAGS=msp430
>>
>> or even
>>
>>$ make buildtest TAGEXPR="cortex-m0 and nucleo"
>>
>> It might be that this is equivalent to what we now c
On Mon, Apr 24, 2017 at 9:27 AM, Kaspar Schleiser wrote:
> Hey Joakim,
>
> On 04/21/2017 06:46 PM, Joakim Nohlgård wrote:
>> I would like to change this split to create groups of boards which are
>> likely to fail together to be in the same group. For example, the Nucleo
>> boards could be in one
Hey Joakim,
On 04/21/2017 06:46 PM, Joakim Nohlgård wrote:
> I would like to change this split to create groups of boards which are
> likely to fail together to be in the same group. For example, the Nucleo
> boards could be in one or more groups cortexm_nucleo, the SAM boards,
> nrf, and kinetis
Dear Joakim,
and all,
I think with Murdock 2 the MCU build groups are getting obsolete anyway (right
Kaspar?). In Murdock 2 every (sub) tasks/jobs is very small, i.e., single app
for distinct boards - but hence lots of them.
Though, there is no need to reorganise the existing groups right away
Dear developers,
The build test MCU groups were added as a measure to split the compile test
during CI runs into several smaller runs and to easier get an overview of
what is failing. The initial groups were based on what architectures were
supported in the code base, but when the Cortex-M groups b
