I agree that that is a compatibility break, but that change was made at
the same time as a host of other backwards-incompatible changes
(0.8.0-b2). I think this particular problem is a bit more complicated,
so strap yourself in for some mind-numbing post-mortem analysis.
The root of this issue is that the arduino repository.yml file
incorrectly pointed to the develop branch rather than an appropriate tag
on the master branch. Under these conditions, everything worked for a
while, because the arduino bsp's pkg.yml file on the develop branch does
specify the correct package type ("bsp"). Eventually, a change was made
to the arduino develop branch which was incompatible with the core
master branch [*], which is not surprising. This incompatible change
exposed the bug in the arduino repository.yml file. As a consequence,
the arduino repository.yml file was modified to point to the master
branch. The mistake here was in assuming the repository.yml change
would be sufficient for fixing the arduino build issues.
In my opinion, temporarily removing the package type restrictions is not
the right thing to do here. We would need to re-release newt for that
fix to have any effect. Instead, I believe we should create a new tag
on the arduino repo with the pkg.yml fix. I can make this change and
ensure arduino apps build properly. However, I don't have an arduino
with me, so I can't actually test image upload or debug.
Chris
[*] - C files were including HAL header files that only existed in the
develop branch of the core repo.
On Sat, Apr 02, 2016 at 12:13:45PM -0700, Sterling Hughes wrote:
> Hey,
>
> Try:
>
> $ newt target show
> targets/arduino_boot
> app=@apache-mynewt-core/apps/boot
> bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
> build_profile=optimized
> features=arduino_zero_pro
> targets/my_blinky_sim
> app=apps/blinky
> bsp=@apache-mynewt-core/hw/bsp/native
> build_profile=debug
> $ newt build arduino_boot
> Error: bsp package (hw/bsp/arduino_zero) is not of type bsp; type is: lib
> $
>
> I understand that we introduced package types into the new release.
> What I'm not sure of is why we've broken compatibility here?
>
> Yes, we're beta, and compatibility breaks are allowed, but:
>
> A- We should call them out on dev@ _PRIOR_ to breaking compatibility, so
> things like the docs can be changed.
>
> B- In this case, was a compatibility break really necessary? Couldn't
> we have just accepted the package type if it was lib-- at least for a
> couple of releases?
>
> Sterling
