github-actions[bot] on gh-pages
deploy: bceba6e91eb7b404814d88b… (compare)
beckermr on master
explain CUDA compiling isn't wo… add links apply suggestion Co-authored-b… and 2 more (compare)
github-actions[bot] on gh-pages
deploy: 24683fcc0b7525c74499b7e… (compare)
beckermr on master
knowledge_base: add missing cud… Merge pull request #1249 from d… (compare)
cmake
is enough , unless you are using something very specific of qmake
or there is no config for cmake
@mingwandroid the autogenerated ones don't really work for Conda forge. The split devel packages don't get pushed due to the dependency on an other package that is being built at the same time.
I don't really understand what you mean here, can you explain it to me? Maybe it was more broke when you tried them? Should work fine, anyway, if conda skeleton rpm is not behaving as you need it we should fix that. I think the problems you mentioned have been fixed already FWIW conda-build is not closed source!
I've been getting strange errors using conda build
locally on my workstation (Azure build works fine) for my conda-forge recipe "ledger":
...
ld: cannot find -lmpfr
ld: cannot find -lgmp
...
It seems ld
can't find the libraries specified in the host
section of my recipe. Has anyone encountered this before? (conda-build 3.18.9)
Another question: why is it that this package is being built on OSX using clang 8 rather than clang 4?
https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=74186
I don't see anything in particular in the recipe that is asking for clang 8:
https://github.com/conda-forge/abseil-cpp-feedstock/blob/master/recipe/meta.yaml
The build with clang 8 is problematic because then it causes compatibility issues when one depends upon that package:
https://travis-ci.org/bluescarni/piranha-tng/jobs/587826816#L233
(at least if I am interpreting this correctly...)
conda_build_config.yaml
then, thanks a lot for the help
Sorry to bother with another question... looking for some OSX help. The package above (abseil-cpp) installs a bunch of CMake package files, one of which contains the following:
set_target_properties(absl::time_zone PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
INTERFACE_LINK_LIBRARIES "\$<\$<PLATFORM_ID:Darwin>:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreF
oundation.framework>"
)
Thus, it seems like it hard-coded an absolute path rather than a path relative to the conda prefix. This eventually leads to issues when using the package if the host does not have that specific version of the SDK. Should this be considered an upstream problem, or is there something I can do within conda to work around?
The relevant upstream code should be this:
if(APPLE)
find_library(CoreFoundation CoreFoundation)
endif()
absl_cc_library(
NAME
time_zone
[...]
COPTS
${ABSL_DEFAULT_COPTS}
DEPS
$<$<PLATFORM_ID:Darwin>:${CoreFoundation}>
)