Please correct me if I'm way off base with that example. The stubs
Patrick proposed in the other thread might help address the issue,
however it can also mean adding code which exists only to satisfy the
build requirement, churns as the real code changes, and may need to be
removed later on anyway.
Right, but it means that there's less of a risk of API changes across the tree (that happen all the time) throwing bring-up projects off-track.
I mean, these stubs don't have to _do_ anything useful, they merely have to present themselves as just good enough to the build system to put all source code through the grinder^Wcompiler.
I'd expect all developers to have _some_ kind of board set up for their SoC because otherwise how do they test the SoC code in the first place? (I assume it is tested, at least to some degree)
Maybe it's good enough to push these early, potentially anonymized plus some signifier that they're stubs? Not sure if that's practical in all existing workflows, but I'll leave that to a separate thread.
I suppose we could look into having jenkins throw out a warning if a source file (*.c or *.h) wasn't touched during the build. That might be a good exercise in any case to see what the situation looks like right now.
Regards,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado