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: https://github.com/HaxeFoundation/haxelib/issues/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: https://github.com/HaxeFoundation/hxcpp/pull/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

[sphis-sinco]

Unclose this.

[tobil4sk]

@sphis-sinco This thread was specifically about a bug with hxcpp resolving library paths, and it has been resolved. Please open a new issue with your exact problem, a minimal sample that reproduces the error, and the outputs of these commands run in an environment where the error is being reproduced:

haxelib version
haxelib --system version

haxelib list
haxelib --global list

I have attempted to reproduce the issue as you described it on discord and wasn't successful. I have yet to try on windows so that could be why.

[tobil4sk]

I've looked into it a bit more and it seems the error message is still coming from hxcpp, so I'm reopening. Please still provide your command outputs.

[sphis-sinco]

@sphis-sinco This thread was specifically about a bug with hxcpp resolving library paths, and it has been resolved. Please open a new issue with your exact problem, a minimal sample that reproduces the error, and the outputs of these commands run in an environment where the error is being reproduced:

haxelib version haxelib --system version

haxelib list haxelib --global list I have attempted to reproduce the issue as you described it on discord and wasn't successful. I have yet to try on windows so that could be why.

Oh no I said that for no reason

[tobil4sk]

@sphis-sinco I've figured out how to reproduce and solve the issue you were running into. It is actually an issue in hxp with unhandled carriage returns on windows (hence why I didn't have it on linux): https://github.com/openfl/hxp/pull/34.

The error was coming from hxp, not hxcpp, it's just that they have identical error messages for a library that isn't found. It's not actually related at all to local repositories.

It can be reproduced by including a library by a name that is different to what is found in its haxelib.json. For example, <haxelib name="Lime" /> instead of lime. Hxp has a fallback mechanism for this situation, but it is broken on windows due to the carriage returns.

This can be fixed by using git hxp and rebuilding lime tools:

haxelib git hxp https://github.com/openfl/hxp
haxelib install format # also required for rebuilding lime tools
lime rebuild tools

Then it should work with haxelib 4.2.0 again.

I've also opened a PR with the same fix for hxcpp: https://github.com/HaxeFoundation/hxcpp/pull/1241

[sphis-sinco]

👍

@sphis-sinco I've figured out how to reproduce and solve the issue you were running into. It is actually an issue in hxp with unhandled carriage returns on windows (hence why I didn't have it on linux): openfl/hxp#34.

The error was coming from hxp, not hxcpp, it's just that they have identical error messages for a library that isn't found. It's not actually related at all to local repositories.

It can be reproduced by including a library by a name that is different to what is found in its haxelib.json. For example, <haxelib name="Lime" /> instead of lime. Hxp has a fallback mechanism for this situation, but it is broken on windows due to the carriage returns.

This can be fixed by using git hxp and rebuilding lime tools:

haxelib git hxp https://github.com/openfl/hxp haxelib install format # also required for rebuilding lime tools lime rebuild tools Then it should work with haxelib 4.2.0 again.

I've also opened a PR with the same fix for hxcpp: HaxeFoundation/hxcpp#1241