-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Boost components #1925
Boost components #1925
Conversation
Some configurations of 'boost/1.69.0' failed in build 1 (
|
Some configurations of 'boost/1.69.0' failed in build 2 (
|
Some configurations of 'boost/1.69.0' failed in build 3 (
|
Some configurations of 'boost/1.69.0' failed in build 4 (
|
Some configurations of 'boost/1.69.0' failed in build 6 (
|
Some configurations of 'boost/1.69.0' failed in build 7 (
|
hello! I had similar idea, as we need to solve several long-standing issues related to boost components, linking order, etc. |
Git error in build 8:
|
Some configurations of 'boost/1.69.0' failed in build 9 (
|
I created the dependency tree for poco similarly: |
Would it make sense to build bostdep as part of the boost package (hidden behind an option)? |
Using boostdep on boost git 1.73.0, I was able to extract the dependency tree. @SSE4 What is the difference between It seems not, because there exist exceptions: e.g. math and test:
dependency tree of boost 1.73.0 modules
|
so yes, it looks like it should print only build-able modules (one who produce static / shared libraries) so the general rule is that build-able module builds (at least) one library (it could build more than one, just like math, serialization or test modules). right now I don't think we should model components for header-only boost libraries. I think this should be the same as components modeled by
I think there are exceptions (e.g. math and test). |
Some configurations of 'boost/1.69.0' failed in build 10 (
|
That makes the dependency tree a lot smaller 😄 I think only math and test are the exceptions (library naming wise)?
|
@madebr maybe serialization as well? (I've seen libraries with name anyway, I think we have few options:
then, we can use the data in recipe to generate components and properly fill also, we need to gather such data for all currently provided boost versions (I guess 1.69.0 - 1.73.0). finally, we have to decide where and how to store that graph. do we need to hard-code it in recipe? I personally don't like it... should we put json or whatever near to the conanfile? sounds better. should we use one json per boost version? probably... could we try to use conandata.yml for that? I doubt as hooks are too restrictive right now for custom fields. @uilianries @jgsogo what are you thoughts on how to organize this better? |
@SSE4 I propose the following:
Eventually, this process can also be used to populate/cull the options. Current content of boost dependency info as a .yml filedependencies:
atomic: []
chrono:
- system
container: []
context:
- thread
contract:
- exception
- thread
coroutine:
- context
- exception
- system
- thread
date_time:
- serialization
exception: []
fiber:
- context
- filesystem
filesystem:
- system
graph:
- math
- random
- regex
- serialization
graph_parallel:
- filesystem
- graph
- mpi
- random
- serialization
iostreams:
- random
- regex
locale:
- thread
log:
- atomic
- container
- date_time
- exception
- filesystem
- locale
- random
- regex
- system
- thread
math:
- atomic
mpi:
- graph
- python
- serialization
nowide:
- filesystem
program_options: []
python:
- graph
random:
- math
- system
regex: []
serialization: []
stacktrace: []
system: []
test:
- exception
thread:
- atomic
- chrono
- container
- date_time
- exception
- system
timer:
- chrono
- system
type_erasure:
- thread
wave:
- filesystem
- serialization
libs:
atomic:
- boost_atomic
chrono:
- boost_chrono
container:
- boost_container
context:
- boost_context
contract:
- boost_contract
coroutine:
- boost_coroutine
date_time:
- boost_date_time
exception:
- boost_exception
fiber:
- boost_fiber
filesystem:
- boost_filesystem
graph:
- boost_graph
graph_parallel:
- boost_graph_parallel
iostreams:
- boost_iostreams
locale:
- boost_locale
log:
- boost_log
math:
- boost_math_c99f
- boost_math_c99l
- boost_math_c99
- boost_math_tr1f
- boost_math_tr1l
mpi:
- boost_mpi
nowide:
- boost_nowide
program_options:
- boost_program_options
python:
- boost_python
random:
- boost_random
regex:
- boost_regex
serialization:
- boost_serialization
- boost_wserialization
stacktrace:
- boost_stacktrace
system:
- boost_system
test:
- boost_test_unit_framework
thread:
- boost_thread
timer:
- boost_timer
type_erasure:
- boost_type_erasure
wave:
- boost_wave
|
@madebr yes, we still need to reduce the graph, to handle |
I want to safe the dependency information to the export folder, def export(self):
self.copy(self._dependency_filename, src="dependencies", dst=self.export_folder) (where self._dependency_filename is "dependencies-1.73.0.yml") Now my question is: |
@SSE4
Are these dependencies hard? Does mpi require boost_python? You wrote earlier that mpi is not built right now, so does that mean that |
Same with |
boost.mpi may build python module, but it's not hard dependency (optional one).
enabling MPI requires some another dependency, like OpenMPI or Microsoft MPI, neither one is in CCI yet. |
adding @grafikrobot to this thread just in case he wants to add something on boost dependencies relationship |
for @madebr |
@SSE4 @madebr I used upstream find_package because, it can be generated without modular boost and can be done automatically (adding version "should" be trivial) and then I am sure to have compatible components with upstream (the most important point for me here is the upstream compatibility...) The issue is that with pre 1.70.0 boost, cmake package were not released, and we should be using cmake's packages. |
Perhaps it makes sense to only attempt to support components and their dependencies in version of Boost older than 1.70. Revert to the current behavior of a single monolithic target for those versions. |
Some configurations of 'boost/1.69.0' failed in build 11 (
|
I've added a comment here (conan-io/conan#7283 (comment)) that applies to this PR, it is related to how/where to store dependencies information. Please refer to that one, and we can continue here with what's applicable to this PR. |
Some configurations of 'boost/1.69.0' failed in build 12 (
|
Some configurations of 'boost/1.70.0' failed in build 13 (
|
I detected other pull requests that are modifying boost/all recipe:
This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there. |
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. |
Specify library name and version: boost/1.73.0
I this to get dependencies between boost libraries from boost generated cmakes. Pre 1.70 Boost, it should come from FindBoost.cmake copied in the recipe, but I have not tested yet.
It is far from ready now, but I would just know if it seems too hacky or not to build components for boost and I would like if I continue spending time on it or not.
conan-center hook activated.