[erlang-questions] ct_cover broken when using packages

[Andreas Stenius]

Hi Tim,

Thanks for the tip of using import in this case, for some reason I hadn't 
thought of it..

Best regards,
Andreas

----- Original Message ----- 
From: "Tim Watson" <watson.timothy@REDACTED>
To: "Andreas Stenius" <andreas.stenius@REDACTED>
Cc: <erlang-questions@REDACTED>
Sent: Tuesday, December 16, 2008 2:33 PM
Subject: Re: [erlang-questions] ct_cover broken when using packages


> Hi Andreas,
>
> 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
> the like:
>
> -module(a.module.with.a.long.package.name).
> %% 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 <andreas.stenius@REDACTED> wrote:
>> Hi,
>>
>> 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
>> way..
>>
>> 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" <watson.timothy@REDACTED>
>> To: <erlang-questions@REDACTED>
>> 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
>>> erlang-questions@REDACTED
>>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>>
>