default include directory of app didn't work

[raincoldl]

BACK_GROUND:
the rebar3 version is the lastest version.
when compile start, copy the file for each app to __build/xxx directory, when in unix enviroment, each directory will get 2 of them.
eg: __build/default/lib/<application_name>/include/include, it willl not happen in win32 enviroment.

BUG:
i download the source code from here and check the code, when compile, in file rebar_prv_compile.erl,
funtion copy_app_dirs/3 copy the directory from app_dir to out_dir, andthen jump to the mod rebar_file_utils, i print the source and
dest, and i found that the cmd in unix is like this => cp -Rp /mnt/hgfs/project/game/aa/apps/aa/include /mnt/hgfs/project/game/aa/_build/default/lib/aa/include, it will cp the directory /mnt/hgfs/project/game/aa/apps/aa/include to
/mnt/hgfs/project/game/aa/_build/default/lib/aa/include, which make the directory become /mnt/hgfs/project/game/aa/_build/default/lib/aa/include/include, there's two of include directory, which make compile process can
not find my *.hrl files and compile error occured.

FIX_SUGGESTION:
maybe the cp function can check if thereis directory, the cmd change to cp -Rp DirA* DirB or somthing else ???

[ferd]

I cannot replicate this in general. Is this on a shared filesystem in a virtual machine? Those things end up often having bugs that exist nowhere else. Can you also specify which rebar3 versions you are using and responding to the standard template questions? They are there for a reason, they're usually helpful to help troubleshoot issues.

[raincoldl]

Environment

Rebar3 report
version 3.19.0
generated at 2022-07-13T01:33:39+00:00

Operating System: x86_64-pc-linux-gnu
ERTS: Erlang/OTP 24 [erts-12.1] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1]
Root Directory: /home/lmqaq/kerl/24.1
Library directory: /home/lmqaq/kerl/24.1/lib

Source code structure

NOTE: in a shared filesystem in a virtual machine

aa
├── apps
│   └── aa
│   ├── include
│   │   └── hehe.hrl
│   ├── priv
│   ├── rebar.config
│   ├── rebar.lock
│   └── src
│   ├── aa_app.erl
│   ├── aa.app.src
│   └── aa_sup.erl
├── _build
│   └── default
│   └── lib
│   └── aa
│   ├── ebin
│   ├── include
│   │   └── include
│   │   └── hehe.hrl
│   ├── priv
│   │   └── priv
│   └── src
│   └── src
│   ├── aa_app.erl
│   ├── aa.app.src
│   └── aa_sup.erl
├── config
│   ├── sys.config
│   └── vm.args
├── LICENSE
├── README.md
├── rebar.config
└── rebar.lock

Current behaviour

lmqaq@ubuntu:/mnt/hgfs/project/game/aa$ rebar3 compile
===> Expanded command sequence to be run: [app_discovery,install_deps,lock,compile]
===> Running provider: app_discovery
===> Found top-level apps: [aa]
using config: [{src_dirs,["src"]},{lib_dirs,["apps/","lib/","."]}]
===> Running provider: install_deps
===> Verifying dependencies...
===> Running provider: lock
===> Running provider: compile
===> Compile (apps)
===> Running hooks for compile with configuration:
===> {pre_hooks, []}.
===> Compile (project_apps)
===> Running hooks for compile in app aa (/mnt/hgfs/project/game/aa/apps/aa) with configuration:
===> {pre_hooks, []}.
===> Running hooks for erlc_compile in app aa (/mnt/hgfs/project/game/aa/apps/aa) with configuration:
===> {pre_hooks, []}.
===> Analyzing applications...
===> Compiling aa
===> compile options: {erl_opts, [debug_info]}.
===> files to analyze ["/mnt/hgfs/project/game/aa/apps/aa/src/aa_sup.erl",
"/mnt/hgfs/project/game/aa/apps/aa/src/aa_app.erl"]
===> Compiling apps/aa/src/aa_sup.erl failed
apps/aa/src/aa_sup.erl:10:10: can't find include file "hehe.hrl"

Expected behaviour

compile with no error.

Other thing

I try it on my home directory and it works well too.

[raincoldl]

I cannot replicate this in general. Is this on a shared filesystem in a virtual machine? Those things end up often having bugs that exist nowhere else. Can you also specify which rebar3 versions you are using and responding to the standard template questions? They are there for a reason, they're usually helpful to help troubleshoot issues.

I cannot replicate this in general. Is this on a shared filesystem in a virtual machine? Those things end up often having bugs that exist nowhere else. Can you also specify which rebar3 versions you are using and responding to the standard template questions? They are there for a reason, they're usually helpful to help troubleshoot issues.

sry about that, i rewrite the issue responding to the standard template as a comment below. Please check it if you got time.

[ferd]

Yeah if it works on the home directory and it works but not on the virtual machine filesystems, I assume the problem is with the virtual machine filesystem's semantics.

We have a https://github.com/erlang/rebar3/blob/main/apps/rebar/src/rebar_file_utils.erl file that handles portable fast file operations by shelling out, and it's possible that in some cases the "copy directory to directory" semantics of a command like cp are not the same. It's going to be very difficult for us to fix that without access to a windows machine with a similar shared path however.