Problem including files from different projects

[Duncan McGreggor]

I've got a project (ledis) which I've set to depend on another project (lfeunit). In order to set up the unit tests in ledis, I need to include some files from lfeunit.

It seems that due to the simple handling of the current directory and the assumptions around relative paths, this isn't possible.

My hope is that I'm just thinking about this wrong, and haven't tried the right way :-) A comment in the source code makes me thing that this hope is ill-founded ;-)

I've provided mode detail in this ticket to myself:
  https://github.com/oubiwann/lfeunit/issues/10

What's the best way to solve this?

Thanks!

d

[dun...@cogitat.io]

Given that all my Erlang time is spent in LFE and that I'm mostly Erlang-syntax-illiterate, do take this with a grain of salt ;-)

But it seems that the following:

lib_file_name(Lpath) ->
    [Lname|Rest] = filename:split(Lpath),
    case code:lib_dir(list_to_atom(Lname)) of
    Ldir when is_list(Ldir) ->
         {ok,filename:join([Ldir|Rest])};
    {error,E} -> {error,E}
    end.

Could be updated to check for another case, something along the lines of:

    case code:lib_dir(list_to_atom(Lname), include) of
        ...

Given that "include" is a standard name for .hrl, inlcudable .lfe files, etc. This would mean that by simply setting the ERL_LIBS env var, we could have projects including files from other projects...

What do you think?

d

[Robert Virding]

That would break with how include_lib in vanilla erlang works, which I don't want to do. :-)

I think the real problem is that currently include and include-lib have no concept of a include path and only look relative to current directory for include and in the library Erlang dirs for include-lib. Though include-lib does know about ERL_LIBS.

A better solution would be introduce the concept of an include path. In conjunction with this whether to keep include/include-lib as macros or make them top-level forms which are interpreted at the same time as macros. Whcih is really almost the same.

I will think some more about this.

Robert

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Duncan McGreggor]

On Tue, May 21, 2013 at 2:36 PM, Robert Virding <rvir...@gmail.com> wrote:

That would break with how include_lib in vanilla erlang works, which I don't want to do. :-)

Hehe. Yeah, I'm with you on that :-)

 

I think the real problem is that currently include and include-lib have no concept of a include path and only look relative to current directory for include and in the library Erlang dirs for include-lib. Though include-lib does know about ERL_LIBS.

A better solution would be introduce the concept of an include path. In conjunction with this whether to keep include/include-lib as macros or make them top-level forms which are interpreted at the same time as macros. Whcih is really almost the same.

Oh, nice. I like this idea :-)

 

I will think some more about this.

Fantastic! As usual, I look forward to hearing your thoughts... and using your code!

d