expand_dependencies -- subtle bug. #2

steakknife opened this Issue Aug 19, 2012 · 2 comments

1 participant


Use-case: Building rabbitmq-erlang-client.


  • rabbitmq-erlang-client -> rabbitmq-server -> rabbitmq-codegen
  • rabbitmq-erlang-client -> rabbitmq-codegen

Issue: rabbitmq-codegen and rabbitmq-server must be present before invoking rabbitmq-erlang-client's make.


{url, "http://hg.rabbitmq.com/rabbitmq-codegen/archive/tip.tar.gz"}.
{prebuild_command, "mkdir -p ebin"}.


{url, "http://hg.rabbitmq.com/rabbitmq-server/archive/tip.tar.gz"}.
{prebuild_command, "ln -sf ~/.sutro/lib/rabbitmq-codegen ../rabbitmq-codegen"}.
{deps, ['rabbitmq-codegen']}.


{prebuild_command, "ln -sf ~/.sutro/lib/rabbitmq-server ../rabbitmq-server"}.
{deps, ['rabbitmq-codegen', 'rabbitmq-server']}.

Also, the example emongo -> etap shows the same behavior.


expand_dependencies is correct ( lists:reverse(digraph_utils:topsort(G))). There might be missing add_edge's or an implicit lexicographical sort/conversion/match occurring elsewhere (e.g., caller).


Found it. digraph_utils:topsort assumes {SomeString, Props} the lowest compared vertex is the root vertex. The DAG is not necessarily arborescence (sutro install foo bar baz = 3 roots), so arborescence_root won't help.

Solution: Decorate the tuple with a monotonically increasing ordinal before the node name, i.e., {N, SomeString, Props}, as the modules are examined. This implies something similar to 0, 1, 2 for sutro install foo bar baz respectively; and 3, ... , N-1 for subsequent dependencies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment