include_lib not found

[hachreak]

Hi, I'm using all the plugins to works on a project that implement a REST API with webmachine.

In my resource I have:

-include_lib("webmachine/include/webmachine.hrl").

But vim say me that can't find include lib "webmachine/include/webmachine.hrl". Can someone help me? I have not an precise idea how I can fix this problem.

Thanks a lot!

[hcs42]

Hi,

Which tool do you use to build your project? vim-erlang-compiler currently supports rebar (version 2), and it also has some rudimentary support for Makefiles.

Where is "webmachine/include/webmachine.hrl" located wrt your source files? I.e. how does the directory structure of your project look like?

[hachreak]

I'm using rebar3. this is my rebar.config:

{erl_opts, [debug_info]}.
{deps, [
  {webmachine, {git, "git://github.com/basho/webmachine", {branch, master}}},
  {oauth2, {git, "git://github.com/kivra/oauth2", {branch, master}}},
  {jsx, {git, "https://github.com/talentdeficit/jsx.git", {branch, master}}},
  {oauth2_mongopool,
   {git, "https://github.com/hachreak/oauth2_mongopool.git", {branch, master}}}
]}.

The structure of my project:

_build
priv
README.md
rebar.config
rebar.lock
src
start.sh
utils

if you need any other information, please tell me! :)

[hcs42]

Thanks, it seems that rebar3 stores the dependencies in the _build/<profile>/lib directory.

Could you try my rebar3 branch? I added the _build/<profile>/lib/*/ebin directories to the Erlang path, which makes the compiler find the hrl.

[fishcakez]

I don't think that's the right fix for rebar3. We should only use one profile. I would suggest using the test profile when in test/ and default otherwise. It might be we would want a configuration for rebar3 to set the profile to use. But that could wait until someone wants it.

After the holiday season I will see about writing a rebar3 provider for this because it's unlikely we will handle everything correctly without using rebar3.

[fishcakez]

Well unless you want to or dont want that apporach @hcs42. I am only suggesting it as I might be more familiar with rebar3.

[hcs42]

We should only use one profile. I would suggest using the test profile when in test/ and default otherwise.

I don't know much about profiles, but this sounds sensible. Do most people use the "default" and "test" profiles?

After the holiday season I will see about writing a rebar3 provider for this because it's unlikely we will handle everything correctly without using rebar3.

If providers are the proper way to do it, I'm open to that.

[fishcakez]

Those profiles are the defaults. So rebar3 compile will build with the default profile when no profile is set. Rebar3 ct or eunit will use the test profile auotmatically which also compile all files in test/.

I think using rebar3 provider is the way to go because we probably don't want to reimplement profile merging and other things. It shouldn't be too slow.

On 19 December 2015 at 17:23, Csaba Hoch notifications@github.com wrote:

We should only use one profile. I would suggest using the test profile when in test/ and default otherwise.

I don't know much about profiles, but this sounds sensible. Do most people use the "default" and "test" profiles?

After the holiday season I will see about writing a rebar3 provider for this because it's unlikely we will handle everything correctly without using rebar3.

If providers are the proper way to do it, I'm open to that.

— Reply to this email directly or view it on GitHub https://github.com/vim-erlang/vim-erlang-compiler/issues/17#issuecomment-166005522 .

[fishcakez]

As an aside, when multiple profiles are used they combine to _build/profile1+profile2/ not use both build directories.

On 19 December 2015 at 17:56, James Fish james@fishcakez.com wrote:

Those profiles are the defaults. So rebar3 compile will build with the default profile when no profile is set. Rebar3 ct or eunit will use the test profile auotmatically which also compile all files in test/.

I think using rebar3 provider is the way to go because we probably don't want to reimplement profile merging and other things. It shouldn't be too slow.

On 19 December 2015 at 17:23, Csaba Hoch notifications@github.com wrote:

We should only use one profile. I would suggest using the test profile when in test/ and default otherwise.

I don't know much about profiles, but this sounds sensible. Do most people use the "default" and "test" profiles?

After the holiday season I will see about writing a rebar3 provider for this because it's unlikely we will handle everything correctly without using rebar3.

If providers are the proper way to do it, I'm open to that.

— Reply to this email directly or view it on GitHub https://github.com/vim-erlang/vim-erlang-compiler/issues/17#issuecomment-166005522 .

[hachreak]

@hcs42 @fishcakez what about use the command rebar3 path?

[fishcakez]

I didn't know about rebar3 path but that looks perfect here!

On 21 March 2016 at 10:27, Leonardo Rossi notifications@github.com wrote:

@hcs42 https://github.com/hcs42 @fishcakez https://github.com/fishcakez what about use the command rebar3 path https://github.com/erlang/rebar3#features?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/vim-erlang/vim-erlang-compiler/issues/17#issuecomment-199215578

[hcs42]

@hachreak Do you feel like modifying my rebar3 commit to use rebar3 path?

[melekes]

Looks like rebar3 is going to be a standard de facto. Looking forward to seeing support for it

[hachreak]

Yep :) , in the Erlang Factory SF 2016 10 days ago they announced the adoption... XD And here you can see the confirm of that.