> Hmm, this is unfortunate since there is no common way to > specify the header path directly. > > I am not sure how much effort we should invent > to support non-GNU implementation > since we already rely on various GNU tools. > > If we decide to support byacc, > we must carry the restriction > that bans GNU-extension. I just realized that I accidentally only responded to Masahiro with my previous email from a few days ago so I'll just quote it here: "I feel like changing 10 lines to support a different yacc implementation that supports most of the GNU-specific features here isn't the same thing as banning all GNU extensions, and in regards to the file prefix, the method in my patch creates the same file names as the bison-specific one for the 3 cases it is used for, and the flags used for it are POSIX yacc compatible. In my opinion increasing compatibility shouldn't have to be all or nothing, and it makes sense to make changes that increase compatibility without outright banning GNU extensions entirely." Aside from that, patch to dtc has just been applied, so pulling the latest upstream changes as well as the v2 of this patch should be what would be needed to support byacc.
