opened
anton-malakhov
username_0
It's rather a question, not an issue. Is it a deliberate decision to build TBB from sources rather than using pre-built packages?
I could probably provide recipe for how we pack it for tbb package on Intel's channel
Pre-built versus building from sources
issue
created
jakirkham
username_1
Yes, in conda-forge we try as much as possible to build directly from source. There are some rare exceptions, but even those we would like to switch to building from source as soon as it is feasible.
comment
closed
anton-malakhov
username_0
issue
created
anton-malakhov
username_0
thanks!
comment
created
jakirkham
username_1
That said, it would be good if we could find a way for users from conda-forge to get packages from Intel and have them work ok together. One particular example that comes to mind is many users want to use MKL with things like NumPy. We can't very easily package MKL at conda-forge. However if there are ways we could make it easier for users to install MKL backed libraries from Intel, I think that would be very beneficial discussion for both Intel and conda-forge. I don't see why a similar solution couldn't apply to TBB.
comment
created
anton-malakhov
username_0
Difference with MKL is that TBB is open-source, and you, guys, can easily built it from sources. So, do you suggest that Conda-Forge and Intel packages should be really compatible and interchangeable? Sure, that is interesting and necessary discussion. For example, there is Python part in our packages which is absent on Conda-Forge. We rather need to refactor that into multiple TBB-related packages, like `tbb` and `tbb4py`. Though, my desire is that each time a user installs tbb into environment with Python (which is default for conda I guess), the Python module is installed automatically.
comment
created
jakirkham
username_1
Going to reopen so this doesn't get lost. Though would note that the focus of the discussion is changing.

Would also mention that a more general discussion about getting Intel packages and conda-forge packages to work together is occurring in issue ( https://github.com/conda-forge/staged-recipes/issues/3022 ).
comment
reopened
jakirkham
username_1
It's rather a question, not an issue. Is it a deliberate decision to build TBB from sources rather than using pre-built packages?
I could probably provide recipe for how we pack it for tbb package on Intel's channel
Pre-built versus building from sources
issue
created
jakirkham
username_1
I see. So actually one doesn't always need to have Python. There are actually some contributors to conda-forge that spend most of their time in C/C++ libraries.

That said, there was some discussion a while back that is somewhat relevant. The idea was essentially what you propose that if there was a Python and C/C++ library for `tbb` that both would get installed if the user had `python` in their environment already. More details on the proposal are in this [gist]( https://gist.github.com/mcg1969/da5aec380d2ed083b79ddcf151ca16f1 ). This is not implemented yet AFAIK, but there is a lot of interest in this idea.

cc-ing @mcg1969 in case he has more to add.
comment
created
anton-malakhov
username_0
I've implemented TBB's built-in packaging script and opened PR for using it with TBB 2018 U2. Though it aligns the package with what TBB developers want, it still does not yet introduce the Python package separation. If it is ok for short-term - let's merge it. Otherwise, we can remove Python module for now. The plan for separation is settled at Intel anyway, it is just a matter of few months to make it public. There will be `tbb`, `tbb-devel`, and `tbb4py` packages and hopefully TBB repository will include conda recipe as an example or for user builds as well.
comment
created
anton-malakhov
username_0
I've updated the PR that integrates unified build & packaging. But in a month or two we will publish split tbb 2018 U3 packages on intel channel, so you might want to do it right now until U3 is published on conda-forge
comment
created
jakirkham
username_1
Making split packages should be available to us soon. PR ( https://github.com/conda-forge/tbb-feedstock/pull/27 ) moves this feedstock to `conda-build` 3. There's obvious other things we want to do generally throughout `conda-forge` for `conda-build` 3 (using new compilers, taking advantage of new pinning features). Though split packages can proceed without those changes.
comment
created
anton-malakhov
username_0
I'm pleased to announce that Both Intel and Conda-Forge channels have the same structure of the packages, comprising `tbb`, `tbb-devel`, and `tbb4py` now! Looking forward when Anaconda will align its `tbb` package as well (@seibert)

Though, there is one pitfall with tbb4py on Conda-Forge. It does not know how to coordinate with OpenBLAS, thus it's not quite usable in a plain conda-forge setup. If/when https://github.com/conda-forge/staged-recipes/issues/3022 is implemented, it will be much more useful.
comment
created
jakirkham
username_1
Glad to hear it. :)

Yeah there have been some changes in `defaults` with `blas`. We should check in with others to see how that is going and how we can integrate those changes into conda-forge. ( https://github.com/conda-forge/blas-feedstock/pull/12 )
comment
created
anton-malakhov
username_0
There is remaining issues with Anaconda's packages, but they are converging as well.
comment
created
anton-malakhov
username_0
@username_2, new version is ready for conda-forge, do you want to fork it for Anaconda as well? Please do not exclude debug binaries this time from `tbb-devel` package, so, I'll consider this convergence task completed.
comment
created
nehaljwani
username_2
@username_0 tbb{,-devel,4py} v2019.0 are available on defaults.
comment
created
anton-malakhov
username_0
thanks, @username_2 ! I'll take a look. We are releasing 2019.1 actually in a few days, some patches will become unnecessary there.
comment
created
anton-malakhov
username_0
Looks perfectly aligned, thanks! One remaining step though is these additional patches. We'll eliminate the need in them with the next 2019.1 release.
comment
created
anton-malakhov
username_0
Great! The new Anaconda recipe does not need patches, closing it now
comment
closed
anton-malakhov
username_0
issue