Re: Reltool and code clash

[Jay Nelson-2]

I may have more info on this.  It seems to be a reltool bug. I don't have a simple case, but I discovered the problem using rebar in conjunction with a tsung installation (which doesn't use rebar and instead installs itself into the erlang lib directory).

We customized tsung by adding protobuffs and a new module as dependencies of the .app file. When we use rebar to generate the app (which relies on reltool to do the work), reltool crashes because some dependencies in tsung are in the wrong directory (tsung, rather than in tsung_controller) in the /usr/local/lib/erlang/lib/ directory. Uninstalling tsung allows reltool to generate the app.

To avoid this problem, we instruct reltool to ignore the apps in the erlang directory:

      {app, tsung, [{incl_cond, exclude}]},
      {app, tsung_recorder, [{incl_cond, exclude}]},
      {app, tsung_controller, [{incl_cond, exclude}]}

And the dependency that we created by customizing tsung gets excluded even though it is included explicitly as a separate app:

        {app, my_shared_lib, [{incl_cond, include}]},

There are two issues:

1) tsung is releasing 3 applications and I believe the module dependencies are incomplete or incorrect.
     [Not an erlang issue, the tsung guys need to fix this one]

2) reltool does not handle include + exclude of an app dependency
      [This is the simple case you need to create]

To recreate the problem simply, you need 3 apps (in this case, C is an included application that is just a standalone library of a single module, whereas A and B are executable apps):

  A => relies on C
  B => relies on C

Create a reltool spec that excludes A but includes B. You will find the release area contains C.app but no C.beam files. It doesn't matter which of A or B is excluded as long as the other one is included, you should see the same results. I am not sure, but I don't think it matters if C is listed as an application or as an included_application.

Hope this helps! Feel free to ask more questions. We are working around it by just copying the beams into place as a separate step in the Makefile. Everything else seems to work.

jay
_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs

[Siri Hansen]

Thanks Jay - this is very helpful!

/siri@otp

2011/5/3 Jay Nelson <[hidden email]>

I may have more info on this.  It seems to be a reltool bug. I don't have a simple case, but I discovered the problem using rebar in conjunction with a tsung installation (which doesn't use rebar and instead installs itself into the erlang lib directory).

We customized tsung by adding protobuffs and a new module as dependencies of the .app file. When we use rebar to generate the app (which relies on reltool to do the work), reltool crashes because some dependencies in tsung are in the wrong directory (tsung, rather than in tsung_controller) in the /usr/local/lib/erlang/lib/ directory. Uninstalling tsung allows reltool to generate the app.

To avoid this problem, we instruct reltool to ignore the apps in the erlang directory:

     {app, tsung, [{incl_cond, exclude}]},
     {app, tsung_recorder, [{incl_cond, exclude}]},
     {app, tsung_controller, [{incl_cond, exclude}]}

And the dependency that we created by customizing tsung gets excluded even though it is included explicitly as a separate app:

       {app, my_shared_lib, [{incl_cond, include}]},

There are two issues:

1) tsung is releasing 3 applications and I believe the module dependencies are incomplete or incorrect.
    [Not an erlang issue, the tsung guys need to fix this one]

2) reltool does not handle include + exclude of an app dependency
     [This is the simple case you need to create]

To recreate the problem simply, you need 3 apps (in this case, C is an included application that is just a standalone library of a single module, whereas A and B are executable apps):

 A => relies on C
 B => relies on C

Create a reltool spec that excludes A but includes B. You will find the release area contains C.app but no C.beam files. It doesn't matter which of A or B is excluded as long as the other one is included, you should see the same results. I am not sure, but I don't think it matters if C is listed as an application or as an included_application.

Hope this helps! Feel free to ask more questions. We are working around it by just copying the beams into place as a separate step in the Makefile. Everything else seems to work.

jay
_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs

_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs

[Siri Hansen]

Hi Jay - I'm trying to re-create this, but so far I haven't succeeded. Could you please help me getting on??

What I have so far is:

Application c, which only has one module, c_lib.

Application a, which uses the c_lib.

Application b, which is a copy of application a, only with different names.

And the following reltool config:

 {sys,[{lib_dirs,["/my/lib/dir"]},

       {app,a,[{incl_cond,exclude}]},

       {app,b,[{incl_cond,include}]},

       {app,kernel,[{incl_cond,include}]},

       {app,sasl,[{incl_cond,include}]},

       {app,stdlib,[{incl_cond,include}]}]}.

I have tried with c listed as 'applications' and as 'included_applications' in a.app and b.app. I have also tried without mentioning c in a.app and b.app. In all cases, I get c_lib.beam in the target system.

I have tried with a, b and c all in the same lib dir, and I have tried to move c to a different lib dir - no difference.

Any ideas??

Thanks

/siri

2011/5/3 Jay Nelson <[hidden email]>

I may have more info on this.  It seems to be a reltool bug. I don't have a simple case, but I discovered the problem using rebar in conjunction with a tsung installation (which doesn't use rebar and instead installs itself into the erlang lib directory).

We customized tsung by adding protobuffs and a new module as dependencies of the .app file. When we use rebar to generate the app (which relies on reltool to do the work), reltool crashes because some dependencies in tsung are in the wrong directory (tsung, rather than in tsung_controller) in the /usr/local/lib/erlang/lib/ directory. Uninstalling tsung allows reltool to generate the app.

To avoid this problem, we instruct reltool to ignore the apps in the erlang directory:

     {app, tsung, [{incl_cond, exclude}]},
     {app, tsung_recorder, [{incl_cond, exclude}]},
     {app, tsung_controller, [{incl_cond, exclude}]}

And the dependency that we created by customizing tsung gets excluded even though it is included explicitly as a separate app:

       {app, my_shared_lib, [{incl_cond, include}]},

There are two issues:

1) tsung is releasing 3 applications and I believe the module dependencies are incomplete or incorrect.
    [Not an erlang issue, the tsung guys need to fix this one]

2) reltool does not handle include + exclude of an app dependency
     [This is the simple case you need to create]

To recreate the problem simply, you need 3 apps (in this case, C is an included application that is just a standalone library of a single module, whereas A and B are executable apps):

 A => relies on C
 B => relies on C

Create a reltool spec that excludes A but includes B. You will find the release area contains C.app but no C.beam files. It doesn't matter which of A or B is excluded as long as the other one is included, you should see the same results. I am not sure, but I don't think it matters if C is listed as an application or as an included_application.

Hope this helps! Feel free to ask more questions. We are working around it by just copying the beams into place as a separate step in the Makefile. Everything else seems to work.

jay
_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs

_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs

[Siri Hansen]

I did finally manage to re-create the problem as described in the original post - i.e. if the same module is included in two different applications, one included and one excluded - then, depending on the order of processing, the beam file might be completely excluded from the release area.

A solution will be included in R14B03. It allows duplicated module names, as long as the configuration clearly states only one actual inclusion. Warnings and errors are emitted.

Regards

/siri

_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs