[poc] Add lapack/3.10.1 #15556
[poc] Add lapack/3.10.1 #15556
Conversation
* Add recipe * Add test files * Uses gcc recipe to get gfortran rather than the gfortran recipe as it's broken. This won't work for windows or macOS
* Add separate components for blas, cblas, lapack and lapacke to correctly model the relationship between these dependencies and allow the fortran libraries to be linked independently of the C wrapper libraries. * Add conan v2 test package * Remove references to conan gcc package as it is not yet mature enough to support this recipe. Specifically, it does not model the libraries it provides, so a runtime linkage to gfortran can't be appropriately modelled.
Conan v1 pipeline ❌Failure in build 1 (
Note: To save resources, CI tries to finish as soon as an error is found. For this reason you might find that not all the references have been launched or not all the configurations for a given reference. Also, take into account that we cannot guarantee the order of execution as it depends on CI workload and workers availability. Conan v2 pipeline (informative, not required for merge) ❌
The v2 pipeline failed. Please, review the errors and note this will be required for pull requests to be merged in the near future. See details:Failure in build 1 (
Note: To save resources, CI tries to finish as soon as an error is found. For this reason you might find that not all the references have been launched or not all the configurations for a given reference. Also, take into account that we cannot guarantee the order of execution as it depends on CI workload and workers availability. |
|
@memsharded @uilianries @jcar87 @prince-chrismc do you have any opinions on whether a recipe like this should/could be possible with conan? That is, a recipe that specifies it's own requirement for a compiler and brings it in. As far as I can see, we currently face a problem in that a recipe can't override the user profile to:
My ultimate goal with this would be to be able to build an entire toolchain within the conan ecosystem - bootstrap gcc and use it to build glibc and binutils to retain control over binary compatibility without having to resort to using ancient build environments. This is also somewhat related to conan-io/docs#3960 |
* Add gfortran component dependency * Remove duplication of test package source
0aa646a to
9f59c96
Compare
|
@samuel-emrys I have to say it's an unique scenario. Indeed GCC package is the only one which provides fortran libraries so far and creating a separated package it be possible, but requires much more effort, as gcc is a direct dependency of gfortran. Since GCC 11, we are using new Docker images with gfortran already installed, but still, it's fragile as users would not have it installed in their system. My suggestion is keeping a minimal configuration for now, like only supporting with GCC 10 to get aligned with the gcc package. Then we can think getting gfortran separated from GCC package. |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
I've been meaning to come back to this - but is there a reason that a draft PR is being marked stale? |
|
The third-party bot is not very smart :) |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
bump for activation. still in progress. Plan is probably to remove #17173 has demonstrated that there might be a way to bypass the fortran requirement and compile with C instead, so that's probably the avenue that I'll explore here. |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Bump for activation. still in progress. |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This pull request has been automatically closed because it has not had recent activity. Thank you for your contributions. |
Specify library name and version: lapack/3.10.1
Initial proof of concept lapack recipe implementation.
This is a draft to illustrate the requirement to model internal gcc libraries, as presented in conan-io/conan#15128. This is a blocker for this recipe.
An additional blocker for this recipe is that it will fail to build when the user profile defines
CC,CXXortools.build:compiler_executables. This results in the following error:This is because the
gccrecipe fails to override what's been defined in the user profile. This can be rectified by adding the following to thegccrecipe whentools.build:compiler_executableshasn't been defined in the user profile, butCCandCXXhave been.I think this is intended behaviour, but this also illustrates a need to be able to override/dictate a profile for a recipe that's been built by a compiler pulled in via
tool_requiresindependently of what's been specified by the user. This profile shouldn't be propagated to any other recipes except those that directly specify the compiler package viatool_requires.Relates to conan-io/conan#4509