Questions tagged «builds»

最简单的构建类型是将(源)代码转换为可运行的已编译二进制文件的过程。更复杂的构建也可以运行单元测试或集成测试,并可以使用工具生成有关代码质量的报告。最后,构建通常是由持续集成(CI)系统自动触发的。

5
持续集成工具在一个单独项目中提供什么优势?
如果您正在做一个单独的项目-您是否会使用CI工具从存储库中进行构建?我在团队环境中使用了Hudson和Cruise Control,在该环境中,任何人只要签入任何东西就必须立即构建。 我认为版本控制的价值仍然显而易见,但是我是否需要在每次提交后进行构建,就像我只是在本地计算机上进行构建一样,没有人提交?

4
用C ++编写构建脚本是否有意义?
我正在使用CMake生成我的项目IDE / makefile,但是我仍然需要调用自定义“脚本”来操纵我的编译文件甚至生成代码。 在以前的项目中,我一直在使用Python,而且还可以,但是现在在我正在处理的两个非常大的项目中管理很多依赖项时遇到了严重的麻烦,因此我想尽可能减少所有地方的依赖项。 有人建议我使用C ++编写我的构建脚本,而不是为此添加语言依赖。项目主题本身已经使用C ++,所以我可以看到几个优点: 要构建整个项目,只需要一个C ++编译器和CMake,就没有其他必要了(所有其他依赖项都是C或C ++); C ++类型的安全性(使用现代C ++时)使一切变得更容易“正确”; 它也是我所熟悉的语言,因此即使我能够编写一些不错的Python代码,也可以更轻松地使用它。 潜在的执行速度提升(但我认为这不会真正被察觉); 但是,我认为可能会有一些缺点,并且由于我尚未尝试,所以不确定真正的影响: 编写代码的时间可能会更长(也就是说,我不确定,因为我在C ++中足够高效,可以编写可以快速工作的东西,因此对于该系统来说,编写它不会太长)(编译时间不应在这种情况下是一个问题); 我必须假定我将作为输入阅读的所有文本文件都在UTF-8中,我不确定可以在运行时使用C ++轻松地对其进行检查,并且该语言不会为您进行检查。 C ++库比脚本语言更难管理。 我缺乏经验和前瞻性,所以也许我没有优势和劣势。所以问题是:为此使用C ++是否有意义?您有报告的经验吗,您是否看到了可能重要的优点和缺点?

6
“自动构建”是什么意思?
我正在尝试将持续集成添加到项目中。 根据Wikipedia的介绍,CI的一项主要内容是自动构建。但是,由于CI和构建自动化文章似乎不同意,我对确切的含义感到困惑。 特定的混淆点:在以下情况下, “自动构建”是什么意思: 使用解释性语言(例如Python或Perl)的项目? 在最终用户的计算机上从源代码构建? 具有不能简单地预编译和分发的依赖项的应用程序,例如用户计算机本地的RDBMS中的数据库?

5
Ant是否仍在Java构建的“主流”中?
我们一直在慢慢地用更全面的Ant构建(例如从CVS中获取,清理编译,jar,存档,电子邮件等)替换批处理命令文件(windows .bat),这些命令文件只是破坏了在开发人员IDE中编译的类。 我已经花了很多时间在Ant上学习(和调试问题),所以我最习惯将其用于这些任务。但是我不知道蚂蚁是否仍然像我刚开始学习时那样被广泛使用,还是“世界已经发展到”一种新的东西(也许更光滑了)。(例如,我开始看到分发了更多的Maven构建资料,例如,我从未使用过。) 这个问题的实际含义是,我是否要促使新开发人员学习Ant,还是应该为构建进行其他学习? 我从不总是掌握趋势,因此,很高兴听到其他Java开发人员的意见,他们认为这是最好的构建工具,以及他们认为新开发人员应该学习的知识。
14 java  training  maven  builds  ant 

6
您可以一步一步构建吗?
从joel测试: 您可以一步一步构建吗? 我必须说我不能。我目前正在使用一个Web应用程序,该应用程序具有必须进行部署才能部署的项目的电子表格列表。所以我的问题是如何使它自动化?是否必须在整个组织范围内?提示/技术?

4
升级时无法修补开源软件吗?
最近,我在集成到应用程序中的开源软件包中遇到了一个令人讨厌的(已确认)错误。根据公共问题跟踪工具,此错误已在该软件的最新版本中得到解决。 有时您需要该错误修复程序来避免对特定模块进行昂贵的重构,但是由于技术和/或政治原因,您将无法升级到最新版本。 在检查所做的代码更改时,此修复程序似乎很简单,我认为可行的选择是自己修补代码并重新编译我当前批准的软件版本,但是批评者希望证明这种情况几乎总是一个坏主意。这是有风险的,并且会带来麻烦的复杂性。 在他们眼中,因为此代码更改仅由我们完成,仅供我们使用,所以它必须是代码库的一部分,这意味着,与其将开源软件作为第三方依赖项引入,我们还必须将其作为一个新项目引入并纳入将其自动构建到我们的构建过程中。 对我来说,我认为这是错误的做法,因为我们会将他们的代码从其源代码控制存储库中提取到我们的代码中,并且在此之前发生的任何代码更改背后,我们都失去了历史。同样,对于需要进行如此小的代码更改而言,这似乎太复杂了。 在这种情况下执行上述操作会不好吗?如果是这样,那么当开源需要改变但仅出于内部利益而改变时,理想的情况是什么?

3
有什么好的方法来组织输入文件(Makefiles,SConstruct,CMakeLists.txt等)以构建自动化软件?
我喜欢对我的代码做的一件事是确保将其重构为可管理的部分。但是,在构建软件时,我发现无论我最终使用的构建自动化软件(最近是GNU Make或SCons)最终都变得一团糟。输入文件看起来像长脚本,似乎不容易重构。我希望能够以某种方式对其进行重构,但是“功能”的概念在某些构建自动化软件中的行为与编程语言中的行为并不完全相同,因此我发现很难编写可管理的代码任何中等复杂项目的Makefile文件或SConscript文件。 在编写用于构建自动化软件的可管理输入文件方面,有任何建议吗?与软件无关的建议是最好的,但是即使是关于特定构建自动化工具的建议也将有所帮助,尤其是Make或SCons,因为这就是我在项目中一直使用的。 编辑:正如Thorbjørn所指出的,我应该添加一些上下文和用法示例。我正在完成化学工程博士学位,并从事计算科学方面的研究。(我是SciComp.SE上的一名程序员,对于那些访问的人来说。)我的项目通常涉及混合编译语言(C,C ++,Fortran),它们执行某些繁重的脚本语言(Python) ,Perl)用于原型制作,偶尔也可以使用特定领域的语言进行原型制作或技术用途。 我在下面添加了两个示例,大致在250行范围内。对我来说,问题通常是缺乏模块化。这些项目中的一些可以组织成模块化的单元,并且最好按照这些思路抽象出构建的各个部分,以使我和将来的维护者更容易跟踪。将每个脚本分解成多个文件一直是我脑子里一直在想的一个解决方案。 第二个示例特别重要,因为我很快将不得不处理大量文件。 这是一条265行Makefile对我来说的样子,取自一个实际项目,并尽我所能组织: #!/usr/bin/make #Directory containing DAEPACK library folder daepack_root = . library = $(daepack_root)/lib wrappers = $(daepack_root)/Wrappers/DSL48S c_headers = parser.h problemSizes.h f77_headers=problemSizes.f commonParam.f f90_headers=problemSizes.f commonParam.f90 includes = -I. -Iinclude -I/usr/include/glib-2.0 \ -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 \ -I/usr/include/libgdome -I/usr/include/gtest/ #Fortran 77 environment variables f77=gfortran fflags=-ggdb -cpp …

2
部署脚本是否应该是构建的产物?
这是一个用Java编写的Web项目。 因此,我正在编写构建和部署脚本。为了创建构建,我使用了ant。詹金斯(Jenkins)完成了连续构建。 构建生成3个不同的工件: 战争档案 带布局的拉链 带图片的拉链 到目前为止,一切都很好,但是现在我需要编写部署脚本,该脚本应该: 将战争(工件1)部署到在服务器1上运行的tomcat 将工件2放置在服务器1的特定目录中 将工件3放置在服务器2的特定目录中 因此,我正在与我的同事交谈,他说我们还应该生成一个工件(也许是deploy.xml),当将其放置在正确的服务器上时,就可以部署这些工件。 因此,将有另一个脚本,它将是: 下载詹金斯文物 scp到每个服务器,并将deploy.xml放在此处 远程调用deploy.xml 使我有些不舒服的是将deploy.xml作为构建工件的行为。其背后的动机是能够进行部署而无需访问VCS存储库,因此构建将是自包含的,即,任何构建只能使用Jenkins生成的内容才能投入生产。 部署脚本应该放在哪里?它们应该只在VCS还是应该是构建工件?


4
发布版本与每晚版本
一个典型的解决方案是在构建服务器上运行CI(连续集成)构建:它将分析源代码,进行构建(在调试中)并运行测试,测量测试覆盖率等。 现在,另一种通常称为“夜间构建”的构建类型:做一些缓慢的工作,例如创建代码文档,制作安装程序包,部署到测试环境以及针对测试环境运行自动(烟熏或接受)测试等。 现在,问题是: 拥有第三个单独的“发布版本”作为发行版本更好吗? 还是在发布模式下“立即构建”并将其用作发布? 您在公司中使用什么? (发行版本还应在潜在产品版本的源代码控制中添加某种标签。)

1
通过微前端向下发送冗余代码
我对微前端的理解是,他们解决的关键问题是帮助企业拥有多个可能组成不同的团队,研究将用于组成大型Web应用程序的单个组件/小型应用程序。 这里要解决的关键问题是多个团队独立工作的能力,并且仍然能够构建大型复合材料。问题不在于为最终用户提供精简的发行包。这种理解正确吗? 的确,如果我们有多个用于组成大型Web应用程序的小型应用程序,则有可能会有多个小型应用程序将相同的Javascript库(例如Lodash)作为最终用户的一部分传送给最终用户的浏览器。各个供应商捆绑包是否导致一定数量的重复/冗余代码被发送给用户? 在设计前端应用程序时,这不是我们应该担心的问题吗?

1
构建脚本和构建服务器的职责
我需要对构建脚本和构建服务器的职责进行一些说明。 我在网上阅读了几篇有关持续集成和构建的文章。包含 F5密钥不是构建过程 构建服务器:项目的心脏监护仪 每日构建是您的朋友 我和我的顾问就软件的构建过程进行了交谈。因为他很有经验,所以我相信他的发言,但是我感到困惑。 据我了解,根据我的研究(由于这是我要提出的问题,请在此处对我进行纠正),理想应该如下: 每个项目都有其构建脚本 这个脚本建立了项目 该脚本确保依赖项是先前构建的 由于依赖关系可能是其他项目,因此使用自己的构建脚本会产生树状层次结构。可能会有一个顶级构建脚本来构建所有项目和应用程序。 但是,构建服务器的职责是: 签出仓库 触发构建 触发测试和其他质量检查工具 使工件可用 可以手动,每晚或每次存储库更改时触发 据我所知,我的顾问的目标是使一个构建脚本变得不灵活且不可维护(除了为我们的旧代码库创建一个构建脚本会花费很长时间的事实)。此外,构建服务器还应维护依赖关系,例如在创建新依赖关系时使用较旧的依赖关系。特别是Ant因为它是一个具体的主题,因此无法构建代码库中使用的所有各种技术,并且无法维护依赖性。 您能否详细说明目标并明确职责?

5
要将git版本集成为内部版本号?
我和一个同事轮流讨论/讨论在构建时将从当前git存储库派生的版本集成到我们的代码中的问题/优点。 我们认为优点包括: 无需担心人为错误更新版本号 我们在设备中找到的内容与源于它的源代码之间的可追溯性 (对我们而言)出现的问题包括: IDE派生的构建系统(例如MPLABX)可能很难弄清楚将这些挂钩放置在何处(最终可能会很俗气) 实际将其集成到构建脚本/ makefile中的更多工作 耦合到特定的构建方法(例如,如果一个人使用XCode和另一个MPLABX进行构建怎么办)可能会给下游带来意外 因此,我们很好奇其他人在这场辩论中的地位。讨论变得容易流传开来。那里有很多人坚持端到端的自动化,把大量的前期工作挂在了一起,并耦合了它带来的影响。辩论的另一端还有很多其他人,他们所做的最简单的事情就是行之有效,并且承受风险。 对于哪一方最好着陆有合理的答案吗?
12 c  git  builds  build-system 

4
是否应该使用“ make clean”而不是“ make”的通用规则?
我现在正在编写一个多文件程序,并且由于某种原因导致我的程序失败,显然只运行“ make”(因为在大多数情况下人们会直观地认为需要这样做)。我想我可以提供有关该问题的更多详细信息,但重要的是它在使用“ make clean”时确实可以运行。所以我想知道是否有人知道运行“ make clean”而不是“ make”的一般经验法则
11 c++  builds  make 

2
如何正确管理C / C ++项目的依赖关系?
我有一个使用3-4个不同的开源C / C ++库的项目。 我为多个平台构建了这些库,并在我的项目中检入了针对不同平台的包含文件和静态库。 但是,我遇到了两个问题。所有这些项目都与依赖项管理有关。我正在寻找最佳实践建议。 1)我怎么知道我到底使用什么? 我没有办法获得静态库的版本。结果,我需要以某种方式跟踪我正在使用哪个版本的静态库(可能是生成它的提交的SHA)? 当我需要确定何时升级这些库时,这一点尤其重要。 2)如何复制构建? 我可能很难为特定平台构建一些特定库。我花了一段时间才弄清楚。 下次需要构建相同的库可能需要半年时间(无论出于何种原因都需要升级。但是,到那时,我绝对不会记住任何东西以及构建它的环境将早已不复存在。 3)我应该分叉这些库以获取源代码的副本吗? 这是一个较小的问题。但是,这仍然是一个问题。确保构建是可复制的(这需要源代码)是一件很高兴的事。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.