On Wed, 2017-07-12 at 10:23 -0400, Nick Bowler wrote: > Hello, Hey Nick.
> There aren't really any "elegant" solutions. Make handles this kind > of tool quite badly. It is possible to get things to work but it is > always a tradeoff between flexibility of your build system and > simplicity of your rules. I had suspected something along those lines due to the scarcity of documentation that's well defined on this particular class of problem, but feel better knowing my hack might be close to as good as it's going to get for the time being. > If you are happy with this method then it is totally fine. Do make > sure parallel builds work by testing them routinely (both clean and > incrementally) -- I think listing everything in BUILT_SOURCES like > you do probably "resolves" any parallelism problems here, (by > reducing opportunities for parallelism). Tested. It appears to work fine. Everything else will presumably be able to build in parallel, but the flexc++(1) and bisonc++(1) derived targets will have to be in serial. > The Automake manual has section on writing portable make rules for > tools that produce multiple outputs[1], with a discussion of various > approaches and their limitations. I generally prefer approaches > using a dedicated witness file. I took a look at this and I think it's a good idea. But I also think that it may not be worth it if I have to integrate these two tools in only one place in the build environment, as opposed to with multiple parsers in multiple sub projects or some such. > Finally, consider whether you want to distribute the generated parser > sources. That way your users don't need these tools installed just > to build your package. I think that as long as I don't have to actually modify the generated parser sources, I don't have a problem requiring the user to have the two tools installed. Most of the compilation I'll be doing, and most of what remains will probably be on a build server which will automatically pull the required build dependencies (e.g. sbuild debs). Thanks a lot for your help, Nick. -- Kip Warner | Senior Software Engineer OpenPGP signed/encrypted mail preferred http://www.thevertigo.com
signature.asc
Description: This is a digitally signed message part
