search

bfgroup / b2

B2 makes it easy to build C++ projects, everywhere.
https://www.bfgroup.xyz/b2/
Boost Software License 1.0
76 stars 228 forks source link

Feature/project search #304

Closed grafikrobot closed 1 year ago

grafikrobot commented 1 year ago

Proposed changes

Implements an automatic method for searching and resolving global project references.

Types of changes

What types of changes does your code introduce?

Checklist

grafikrobot commented 1 year ago

@Kojoley - @grisumbras - @pdimov comments appreciated on this.

grisumbras commented 1 year ago

Seems good to me. The only thing I have reservations about is directory search order. It seems to me it's logical to start from the most specific and and with /, but it starts with /.

Also, it seems to not support setting B2_PROJECT_PATH=/boost/core:/opt/boost_core and searching for /boost/core (because it only searches for path.parent $(name) here).

grisumbras commented 1 year ago
  1. Distros users will certainly want a system installed libraries discover out-of-the box (which they should put in site-config.jam I suppose). That will lead to having multiple versions of the same library in the discovery paths. There probably will be a need to favor/force use of system provided libraries too.

This can only be a problem if system packagers start putting .jam files for libraries into packages. I don't expect this to happen, to be honest.

  1. There is certainly will be a future request to have an ability to pin/specify a version of a needed dependency.

This would be achieved with B2_PROJECT_PATH=/project/name:/opt/project_name_xx_yy_zz

  1. I don't think it is a good idea to search for projects which are actually subprojects (Jamfile vs Jamroot). It seems that it will easily allow a situation where you don't know what you are actually using, like there will be cases when someone builds Boost slice and will end up in a mix of system Boost and own build. I feel like when you want to use an external library it should be stated explicitly. Am I overthinking?

Are you talking about something like B2_PROJECT_PATH=/boost:/opt/boost_1.72:/boost/core:/home/me/my_boost_core ?

BTW, I've created a module for explcictly requesting external libraries in #296. As far as I can see, it will also work with the mechanism in this PR.

Kojoley commented 1 year ago
  1. Distros users will certainly want a system installed libraries discover out-of-the box (which they should put in site-config.jam I suppose). That will lead to having multiple versions of the same library in the discovery paths. There probably will be a need to favor/force use of system provided libraries too.

This can only be a problem if system packagers start putting .jam files for libraries into packages. I don't expect this to happen, to be honest.

They won't start putting them in the packages if that leads to ambiguity errors.

  1. There is certainly will be a future request to have an ability to pin/specify a version of a needed dependency.

This would be achieved with B2_PROJECT_PATH=/project/name:/opt/project_name_xx_yy_zz

It doesn't. I won't receive an error that an available version is incompatible, and the needed version will not be found because the search will stop on the first found one.

  1. I don't think it is a good idea to search for projects which are actually subprojects (Jamfile vs Jamroot). It seems that it will easily allow a situation where you don't know what you are actually using, like there will be cases when someone builds Boost slice and will end up in a mix of system Boost and own build. I feel like when you want to use an external library it should be stated explicitly. Am I overthinking?

Are you talking about something like B2_PROJECT_PATH=/boost:/opt/boost_1.72:/boost/core:/home/me/my_boost_core ?

That's the one way to shoot yourself in the foot. The /boost:/opt/boost_1.72 part could be coming from something like site-config.jam. And the /boost/core:/home/me/my_boost_core part is not needed when you will build Boost itself but didn't recursively checkout everything.

grafikrobot commented 1 year ago

4. It seems that it will easily allow a situation where you don't know what you are actually using, like there will be cases when someone builds Boost slice and will end up in a mix of system Boost and own build.

This already happens without this PR. And it's not possible prevent it as changing the default search paths of the compiler is usually not possibly. The only remedy I know of in this general case it to use virtual envs (or equivalent). Hence, I don't think it's worth trying to deal with here.

grafikrobot commented 1 year ago

3. There is certainly will be a future request to have an ability to pin/specify a version of a needed dependency.

Thinking about this.. Yes, probably. But I don't think I'm prepared to try and deal with that now. It's not an easy thing to deal with.

grafikrobot commented 1 year ago

@Kojoley & @grisumbras any other comments before I merge this in? Note, my goal is to push out a 4.10.0 version this coming weekend.

grisumbras commented 1 year ago

None from me.

grafikrobot commented 1 year ago

/backport

github-actions[bot] commented 1 year ago

Successfully created backport PR for version/4.10.0: