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
Allow missing libraries #7847
Allow missing libraries #7847
Conversation
Testing this on $ brew linkage --test root
Missing libraries:
libASImage.so
libCling.so
libCore.so
libEG.so
libFTGL.so
libFoam.so
libGLEW.so
libGX11.so
libGed.so
libGeom.so
libGpad.so
libGraf.so
libGraf3d.so
libGui.so
libHist.so
libHistFactory.so
libImt.so
libMLP.so
libMathCore.so
libMathMore.so
libMatrix.so
libMinuit.so
libMultiProc.so
libNet.so
libNew.so
libPhysics.so
libProof.so
libProofPlayer.so
libRCsg.so
libRGL.so
libRHTTP.so
libRIO.so
libROOTBrowserv7.so
libROOTDataFrame.so
libROOTGpadv7.so
libROOTHist.so
libROOTHistDraw.so
libROOTNTuple.so
libROOTVecOps.so
libROOTWebDisplay.so
libRint.so
libRooFit.so
libRooFitCore.so
libRooStats.so
libTMVA.so
libThread.so
libTree.so
libTreePlayer.so
libTreeViewer.so
libWebGui6.so
libXMLIO.so
libXMLParser.so
libXrdProofd.so
libvdt.so
Broken library linkage ignored
[linuxbrew@docker] [Sun Jun 28 04:45:46] [Last Exit Code: 0] |
Can we have a mechanism for macOS/Linux? I do not know any of these cases on macOS, and a few on Linux, so this is mosty a Linux-only "issue". The idea would be to have two different lists/functions for both OSes. |
I'm not sure I understand the question/request. The way I implemented it here is that addition of |
Can you provide an example usage of what the
Yes, I think so. I think this should specify a list of libraries (or even a glob) and there needs to be a match otherwise it's an error (so we are forced to remove these when they no longer reply).
If we have no usage on macOS so far: yes, I think so. In that case the DSL should be designed in such a way that we could add it on macOS later if need be and be clear that it only applies to Linux now. Nice work @maxim-belkin! |
In the current implementation, it'll look like this: (not sure why the above link doesn't render into a code snippet 😕)
Makes sense. Shall it be implemented as a block or similarly to
OK, I'll update the PR accordingly. But just to make sure we're on the same page: do you expect formulae on macOS to respond |
Not the same repo.
Gotcha. Yeh, I think this should specify the libraries and have something in the name or a parameter that mentions
Similar to
Thanks! I think it depends on whether the name is Linux-y or whether it takes a |
I think we should go with linux in the method's name. We have done the same for on_macos/on_linux, where we have specific methods by OS, and not one generic method with a parameter. By the way, I think the Or we can just go for a list of files everywhere to be consistent. There won't be that many formuale needing this anyway (maybe 3-4). |
Or: it always has to be inside a
A middle-ground would be a glob. My only concern is this list is pretty long.
If these are all files that are in |
👍 Bike shedding: on_linux do
ignore_missing_libraries %w[libASImage.so libCling.so libCore.so]
end or perhaps |
Works for me 👍. |
c6e78a8
to
e165f45
Compare
Updated. Formulae can now specify ignore_missing_libraries ["libASImage.so", "libCling.so", "libCore.so", %r{libxcb\.so\.\d}]
|
e165f45
to
f8ece3d
Compare
Shall we add a special case |
I'm inclined not to add the additional complexity. |
I think this needs a rebase and a quick |
f8ece3d
to
f2ddcda
Compare
Thanks @maxim-belkin! Note that this shouldn't be used in formulae until we tag a release that contains this commit, but it can be tested on e.g. CI builds. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! Some comments that'd be nice to address.
case x | ||
when Regexp | ||
x.match? lib | ||
when String | ||
lib.include? x | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about when it's neither? Would be nice to error in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can add some logic here but... shall we wait and see if there is a need for that? Right now I suspect there will be 0 use cases for that error-catching "else".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will fail non-gracefully if there's a need for that. An else
with a raise
is minimal code to be maintained but will produce a nicer error message
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will fail non-gracefully if there's a need for that.
How would this fail? I thought it'll just quietly ignore it. I'm probably missing something... Anyways, I agree with adding an else
but shall it odie
or owarn
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I guess "fail" is the wrong word here but "silently ignore the invalid non-String/non-Regex input" is probably a better one.
class << self | ||
undef on_linux | ||
|
||
def on_linux(&_block) | ||
yield | ||
end | ||
|
||
def ignore_missing_libraries(*libs) | ||
libs.flatten! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will modify the caller which doesn't seem like what we'd want. Merging with libs.flatten
seems better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will happen if you use this on macOS? I'd say it should have a custom error rather than "method not defined"
def broken_dylibs_with_expectations | ||
output = {} | ||
@broken_dylibs.each do |lib| | ||
output[lib] = (unexpected_broken_libs.include? lib) ? ["unexpected"] : ["expected"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be an if
? Bit hard to follow as-is.
brew style
with your changes locally?brew tests
with your changes locally?This enables formula creators/editors to say that the formula can have broken linkage by adding
allow_missing_libs
to the formula definition.Things to consider:
broken_dylibs
only?false
on a Mac and defineallow_missing_libs
on Linux only (underextend/os/linux/linkage_checker
)?CC @sjackman @iMichka