Talk:List of build automation software

Misc
I'm not sure what is meant by "Make-based". I think what might be meant is "make-like". --Edalytical (talk) 04:25, 2 May 2008 (UTC)


 * agree. I changed section title to Make. No pussy footing around! Stevebroshar (talk) 13:23, 30 May 2024 (UTC)

There are no reason to break out the make-based tools uniquely, except possibly to mention make in the history of build automation. The list is in fact incorrect. Build tools should probably be organized based on ability to do source code and binary dependency management vs. workflow automation, and whether the tool is an interpreter for a scripting language (make, Ant) or does not require scripting (OpenMake). Seanblanton (talk) 21:50, 3 November 2008 (UTC)


 * Well, historical is not a bad reason. But, flatter is better. ... I re-organized, but left make vs. non-make (other). Stevebroshar (talk) 13:24, 30 May 2024 (UTC)

The choice of entries looks strange, what is the criteria, why not to put Redo not yet in Wikipedia, Scons and Waf which have their wikipedia page, Buildout that is also in Wikipedia and link to this true page, and probably most of the Category: Build automation and Category: Compiling tools? --marc (talk) 20:58, 29 April 2012 (UTC)

Shouldn't make-alikes list include Borland make, at least for historical reasons? — Preceding unsigned comment added by 178.140.244.14 (talk) 16:09, 15 September 2012 (UTC)


 * What's Borland? :) Stevebroshar (talk) 13:24, 30 May 2024 (UTC)

I see what the article is trying to achieve and I agree that that the way it is split out is awkward. --Rriehle (talk) 15:30, 17 March 2015 (UTC)
 * Continuous Integration isn't a type of tool and it isn't a language; it is a practice. All references to Continuous Integration outside of the practice context should be corrected. You can perform Continuous Integration with many of these applications if you organize correctly.
 * Many of these tools listed in this article are build tools or build scripting languages and not what the community would consider build automation tools; Build Automation tools automate the running of the build process, involving build tools or build scripting languages. Make, NMake, NAnt are all just build tools, for example. Ant is among the more ubiquitous build tools and it seems to be missing from the article, which takes away from the consistency either way).


 * Where do you see a difference between "just build tools" and "built automation tools"? Schily (talk) 16:42, 19 March 2015 (UTC)
 * Interesting distinction. I wonder if your view is widely held. ... Thing is, it's a grey area between (just) build and build automation. If I am building via an IDE then create a makefile to build outside of the IDE I have automated the build. But, in some contexts one starts with a makefile instead of building via an IDE. In that case, make is not really automating a process that was previously more manual. ... As with many things it's a matter of context and perspective. Stevebroshar (talk) 13:29, 30 May 2024 (UTC)

Another build tool for python (maven-like): https://pybuilder.github.io/ — Preceding unsigned comment added by 62.192.66.236 (talk) 11:41, 4 May 2017 (UTC)

Configuration Management Tools List in the wrong place
"Configuration Management Tools" section should not be here; there already is one at List_of_revision_control_software 78.141.139.10 (talk) 15:36, 19 March 2013 (UTC)

Concur, though a link to the list of configuration management tools would be very useful. The tools listed in the configuration management section are not project configuration management tools (which is what is what one usually thinks about when doing software builds). These tools are system configuration tools, which is useful for network administrators but not so relevant for software authors. Unless the Wikipedia author community decides otherwise, this section should be replaced with a link to sw project configuration management tools. — Preceding unsigned comment added by 157.127.239.146 (talk) 00:24, 27 April 2017 (UTC)

Page notice added
Template:Editnotices/Page/List of build automation software - that all entries should already have an article. Any objections? - David Gerard (talk) 11:55, 3 March 2014 (UTC)

@David: You reverted my addition to the list, and then I saw this rule about entries needing an article. I'm new to editing wikipedia, so I'm not sure if this is the right place to talk, but to avoid future mistakes I have to ask: is this a general rule adopted by wikipedia for all lists (the "Template" seem to point in this direction) or is this specific to this page (I certainly saw many wiki lists with items without articles, e.g. Comparison_of_continuous_integration_software).

Can you please clarify? There's probably a good reason for the rule: I get the goal to have a consistent encyclopedia, but on the other hand I'm afraid it adds a barrier to keeping lists up to date. For example I can always find 5 minutes to add an item with a 1-liner summary + informative external links, but currently I'm not committed to writing a full article. Thanks for your feedback - Antoine Poliakov (talk) 15:38, 21 March 2014 (UTC)

Scripting/Home-brew
We might note that (almost?) any scripting language can be used to construct a build automation. Personally I just use a BASH script to automate the build of any of my larger project, (be they C/C++ Haskell Perl or even Java). I would be interested to know how many people/projects also use BASH for build automation. alexx (talk) 12:01, 16 March 2014 (UTC)

gruntjs
As far as I know, [| gruntjs] is also used as a build automation tool - but where to put it in this list? 93.231.132.207 (talk) — Preceding undated comment added 14:24, 18 April 2014 (UTC)

Opus Make
Opus Make has existing for a very long time, but unfortunately hasn't been updated in years. Opus is very powerful. http://www.opussoftware.com/ •  Sbmeirow  •  Talk  • 19:31, 21 April 2014 (UTC)


 * I looked at the link. Opus as a company has not updated their site since 1998. The last version of Windows they support is 95  I think they might no longer be supporting their packages with updates. If the article is going to include older (historacial) and no-longer maintained packages, it might be a good idea to change the list into a table with a column to denote wheather or not the tool is still maintained. I think this would be a good feature to help users differentiate between currently maintaned and historacal tools. Seamus M. Slack (talk) 23:00, 8 November 2019 (UTC)

Add Crawler-Lib Build Tools
There is a new free build automation toolbox made with powershell: http://www.crawler-lib.net/build-tools — Preceding unsigned comment added by 84.171.98.25 (talk) 16:43, 11 August 2014 (UTC)

It is promising but there is no actual release at the moment. 93.222.146.1 (talk) 11:47, 15 August 2014 (UTC)

Release is available now 84.171.122.97 (talk) 00:05, 17 August 2014 (UTC)

Add Maiken
Cross platform YAML based build tool for C/C++/Obj-C/C#/CUDA/opencl. https://github.com/mkn/mkn • Edit made by Maiken author 10:28, 18 November 2015 (UTC)

C# Make (Cake)
Is there any particular reason Cake isn't on the list? http://cakebuild.net/ — Preceding unsigned comment added by Icecream-burglar (talk • contribs) 07:22, 24 January 2017 (UTC)

Add SnakeMake
Tedtoal (talk) 18:30, 12 May 2017 (UTC)

Who is this article useful for?
What is the point of this article? It tells the reader that there are about 40 different build tools. How does this help anybody? It might be useful to explain why projects using some combinations of programming languages can't be built using the old standard tools like make. It might also be useful to state, for each build tool, what kinds of projects it can build efficiently. Longitude2 (talk) 13:52, 20 March 2020 (UTC)

No red links policy
Curious why the article policy for no red links? Red links are reasonably common in list articles. Is there some quality of software build tools that makes red links undesirable? If so, what is it? Brycehughes (talk) 01:31, 19 August 2020 (UTC)
 * I recently did this to try to raise the bar on quality by listing only items with Wikipedia articles. From WP:CSC, this is effectively "Every entry meets the notability criteria", where red-linked entries can be added if "it is reasonable to expect an article could be forthcoming in the future." However, I generally don't see software-related red links turn into Wikipedia articles, so I'm generally inclined to remove these types of list entries to favour content with Wikipedia articles to provide more detail. So if you want to add a new entry in this list, you may need to write the article first. Is this too restrictive? + m t  09:44, 19 August 2020 (UTC)
 * In this specific case, I think it is too restrictive. In general, I lean more towards your end of things; cluttered/spammy/crufty lists really annoy me. I appreciate the clean up you did on this article previously, which was needed. However, certain lists are more prone to higher rates of crap accumulation, and I don't think a list software build tools—arguable one of the least exciting areas of software development and thus one of the least likely to garner articles—is one of them. In this case, I think a blanket no-red-links policy is too restrictive, and instead new entries should be evaluated on a case-by-case basis. I.e. for software build tools, we should be aiming for merely the third criterion of WP:CSC, reasonably vetted. What do you think? Brycehughes (talk) 12:00, 19 August 2020 (UTC)
 * It's much easier to enforce a no-red-links policy, because it's difficult to evaluate each entry's notability. There are other places on the internet for complete lists of automation software (e.g. this from a quick search), but this is an encyclopedia list article that should ideally be built on content from other articles that have established notability. But in balance, if it helps readers find what they need, then case-by-case evaluation of some entries may need to done here. Would that just be an inline comment, or a discussion on the Talk page? + m t  20:52, 24 August 2020 (UTC)
 * It sounds like you would like a rubric for evaluating each entry in the list. I'm not sure there could be a clear one, although I think a no-red-links policy renders the list unhelpful, no better than a disambiguation page, essentially an index of build tool articles that just happen to be written. Take the entry I added, for example, which prompted your initial revert. The Scala language has long been dominated by a bit of a dinosaur (in my opinion) build tool called SBT. Recently a newer build tool called Mill has been gaining in popularity, and is now supported by major IDEs (IntelliJ, VS, etc.). While I don't believe Mill yet deserves its own Wikipedia article (it may, but I can't be bothered researching it—it's a build tool), I do believe that it belongs on this list, as it is helpful for the sort of reader that reads these lists to know that there is an alternative, fully-supported build tool out there for Scala. Now, I struggle to think of a counter example—that is, a build tool that certainly should not be included on this list—perhaps you've come across one in your pruning? I know that if I were to suddenly whip up a build tool (ha) and then push it to Github, it would be wrong for me to then go ahead and include it on this list. There needs to be some measure of popularity/usage at least, but I'm not sure where we'd find that measure. If you look at the Github repository for Mill, you can see that it is rather popular for Scala (remember this is Scala, naturally a bit more niche, not a widespread language like Java or Python, so we'd need to control for that). My personal preference is just to use editorial judgement for each entry—you know it when you see it—but if we can come up with a rubric, then that's fine also. Brycehughes (talk) 01:57, 26 August 2020 (UTC)

JetBrains Space Edit Request
Message:

Hello, my name is Alyona Chernyaeva and I’m an employee of JetBrains. I work in the JetBrains Space team as a marketing specialist. We are reviewing Wikipedia articles that relate to our areas and would like our product to be listed in the article. Please review the description below and let me know if it is acceptable to you. Thank you very much for your consideration.

'''Continuous integration '''

JetBrains Space, (Space Automation), a continuous delivery service along with a solution for a broad spectrum of automation tasks.

Alyona na (talk) 18:44, 24 March 2022 (UTC)


 * ❌. This article lists software that already has an article. An article about the developer is not the same thing. - MrOllie (talk) 14:14, 1 April 2022 (UTC)

a-a-p link
a-a-p link lead to Bram Moolenaar page, not to the tool page. XP_2600 (talk) 09:30, 22 October 2023 (UTC)