Temurin-build: 明确应在何处定义配置参数

创建于 2020-10-08 · 6评论 · 资料来源: adoptium/temurin-build

从https://github.com/AdoptOpenJDK/openjdk-build/pull/2125#pullrequestreview -504661752中的讨论中脱颖而出

我们需要提供有关更改配置参数的位置的指导。我将FAQ的这一部分放在一起时碰到了它，因为当前情况位于三个地方之一。使用哪种方法取决于我们希望受到影响的人，并且据我所知，我们避免明确应在何处进行更改，而这些更改过去已导致混乱。快速总结：

| 位置| 影响力|
| --- | --- |
| 常规文件（根据此PR）| 仅当通过我们的詹金斯管道运行时|
| 特定于平台的配置脚本| 使用build-farm / make-adopt-build-farm.sh （包括我们的管道）的用户-应该是我们机器专用的东西|
| build.sh | 正在运行makejdk-any-platform.sh的任何人（包括最终用户）|

因此，这取决于我们希望这些内容的最后一行。如果要允许用户尽可能地使用与我们相同的配置选项来复制通过构建，那么我认为它应该在build.sh中，但是如果我们希望它对于用户自己构建它是可选的，那么jenkins管道不是一个坏选择。但是，我们确实应该向项目的新人明确指出应该进行更改的地方，例如通过更新FAQ。

我们应该讨论何时使用每种类型，并举例说明在上述三个位置中何时应添加内容的示例。

我会建议：

平台脚本会影响bulid的环境变量，并包括配置参数以覆盖特定构建机器的内存使用情况。当前，我们确实在其中提供了针对OpenJ9的CUDA和OpenSSL启用之类的东西-可以将它们移至build.sh中，因为我们希望在其中具有VM特定信息（将它们放入常规文件中，如果它们进行更改，将会导致更多的编辑工作）。
groovy脚本当前具有诸如dtrace之类的内容以及诸如JITserver之类的其他openJ9选项（老实说，我从来都不喜欢将它们放在此处），尽管赞成这样做的理由是，这是一种添加特定于特定内容的干净方法Java版本或VM，但是如果您不使用jenkins，则定义有些模糊。也许我们应该保留这些以用于特定于詹金斯的事情，例如默认运行哪些测试套件，也许还有区分正常堆堆和大型堆并删除其他所有内容的选项？
build.sh会设置诸如我们的供应商信息之类的内容，以指示是谁构建的，可以报告错误以及用于GA构建的单独标志。我们有诸如freetype alsa ，以及在那里定义的X11开发路径（也许它们应该在平台脚本中）。我建议，为了最大程度地发挥影响，如果我们希望采用以特定方式一致地构建的openjdk，以使开发人员可以复制影响OpenJDK构建方式的大多数默认配置选项，则应在此处（或其中一种称为formj的脚本）

总体上了解在哪里对构建脚本进行更改也是https://github.com/AdoptOpenJDK/openjdk-build/issues/957的一部分，但我正在创建此操作以限制范围，以弄清楚这个重要问题

documentation enhancement help wanted

资料来源

sxa

👍1

所有6条评论

我们还存在一个问题，可以在回购协议之间分割文件，我认为这会有所帮助...

karianna 于 2020-10-08

👍1

我并不太相信像这样的碎片，但是不管我们是否需要决定应该在什么地方进行记录，将其记录下来都是一个微不足道的第一步（嗯，决定是一个很好的第一步，然后我们就可以记录下来）

sxa 于 2020-10-09

在build.sh和groovy脚本中设置的configure选项应合并到平台脚本中，我认为这些脚本应随后移至makejdk-any-platform.sh下。传递单个标志（例如--use-default-config-args）可能会触发它们，或者省略该标志会禁用它们（因此脚本仅使用用户的config参数）。

这些事情是一个好主意，因为：

只会在一个位置设置config参数，从而更容易查找和更改它们。
将平台脚本移至makejdk-any-platform.sh下意味着使用我们的docker镜像的docker构建只需克隆一个存储库（在完成构建存储库划分后）。
用户无需设置任何配置参数即可启动makejdk-any-platform.sh，并确保构建配置将拥有所需的所有选项，前提是他们正在使用我们的docker文件之一进行构建。
我们可以为每个configure参数设置版本“范围”，而不是为每个发行版复制相同的配置文件。这意味着更少的文件，更少的代码重复，并且还减少了在我们准备新的OpenJDK版本时可能出错的情况。

adamfarley 于 2020-12-04

当我尝试实现build-jdk操作时，我从自述文件开始，并使用makejdk-any-platform.sh来构建jdk，这意味着平台特定的配置是不可见的。

我想知道是否可以将特定于平台的配置下的文件移动到相同的build.sh级别，因此无论是什么构建系统环境，jenkins，git-hub操作，本地构建jdk的用户等都可以使用它？我想那些平台特定的配置是平台特定的，而不是詹金斯特定的。

Groovy脚本是jenkins专用的构建脚本，它将被拆分为单独的仓库https://github.com/AdoptOpenJDK/openjdk-build/issues/1108？

sophia-guo 于 2020-12-07

👍1

通过https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67在jenkins存储库的README.md中阐明了Groovy jenkins参数

我现在打算调整此（openjdk-build）存储库的FAQ，以阐明应在https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67处完成jenkins特定参数的设置，其中基于机器的参数和全局参数应分别在平台文件和build.sh完成

M-Davies 于 2021-03-03

https://github.com/AdoptOpenJDK/openjdk-build/pull/2518已合并，完成了文档更改。这应该可以处理要向项目添加新参数的任何人。本期的最后一部分将是研究我们现有的参数和位置，评估每个参数在当前位置的适用性，并根据此评估是否需要将它们移至另一个位置。但是，这将需要大量工作，考虑到我目前正在处理的多个优先级较高的任务，我不太可能有时间在合理的时间内完成此任务。

因此，我将删除我的任务，并请他人重新评估我们现有的参数。

M-Davies 于 2021-03-10

👍1

此页面是否有帮助？

0 / 5 - 0 等级

Temurin-build: 明确应在何处定义配置参数

所有6条评论

相关问题