metacall 0.5.27 (new formula)

[AkechiShiro]

• [X] Have you followed the guidelines for contributing?
• [X] Have you ensured that your commits follow the commit style guide?
• [X] Have you checked that there aren't other open pull requests for the same formula update/change?
• [X] Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• [X] Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• [X] Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

The only warning I'm getting with brew audit --strict --new --online metacall the following :

metacall:
           * Stable: version 0.5.27 is redundant with version scanned from URL
Error: 1 problem in 1 formula detected

---

Also note this formula is only for MacOS

[AkechiShiro]

@SMillerDev If you have any idea on how to solve the CI/CD error that is causing the failure, please tell me what would be the recommended course of action to solve it

[SMillerDev]

Making it follow the rule here: https://docs.brew.sh/Acceptable-Formulae#stuff-that-requires-vendored-versions-of-homebrew-formulae should fix the build issue.

[AkechiShiro]

Hey @SMillerDev, the issue with Node is mitigated for now, (I disabled it to test & make sure it's not failing due to it), the flag BUILD_SECURITY and FORK_SAFETY are based on the flag upstream, as you've recommended me to do so.

The CI/CD still fails. I cannot reproduce the failure locally on my OSX-KVM machine using brew install --verbose --build-bottle metacall, the bottle builds successfully, and in the end, I get this file metacall--0.5.27.big_sur.bottle.tar.gz , can I have some pointers or get more logs of why the latest CI/CD is failing due to CMake failing to build a specific target ? See this

[SMillerDev]

All the logs are output by CI.

[AkechiShiro]

The builds fail because this fails, now I did not find any other errors, hence why I'm asking if it could be possible to have the log file, that is being said to be seen.

CMake Error at /tmp/metacall-20220827-81360-1bt1jmf/core-0.5.27/build/source/detours/funchook_detour/funchook/src/funchook_detour_depends-stamp/funchook_detour_depends-build-Release.cmake:49 (message):
  Command failed: 2

   '/opt/homebrew/Cellar/cmake/3.24.1/bin/cmake' '--build' '.' '--config' 'Release' '--target' 'install'

  See also

    /tmp/metacall-20220827-81360-1bt1jmf/core-0.5.27/build/source/detours/funchook_detour/funchook/src/funchook_detour_depends-stamp/funchook_detour_depends-build-*.log


make[2]: *** [source/detours/funchook_detour/funchook/src/funchook_detour_depends-stamp/funchook_detour_depends-build] Error 1
make[1]: *** [source/detours/funchook_detour/CMakeFiles/funchook_detour_depends.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

If it is not possible, could you please tell me, how I could reproduce the CI/CD for ARM tests only (or even just reproduce the CI/CD environment locally), can I use brew-test bot ? Or is it only made for maintaining Homebrew Core ?

[AkechiShiro]

@SMillerDev after checking with upstream, the flag FORK_SAFETY needs to be disabled for macOS, else the bottle fails to build.

The CI/CD is now failing due to

This is a direct dependency of the libraries used in metacall and cannot be tweaked upstream, I request an exception be made for this warning alone.

If needed, I can ask upstream to further clarify why an exception is needed.

If a solution is advised or recommended, we can talk about it as well, please feel free to tell me what would be a good compromise.

[SMillerDev]

This is a direct dependency of the libraries used in metacall and cannot be tweaked upstream, I request an exception be made for this warning alone.

Why can't it install in a directory in libexec, as is convention for non-standard files.

[viferga]

@SMillerDev One more thing about the bootstrap files (the non standard files installed in the lib directory). Some runtimes are really hard to embed, basically they do not provide embedding API, one example is NodeJS. In order to overcome this, we designed a bootstrapping script that creates a trampoline between C/C++ and JS land, so the runtime is easier to embed. They are installed on the same location of the libraries (aka loaders, which are plugins loaded at runtime) because it simplifies the design and finding the location across multiple platforms. Right now there's many package managers and build system which depend on this, and making a change would be difficult for all platforms. Also this assumption makes simpler to solve other related problems.

The only languages that have this are NodeJS (bootstrap.js), TypeScript (bootstrap.ts), Java (which I think provides a compiled version of this, bootstrap.class or similar) and C# (which is the same as Java but with .dll extension).

The main project only provides a unique library which is libmetacall.so. The rest of libraries are all plugins that metacall loads at runtime, either for providing serialization, or fork safety (like has been talked in this thread already) or other languages. All dependencies are optional, in theory you can select any language support you want.

[SMillerDev]

Why would it be difficult for package managers? It should just be part of the cmake configuration where this is installed.

[viferga]

Why would it be difficult for package managers? It should just be part of the cmake configuration where this is installed.

@SMillerDev Are you talking about the env vars? As far as I know CMake does not allow to install environment variables. And if you check the different launchers, they are highly platform and package manager dependent. So having this launcher script implemented in upstream will only provide problems in order to package it on different package managers.

The restrictions and design decisions of Guix are very different from Brew for example.

What's the problem of the launcher script by the way? Does it conflict with some design decision or restriction of Brew?

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.