<div dir="ltr">Hi (long time lurker of this mailing list)<div><br></div><div>I like <a href="http://erlang.mk">erlang.mk</a> and I like yaws and tend to use them in various projects (big thank you to the respective contributors of those projects). But when two of your friends do not get along together you tend to worry. In the yaws case it seems like the problem is that it does have a rebar.config and builds fine with rebar, but it does not have its own copy of rebar locally which many packages seem to include these days (or am I right, what is the norm?). So yaws is not built when it is added as a dependency in an <a href="http://erlang.mk">erlang.mk</a> project. </div><div><br></div><div>I have also tried to add yaws as an AUTOPATCH option in <a href="http://erlang.mk">erlang.mk</a> and <a href="http://erlang.mk">erlang.mk</a> tries to create a Makefile from the rebar.config but the resulting build fails with a:</div><div><br></div><div><div>src/yaws.erl:13: can't find include file "yaws_appdeps.hrl"</div><div>src/yaws.erl:221: undefined macro 'YAWS_APPDEPS'</div><div>src/yaws.erl:175: function start_app_deps/0 undefined</div><div>src/yaws.erl:195: function start_app_deps/0 undefined</div><div>make[2]: *** [ebin/portal.app] Error 1</div><div>make[1]: *** [all] Error 2</div></div><div><br></div><div>So I guess the AUTOPATCH option in <a href="http://erlang.mk">erlang.mk</a> does not seem to properly create a working Makefile. </div><div><br></div><div>The way I always resolve this is to either copy in a rebar script into the yaws folder or go through the autoconf procedure, which is the other way of building yaws, but this is of course a manual process that I would like to avoid. The problem is - which one is the odd one here - should a fix be done in <a href="http://erlang.mk">erlang.mk</a> (perhaps in the AUTOPATCH part) or should yaws' build system be fixed? Or should my two friends continue to not get along properly forever and ever? :) </div><div><br></div><div>/Stefan</div><div><br></div></div>