-
Notifications
You must be signed in to change notification settings - Fork 46
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
fixCMake doesn't correctly fix $libDir to $developLibDir #301
Comments
This has always been an issue for packaging rizin (maybe still something could be fixed upstream), but so far this fixed (still checking) it for me, thanks on that pointer @mtl1979 :)
|
I counted 7 recipes having either uncommented or commented call to fixCMake... Some of them used sed in addition to fix what fixCMake skipped... I didn't count recipes that use sed only to fix any files generated by CMake... |
As pointed out on IRC, I think that the single quotes are in wrong places... I'm not sure why |
Thought the relativeLibDir would be needed for 32bit, but that has already been taken care for, this works on 64bit and 32bit:
|
Rizin is a bit different in this case, it uses meson/ninja as build system and some python scripts to fill in the paths in the cmake config files, I guess in most cases with cmake builds this will probably fine without any sed magic. |
What it really should do is replace Unfortunately, CMake files aren't as standardized as pkg-config files, so Maybe using sed in addition to or instead of |
That is actually "de-quoting" |
I know what's the difference between single and double quotes... In this case double quotes might have been better choice as first |
Some recipes are using sed in addition to fixCMake as fixCMake still works with fixing header paths... I didn't count how many recipes use sed without fixCMake as it would have taken more than just one use of "inrecipe" function. |
CMake's configuration files use relative paths and thus trying to use full path of $libDir doesn't work...
One solution is to search for
}/lib
instead as that will catch relative paths where the base directory or "prefix" is a variable.The text was updated successfully, but these errors were encountered: