This is trying to address what I think is the actual problem underlying #515. While I didn’t test this with a package, I did test that with an RIP build “mesa_7i65.comp” can be copied out of the tree and built with halcompile --compile. buildbot shows green for kernel-mode RTAI builds, and I tested locally with uspace builds on debian stretch.
评论 (7)
#2 – jepler 于 2018-10-26
I’ve added a test for whether include "..." will find a header file that is “next to” the comp file. For me it passes, which still makes me unsure just what is intended to be solved in #515. Perhaps adding a test to #515 similar to 326efa3f8cf46c03f6c938e7d75c592064d7018b would help us understand.
#3 – jepler 于 2018-10-27
@SebKuzminsky do you want this for 2.7?
#4 – SebKuzminsky 于 2018-10-30
Yes, please merge this to 2.7. Thanks!
#5 – jepler 于 2018-10-30
OK, assuming nothing goes wrong, I will close this PR and open a fresh one targeting 2.7 branch instead. Please feel free to ping me if no action by Saturday.
#6 – jepler 于 2018-10-30
It does go slightly wonky, because it looks like hm2_pktuart isn’t in 2.7. So some part of this PR will survive to be rebased against master after the 2.7 version is merged (and merged up)
#7 – jepler 于 2018-11-04
@SebKuzminsky I’m going to merge the “public API” bits to master given the actual incompatibility between 2.7 and master (see #522’s buildbot build failures) and we can decide if there any part of this that does make sense to cherry pick back to 2.7 at a later time.
#1 – andypugh 于 2018-10-26
I don’t think that this actually addresses the issue in 515, I am afraid I might have confused the issue by bringing up a corner-case of halcompile.
However, this does seem like a valuable improvement to the ease of use of mesa serial protocols, and so I stongly support its adoption.
But I think we might need #515 too…