Talk:Make (software)

utilize users comment

how wikipedia utilize users comment —Preceding unsigned comment added by 76.210.239.112 (talk) 20:11, 23 April 2009 (UTC)

what about

what about Make Magazine? Brewthatistrue 23:47, 22 July 2005 (UTC)

Weird sentence

What's going on with "It uses files called "makefiles" to determine the dependency graph for a given output, and the build scripts which need passed to the shell to build them."? mat_x 16:31, 9 September 2005 (UTC)

You're right that it's awkward, but it's actually a fair description of the process. It processes the makefile. It has a series of depedency graphs. For a given target, it looks at all the dependencies, and will run the build scripts for anything which needs built (or re-built) in the process. --Flata 10:32, 15 September 2005 (UTC)

It's a fair description of what the make program does, but not a fair description of how a person learns to get make to do that. From the human's point of view, he or she edits a Makefile to define which output files depend on (i.e., come from) which source files. The human doesn't have to care about the dependency graph which make generates to guide its own approach to checking the dependencies. The human only has to care about defining the dependencies correctly in the Makefile, using the appropriate syntax. The article should distinguish between the internal operation of make, which is of interest to the few people who maintain the make program itself, vs. how the vast majority of users will approach the use of make. I.e., I suggest putting the internal operation stuff in its own section, so as not to confuse people who only want to use the program. That is, an abstract internal concept like "dependency graph" should not be in the introduction section. The introduction should introduce make: here is what it does from the user's point of view, why you might want to use it, and how you approach using it. Teratornis 18:47, 2 June 2006 (UTC)

Be bold and do it. 201.47.46.16 21:35, 27 December 2006 (UTC)

Capitalization

I don't necessarily agree with the "incorrecttitle" in this case. For documenting the command, as typed into the command line, yes it's "make" but the program itself is called Make. I don't have PWB sources on-hand anymore, but in the makefile for V7 Make, it says "# Description file for the Make command". In the fatal() routine, it prints its identifier as "Make". The de Boor make, as it appears in FreeBSD 6, prints "make" in the equivalent Punt() routine, for what it's worth. --Flata 10:39, 15 September 2005 (UTC)

Layman explanations please!

Could someone familiar with this subject please re-write the article in such a way that regular readers can understand the basic concept of it? I'm fairly computer literate, but understand hardly anything of the article, except that we're talking about very specific types of file conversions (this is not about converting a Word file to a TXT file, right?). You won't even know that the article is about computing until you have read several sentences. Thomas Blomberg 10:18, 26 April 2006 (UTC)

make can handle any kinds of files — as long as you've got a standalone program capable of doing the conversion e.g. doc2txt.exe if such a thing exists. (In other words, make is not a "GUI runner", although there are probably versions that can do that too.) For example: you save your Word document as a new file (or overwrite an old file); then you run make which notices there's a new Word document and runs the conversion program to create (or update) the TXT version of the file. Ewlyahoocom 11:11, 26 April 2006 (UTC)

What I meant is that the article should be written in a way that makes the content accessible to non-computer people. Any clarifications should be in the article, not on the talk page. And to be quite honest, the answer above didn't make me one bit wiser. Thomas Blomberg 11:21, 1 May 2006 (UTC)

Yes, I agree that the article should be edited. And while I appreciate your frankness, I assure you it's unnecessary -- it is the reason why I did not attempt to edit the article. Ewlyahoocom 14:52, 1 May 2006 (UTC)

The introduction needs work if a general audience is to understand it. The first several sentences presume the reader has a computer science background. However, someone who has never used make before may have no idea how the vaguely general concepts alluded to in the jargon terms apply to anything specific, nor why someone would need to "automate the process of converting files from one form to another."

• A typical computer user may be familiar with one-off manual file conversions (such as converting a Word .doc file to .txt or .html), but will have no personal experience with projects consisting of several or many source files which a developer (e.g., a programmer, documenter, system designer) edits manually (often in small steps), and then repeatedly compiles and possibly links into some sort of output file or files (e.g., a program, or a document in various output formats as from DocBook, etc.). In other words, the article makes (no pun intended) no sense to someone unfamiliar with using programming software in an edit-compile-run/examine-debug cycle.
• Many computer users will be familiar with GUIs only, and may have barely or never seen a command line interface. make in its classic form requires the "external programs" to be executable from the command line. A reader who doesn't understand this will be further confused.
• The introduction could introduce dependency more clearly, as it applies to make, and what about the whole point of dependency checking: efficiency. The simplest approach is to re-compile every source file in a project, for example with a batch file, but that might waste time re-compiling files that don't need it. The article linked to makes matters worse by mentioning many aspects of dependency irrelevant to make. The concept to get across is reasonably simple: in most cases, a developer edits a source file of some sort, and then it is newer than one or more output files that depend on it (those output files being left over from a previous run of make). The developer runs make, which examines the output files, determines which are older than any of the source files they depend on, and then calls the appropriate command-line programs to generate new copies of the output files from the source files.
• The introduction assumes the reader understands the concept of a file's modification time. It would be nice to link to an appropriate article explaining the concept, but Wikipedia seems not to have one at the moment. The closest I see is the article on touch.
• The article has too many verbs in the passive voice, creating ambiguity as to the various actors (the developer (a human), the various programs that run and do things). The description in places tends to invert the natural order of concept assimilation. I.e., it reads as now-we-understand-it rather than here-is-how-to-understand-it.

The introduction would benefit from linking explicitly to more of the topics which give clues as to who uses make, and why they use it. It should mention some essential concepts such as the command line interface, and the repetitive edit-compile-run-debug cycle of software development. The IDE article contrasts itself to make, and the make article could contrast itself conversely. It wouldn't hurt to mention why we use make instead of the simple brute-force re-compile-everything method. I don't see a suitable article which defines the concept of a "project" as we would use the term here. The natural use of make is in the context of some sort of software project: a collection of source files a human edits, and then converts into other kinds of files with utility programs.

I'll make a note to look at editing the article a bit. But I wanted to mention here what I think the article needs before I go hacking at it. Teratornis 18:35, 2 June 2006 (UTC)

OK, I completely rewrote the lead, and it should be quite a bit clearer now. Redquark 17:12, 16 October 2006 (UTC)

I suggest clarifying the concept of dependency even more. 69.251.180.224 (talk) 01:55, 1 September 2010 (UTC)

What about test and install

It would be complete if the article covers "make test" and "make install"

Tale of design mistake lock in?

My fuzzy recollection is Feldman wrote something describing how he quickly (weeks?) concluded that using significant tabs had been a mistake. But how at that point, he had too many users, order 10?, to change it. Now, order 10_000+ users later... It's a cautionary tale for any protocol designer. And I'd really love to find a reference. 66.30.119.55 19:42, 6 July 2006 (UTC)

Cross-posted on Talk:Make and Talk:Stuart Feldman.

The anecdote in question appears in Eric S. Raymond's The Art of Unix Programming, Chapter 15, section 4. FAQS.org has the full text:

No discussion of make(1) would be complete without an acknowledgment that it includes one of the worst design botches in the history of Unix. The use of tab characters as a required leader for command lines associated with a production means that the interpretation of a makefile can change drastically on the basis of invisible differences in whitespace.

Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history.

-- Stuart Feldman

I suspect that the best way to handle this might be to put this quotation in Wikiquote and refer to it from the main article.

MarkKriegsman 15:04, 14 May 2007 (UTC)

I agree, it would enhance the article significantly. Donal Fellows (talk) 14:42, 29 August 2008 (UTC)

Usual Wikipædia quality

“The make identifies and runs the programs which are necessary to convert the files (these programs are called dependencies).” This sentence is complete garbage---it implies that “the make” (“the make utility”, perhaps?) works out that, for example, gcc is needed, and runs it; where gcc itself is dubbed a dependancy. This is clearly false, as i) make must have transformation rules explicitly provided to it (even if they are global), and ii) the dependency is this case is the source file (which is a dependency of the required object file).

So fix it, the "usual Wikipedia" way :) Stevage 02:26, 14 November 2006 (UTC)

"and source files are marked as depending on files which they include internally." is also incorrect; it is a common beginner's mistake though. To use the context of compiling a C program, the *object* file depends on the include files, not the *source* files. That is because the object file will change if you change the include file. -- 213.84.74.36 (talk) 20:22, 12 October 2008 (UTC)

makepp?

Why is makepp listed as one of three modern noteworthy make variants? It looks like a vanity edit, and a Google Groups search indicates that few people use it. Plus, Debian Linux doesn't carry it. How about mentioning Microsoft's nmake instead? JöG 20:13, 28 September 2006 (UTC)

Hash?

"# Comments use the pound sign (aka hash)" - is this some really weird C term, or does the author really not know what the pound sign is?

The # symbol is called 'pound' in the US, this is different from the UK Pound symbol £. the term 'hash' is normally used in C/C++ for # as it is generally internationalised, and can be pronounced well "hash-include", "hash-define", etc.

the # is also sometimes called a sharp (like in music), at the top of a script you will find the `shebang` - abbreviation for 'sharp','bang' e.g. #!/bin/bash. Obviously, the exclamation point is the bang, but perhaps people outside of the unix comminity will look at you funny if you start calling them 'bang', say out loud at work. (P.S. if you did have to read scripts out loud, or speak of them, then sharp and bang are less cumbersome than `pound sign` and `exclamation point`, not to mention they confer the purpose of these symbols. Amarok1234 (talk) 15:53, 23 May 2008 (UTC)

Makefiles obsolete?

There's a couple of comments that makefiles are obsolete, replaced by IDEs. I disagree. makefiles, especially gnu make, is ubiquitous in the unix world; it is what every C/C++ project tends to have. The makefile may have been generated by other tools such as automake, but its still there. Furthermore, the are many other text file driven build tools including Ant,Nant,Phing,MSBuild,Rake (Ruby). Many IDEs integrate with these tools (Ant is supported in all Java IDEs, MSBuild is generated by Visual Studio, but the tools and the concepts all depend on Make, and all allow skilled developers to edit the files by hand

It is possible to saw a word about the mak format (invention of the men of wxwidget) ? This format is a scripted Makefile capable to adapt the content and syntax to the material/software. Sure it's not so great than Bjam... but it's allways better than simple makefiles. With it you can compile on linux and windows (Visual) without any adpatation. (it's a sort of adaptative makefile). It generates makefiles. —Preceding unsigned comment added by 81.80.168.101 (talk) 09:21, 13 June 2008 (UTC)

Link to remake page

I dropped the link to remake because it deals with remake in films industry... Tiksagol 05:15, 6 September 2007 (UTC)

Toaster not broken, it needs to be plugged in

There is a section on advantages and disadvantages:

Make is a component in a system, and part of the unix philosophy is focus and simplicity. You combine several components together to achieve an objective, and each of those components is optimized to play just one role (the whole is much greater than the sum of its parts).

To say that a disadvantage of make is that it lacks the features of an other component (e.g. Automake) is akin to saying one of the disadvantages of a wheel is that the user has to hold it up and roll it. However, the wheel is just a component, and in conjunction with the axle &c, performs admirably. In fact, the wheel has the luxury of just focusing on being a very good wheel.

The advantages and disadvantages section speaks only of disadvantages. Jhobson1 (talk) 19:43, 21 November 2008 (UTC)

You're right. I'll make an attempt to rewrite parts of it showing both sides. Then there's the next question: advantages and disadvantages compared to what? JöG (talk) 20:21, 13 May 2009 (UTC)

OK, I did some rewriting. Added one of the worst problems, too – relying on time stamps reflecting file change. Can someone comment please on whether any other build tool has succeeded with some other technique? Checksums? JöG (talk) 21:20, 13 May 2009 (UTC)

Topological sorting

I tried to insert a note about how the build process is derived (i.e., through topological sorting). Maybe this should be placed in its own, short section, instead of in the summary? --cslarsen (talk) 13:01, 6 November 2008 (UTC)

Poor wording

The first sentence is poorly worded, in particular the phrase "automatically builds". I followed the link to the article on both words and both describe esentially the same thing. I find this confusing. --User:Josh 13:25, 14 October 2010 (UTC) —Preceding unsigned comment added by 207.194.62.58 (talk)

I changed that to a single link. Didn't try to fix the wording though. --Kvng (talk) 18:16, 16 February 2011 (UTC)

Suffix rules considered obsolete in GNU Make

I'm not sure about BSD Make or the POSIX specification but suffix rules have been obsolete for quite a while in GNU Make. They have been replaced by the more general and flexible pattern matching rules.

http://www.gnu.org/software/make/manual/html_node/Suffix-Rules.html

The article seems to have a disproportionate amount of information about suffix rules and only a few minor mentions of pattern matching rules.

I don't have the time to update the article right now but I just thought I'd add a note here.