[erlang-questions] ct_cover broken when using packages
Tue Dec 16 14:33:42 CET 2008
Yeah the package system implementation isn't ideal - not even make:all
will work unless you write (or generate) an Emakefile which specifies
each of the source directories explicitly. You shouldn't have to do
this sort of thing, it should "just work" imho.
We do use packages, because our applications are packaged (and
released) both as discrete Erlang/OTP releases and as components
(depending on the needs of the target environment in question), so we
would end up with names like
'bss_billing_dispatch_control_routing_server' which is something I'm
just not willing to type! :)
The work around is to include an import for 'ets' in your modules,
which if you're averse to including in the production code (although
it doesn't really matter in reality), can be stripped out using cpp or
%% some *real* imports/directives/etc
-import(ets). %% hack to keep cover happy
This works, but I'd like to see it fixed nonetheless.
On 16/12/2008, Andreas Stenius <> wrote:
> I've run into similar problems when using packages, when including for
> instance the eunit.hrl file, which has defines that will run into the same
> problem of referring to global packages without the needed leading dot.
> In my opinion, the package system is broken, in that code is dependent on
> the package layout for accessing the global scope, so I dropped it. Doesn't
> look like the Erlang/OTP distro uses the package functionality at all any
> But I'd rather like seeing this issue addressed and fixed, since now all my
> modules resides in only one dir, and with quite extensive names, which
> should rather be a path..
> Sorry, no help here, just want to add my view to let out that we're more
> with similiar issues.
> Best regards,
> Andreas Stenius
> ----- Original Message -----
> From: "Tim Watson" <>
> To: <>
> Sent: Tuesday, December 16, 2008 1:16 AM
> Subject: Re: [erlang-questions] ct_cover broken when using packages
>> Hi all,
>> I've noticed that the cover tool seems to break when using packages.
>> It appears that the cover tool inserts executable code into your
>> functions such as this:
>> myfunction() ->
>> %% do something
>> ets:<some_function>, %% inserted by cover
>> %% etc
>> This would be fine except that in a module module 1 contained within a
>> package package1, the atom ets is resolved to 'package1.module1.ets'
>> which doesn't exist (hopefully!). The correct behaviour would be to
>> insert '.ets' or to dynamically add an "-import(ets)." to the module
>> so that 'ets' resolves to '.ets' instead.
>> Has anyone else come across this? Is there a planned fix?
>> Many thanks,
>> Tim Watson
>> erlang-questions mailing list
More information about the erlang-questions