Local repositories break with libraries which use native C++ files

[EliteMasterEric]

hxCodec is a good demonstration of this issue.

1. Use haxelib newrepo to create a local repository.
2. Install hxCodec into that local repo and try to build a project which uses it (hxCodec has several sample projects)
3. You will receive an error that one of the included build files is missing.
4. cd out of the folder and install hxCodec there.
5. You will no longer receive the error about the missing build file.

I presume that whatever functionality is retrieving the build file is using the absolute haxelib location and not respecting the relevant local repositories.

[kLabz]

Probably because of https://github.com/HaxeFoundation/haxelib/blob/development/src/haxelib/api/ScriptRunner.hx#L94, which is also triggering some issues for me (because I don't have a global repository, it breaks easily)

[tobil4sk]

I ran the following commands in a local repo with lime installed (with no hxCodec install in the global repo). It compiled without any issues:

haxelib git hxCodec https://github.com/polybiusproxy/hxCodec
cd $(haxelib libpath hxCodec)/samples/lime-playback
lime build linux

@EliteMasterEric Would you be able to provide an example setup where it is failing for you? Could you also share the output of the following commands?

haxelib --system version
haxelib version

Probably because of https://github.com/HaxeFoundation/haxelib/blob/development/src/haxelib/api/ScriptRunner.hx#L94

I don't think this would be the case. The file is new since the code was refactored, but the CWD behaviour remained the same as it has always been: #272

[kLabz]

It is not the same.
Now not only cwd but also resolution of path to haxelib repo is impacted, as it's resolved from that cwd instead of "real" cwd.

[tobil4sk]

Now not only cwd but also resolution of path to haxelib repo is impacted, as it's resolved from that cwd instead of "real" cwd.

As mentioned in #272, the cwd was always changed to the library path (see the old code). Then the script is run with a command like:

haxe --library dep1 --library dep2 [...] --run Run arg1 arg2 OLD_CWD

Then the child process runs the haxe compilation, and which causes a separate haxelib process to resolve the dependency libraries from the new CWD. This has not changed, so I don't see how the library resolution behaviour could have changed.

The way it works could cause a problem if there is a dev library set to a location outside the scope of the local repo, but this wouldn't be a new issue.

[NeeEoo]

Its caused due to the ${haxelib:repo} in the buildXml macro it doesnt check local packages, if it exists in global packages

its something with the cwd, a way to fix it is to do

<setenv name="HAXEPATH" value="./"/>

in project.xml but it causes it so you have to have to use haxelib newrepo

the way a lot of packages fix it, especially linc packages is by doing this https://github.com/AndreiRudenko/linc_luajit/blob/master/linc/Linc.hx#L36-L61

[tobil4sk]

I think this is the line that's causing the issue:
https://github.com/HaxeFoundation/hxcpp/blob/b1359b43354aa52e7da29dbdd711bace63a51685/tools/hxcpp/PathManager.hx#L109

It changes the cwd to HAXEPATH before executing the haxelib path command. So that would make sense how setting HAXEPATH avoids the problem. I'm not too sure why it should change directory to HAXEPATH? It has been like this since: HaxeFoundation/hxcpp#37, which was merged (not long) before support for local repos was added to haxelib.

EDIT: Maybe this was done in case haxelib is not available in PATH