可以使用Docker容器作为Conan中的构建依赖吗?

huangapple go评论74阅读模式
英文:

Is it possible to use docker-containers as build-requires in conan?

问题

We use conan to build our libraries and applications as a package/dependency management tool.

我们使用Conan作为包/依赖管理工具来构建我们的库和应用程序。

We want to build our projects with two different toolchains.

我们希望使用两种不同的工具链来构建我们的项目。

As an example:

  • visual_studio toolchain
  • gcc

例如:

  • Visual Studio工具链
  • GCC

But my question is independent of that specific compiler.

但我的问题与特定编译器无关。

According to the documentation I've a few options to do so with conan.

根据文档,我有几种使用Conan的方法。

  1. Install the toolchains locally and create conan profiles referring to the toolchain.

  2. 在本地安装工具链,并创建引用工具链的Conan配置文件。

  3. Define "build requires," which will automatically download the toolchain, and conan will use it, similar to the profile mechanism.

  4. 定义“构建要求”,它将自动下载工具链,并由Conan使用,类似于配置文件机制。

Is it possible to pack the "build requires" tools into a docker container and get conan somehow to invoke the build command through the docker?

是否可以将“构建要求”工具打包到Docker容器中,并以某种方式让Conan通过Docker调用构建命令?

The reason I want to do so:

  • Visual Studio toolchain can be run in a Windows container.
  • GCC toolchain can be run in a Linux container.
  • It is possible to encapsulate the complete toolchain.

我之所以这样做的原因是:

  • Visual Studio工具链可以在Windows容器中运行。
  • GCC工具链可以在Linux容器中运行。
  • 可以封装完整的工具链。

The typical usage of docker+conan looks a little bit different:

Docker+Conan的典型用法略有不同:

In that case, conan runs inside of the container.

在这种情况下,Conan在容器内运行。

Why I want to manage the toolchain-docker-images through build-requires recipes?

为什么我想通过“构建要求”配方来管理工具链Docker镜像?

We have different versions of toolchains (images). It would be nice if we can manage tool-chain versions with build-requires recipes.

我们有不同版本的工具链(镜像)。如果我们能够使用“构建要求”配方来管理工具链的版本,那将非常好。

I want to understand why it's the recommended way to install conan inside of docker combined with the toolchain.

我想了解为什么将Conan与工具链结合在Docker内安装是推荐的方式。

Are there technical limitations / performance limitations if we implement it as described above?

如果我们按照上述描述的方式实施,是否存在技术限制/性能限制?

Thanks :).

谢谢 :).
Toni

英文:

we use conan to build our libraries and applications as a package/dependency management tool.

We want to build our projects with two different toolchains.
As an example:

  • visual_studio toolchain
  • gcc
    but my question is independent of that specific compiler.

According to the documentation I've a few options to do so with conan. https://docs.conan.io/en/1.35/systems_cross_building/cross_building.html#cross-building-with-conan

  1. install the toolchains local and create conan profiles referring to the toolchain.
  2. define "build requires", which will automatically download the tool-chain and conan will use it, similar to the profile mechanism.

Is it possible to pack the "build requires" tools into a docker container and get conan somehow to invoke the build command through the docker?

The reason I want to do so:

  • visual studio toolchain can be run in a windows-container
  • gcc toolchain can be run in linux container
  • it is possible to encapsulate the complete toolchain

The typical usage of docker+conan looks a little bit different:
https://docs.conan.io/1/howtos/run_conan_in_docker.html#docker-conan
In that case, conan runs inside of the container.

Why I want to manage the toolchain-docker-images through build-requires recipes?
We have different versions of toolchains (images). It would be nice if we can manage tool-chain versions with build-requires recipes.

I want to understand, why it's the recommended way to install conan inside of docker combined with the toolchain.
Are there technical limitations / performance limitations if we implement it as described above?

Thanks :).
Toni

答案1

得分: 1

这是不可能的,因为它是内置的。 "tool_requires"("build_requires")只能为使用者的食谱提供信息,它们可以生成环境文件、cmake文件等。

但通过扩展Conan的功能,可能可以实现。您可以创建Conan包,包装有关您的Docker映像的信息,主要是映像名称,可能还包括一些配置,然后通过"profiles"中的"[tool_requires]"注入这些映像信息,例如。

然后,可以使用不同的方法利用该信息。例如,如果食谱继承自实现了“def run()”方法的“python_requires”,该方法将覆盖“Conanfile.run()”的默认方法,您可以在那里自定义注入“docker ....”命令,这些命令将被预先添加。

或者您可以使用新的2.0命令包装器,通过“conanfile.dependencies.build”访问“tool_requires”信息,以便它们可以向命令注入必要的“docker ...”修改。

然而,应该注意的是,安装依赖项时,它们将安装在主机系统中,而不是Docker容器中,因此每个Docker调用都需要正确挂载主机上的Conan缓存并配置以使用它。

总的来说,这听起来是可能的,但可能相当复杂,并且可能会出现意外的问题。在容器内部使用Conan非常有效且相当简单,它在ConanCenter中被广泛使用,许多Conan用户也这样做。

英文:

This is not possible as built-in.
tool_requires (build_requires) can only provide information for the consumer recipes, they can generate environment files, cmake files, etc.

But it might be possible to do it extending the Conan capabilities. You could create Conan packages that wrap the information for your docker images, mostly the image name, plus maybe some configuration, and you could inject those images via [tool_requires] in your profiles, for example.

Then, there could be different methods to leverage that information. For example, if recipes inherit from a python_requires that implement a def run() method that overrides the Conanfile.run() default one, you can customize there the injection of docker .... commands that would be pre-pended.

Or you could use the new 2.0 command wrapper, and via the conanfile.dependencies.build access the tool_requires information, so they can inject the necessary docker ... modifications to the commands.

It should be noted however that when dependencies are installed, they will be installed in the host system, not in the docker container, so it would be necessary that each docker invocation correctly mounts the host Conan cache and configures it to use it.

Overall, it sounds possible, but probably quite complicated, and it could have unexpected rough edges. Using Conan inside the containers works very well and it is quite simple, it is used a lot in ConanCenter, and many Conan users do that too.

huangapple
  • 本文由 发表于 2023年5月10日 18:19:35
  • 转载请务必保留本文链接:https://go.coder-hub.com/76217266.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定