Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use $(LIBEXT) instead of manually setting .hdll everywhere #377

Closed
wants to merge 1 commit into from

Conversation

jdonaldson
Copy link
Member

@jdonaldson jdonaldson commented Apr 29, 2020

I'm working through creating a hashlink formula for Homebrew: Homebrew/homebrew-core#53790

One of the CI checks is to validate that any generated libs have known MacOs-related extensions (.dylib, .framework, etc). The current installation script for hashlink uses a platform specific "LIBEXT" variable for the main libhl library, but the supporting libraries (openal, ssl) all use .hdll (a default for windows).

This PR uses the LIBEXT extension for all installed libraries. I tested this on MacOs, and verified the correct behavior for HomeBrew, but I haven't tested it anywhere else.

@Aurel300
Copy link
Member

This is a bit strange. hdll is a HashLink-specific extension that is used on any OS. It is not Windows-specific (that would just be dll), and is similar to Neko's ndll. Also, have you actually tested this working when loading anything from libraries? I don't think it can, since you have not changed this:

strcpy(tmp+strlen(lib),".hdll");

@nanjizal
Copy link
Contributor

I do wonder if rather than Haxe use brew for building packages and risk that older osx are not supported, and brew problems and update aspects, it would be ideal to have some ninja, especially for setting up ocaml and building haxe but also for hashlink.
https://ninja-build.org/ textmate2 uses ninja and it is one of the easiest complex projects to setup and get working on a mac.
Anyway this is not a request for official ninja over brew support just thought it might be something that may interest you, and may work out simpler?

@jdonaldson
Copy link
Member Author

Also, have you actually tested this working when loading anything from libraries? I don't think it can [...]

Thanks, I missed this.

@jdonaldson
Copy link
Member Author

jdonaldson commented Apr 30, 2020

FWIW, here's the explicit check for library extensions : https://github.com/ilovezfs/brew/blob/ee6b0e7c9b5b5f2030830bbca97805d10867cdd6/Library/Homebrew/formula_cellar_checks.rb#L59

Note that this only applies for new applications. Older applications don't have to adhere to this.

@jdonaldson
Copy link
Member Author

I think it's best if we get some sort of exception or provide some sort of whitelist for these hashlink libraries. I'll leave this PR up for more discussion.

@ncannasse
Copy link
Member

Is it just a warning ? If it doesn't prevent the brew to be build I think we should just skip it.

@jdonaldson
Copy link
Member Author

I'm going to cancel this, I don't think modifying the hashlink library naming pattern is a good idea for now.

@jdonaldson jdonaldson closed this May 4, 2020
@jdonaldson
Copy link
Member Author

Is it just a warning ? If it doesn't prevent the brew to be build I think we should just skip it.

Yeah, it's a warning. Still, homebrew is a huge project, and I've put effort into the hashlink formula so as to reduce noise as much as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants