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)

I added link to the Dependency graph page to the bottom of the "See also" section. See the talk of the Dependency graph page RippleSax (talk) 10:09, 10 January 2016 (UTC)

About the modification time. Just read the article Stat_(system_call) --84.158.127.69 (talk) 13:29, 13 October 2021 (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. — Preceding unsigned comment added by 81.157.211.54 (talk) 03:26, 26 May 2012 (UTC)

Well... the article is about "make" in general, not GNU make in specific. And yes, pattern matching rules are a GNU extension. -- DevSolar (talk) 11:32, 11 June 2012 (UTC)

Wrong: Pattern matching rules is a SunPro-Make extension from 1986 that has later been reimplemented by gmake. --Schily (talk) 16:33, 11 June 2012 (UTC)

FreeBSD make also has them. I think it's fair to say that over 99% of Makefiles written today can use pattern rules. But how to decide which features of which versions of make to cover here? Rp (talk) 09:56, 12 June 2012 (UTC)

External links

The page version at the beginning of 2012 had a long list of extarnal links (all of which were in fact live). On Jan 25 most of these were removed by "Thumperward", with an explanation referring to Wikipedia rules on external links that say among other things "it is not Wikipedia's purpose to include a lengthy or comprehensive list of external links related to each topic". Fine, except that the links that were removed were, a little randomly, all but the 10 last links. I have now cut down the list of links to three (after looking briefly at all the links in the long list). However, as there is now a wikibook that is linked to in the Wikipedia article, I have moved many of the links to there. Kristjan.Jonasson (talk) 15:55, 15 December 2012 (UTC)

I made a look at the links you removed and they seem to contain valuable information. Having a wikibook is not an excuse to remove this links. Sorry to say, but I don't consider your removal helpful. For that reason I decided to revert it. Georg Peter (talk) 13:11, 28 December 2012 (UTC)

Initial release year

Please check out file: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/make/ident.c which may help to correct date: base version of `make' was 24 april 1976 — Preceding unsigned comment added by 46.146.234.112 (talk) 02:52, 14 February 2013 (UTC)

False claims about pattern rules and advertizing for GNU make

The recent edits for pattern rules are not acceptable for WP as they are false with respect to obsolescense and because the contain advertizing for GNU make that tries to create the impression, pattern rules are a GNU make invention.

Correct is my version of the text. but this has been revertey by a person that seems to miss the related knowledge about make.

Let me repeat: Pattern rules have been introduced by SunPro make in Spring 1986 (see man pages for SunOS-3.0) and a make program that uses pattern rules for the built in rules is broken. Schily (talk) 21:38, 11 May 2014 (UTC)

Schily, I have removed the words "obsolete" and "introduce" from that sentence, I hope that it no longer "contains advertizing and tries to create the impression". You can add yourself your reference to whoever was first to use pattern rules, however I personally believe it is not terribly important. Hope you are satisfied now, Bakkedal (talk) 23:09, 11 May 2014 (UTC)

This makes the text less unbalanced. The problem is that the current text still does not mention that pattern rules are not in POSIX and that the current text does not mention the origin. I of course can verify that SunPro Make introduced pattern rules in spring 1986 by reading the SunOS-3.0 man pages and i know of no prior art (gmake first appeared in 1988, so gmake definitely did notinvent it). But these man pages seem not to be online. Mr. Dickey may not know the WP rules, as he removed a sourced statement - a source does not needed to be available on-line...and Mr. Dickey seems to be an unfriendly editor as he simply removed a correct statement instead of asking on the talk page. Schily (talk) 15:24, 12 May 2014 (UTC)

I agree with your version, except that mentioning a version of make from 1986 while removing the name of GNU make seems unbalanced; I'd guess that 99,9% of the Makefiles written today are written for GNU Make, so mentioning it in this article is not a matter of advertising, but of relevance. Rp (talk) 09:02, 16 May 2014 (UTC)

SunPro make was the first make implementation with general availability that introduced many new features in 1986 that influenced other make implementations. SunPro make is needed to compile OpenSolaris, so it cannot be called petty. SunPro make now is OpenSource and still offers features that are not available by other make programs (such as automated integrated include file dependencies and linker dependencies).

With respect to pattern rules, GNU make now is not the only make implementation besides SunPro make that supports them. GNU make may be the first implementation after SunPro make, as it started in 1988 with pattern rule support, but since 1996 smake also supports pattern rules. Even though smake is OpenSource, smake is older than GNU make and usable on many more different target platforms than GNU make, smake is not even mentioned in this article. Well, AFAIR there was some related text in previous versions of the article, but some people removed this. I have no problems with mentioning GNU make as one implementation that supports pattern rules, if we could agree on a more generalized text in the article, that e.g. mentions SunPro make and smake in an encyclopedic way, correctly mentions David Korns nmake (and that it is older than what Microsoft names nmake) and by putting warnings to GNUisms in examplex in the article if they depend on features that are not supported by POSIX. Schily (talk) 10:00, 16 May 2014 (UTC)

Explaining why the claims on Pattern Matching Rules in the article have been wrong

Pattern matching rules are searched first (before looking for Suffix Rules that might match a given suffix) in the order of the respective definition of the Pattern Matching Rules. Thus, if a make implementation would try to define it's built-in rules using Pattern Matching Rules, these built-in rules could not be redefined later in the users makefile. This is because the built-in rules are read before any makefiles from the user. Pattern Mathing Rules withing the built-in rules would become the first and thus dominating definition.

Gmake did try this a few years ago and failed miserably with many makefiles out in the public that assume that defining a Suffix Rule for given target groups would be honored.

For this reason, Pattern Matching Rules are a nice and powerful enhancement to the inference rules in make, but can never completely replace Suffix Rules. I hope this prevents people that are not familiar with make to again add a related false claim in the main article that I just removed for good reasons. Schily (talk) 10:34, 28 May 2014 (UTC)

Schily, I am sorry to tell you that, but you are not helpful at all. You delete valuable information originating from verifiable sources (e.g. GNU make manual) on the ground that you personally have some original ideas about makefiles (and apparently a personal vendetta against GNU make). For example, you claim that pattern rules "can never completely replace suffix rules". Could you please prove your point by a concrete example (or a reference)? Otherwise (and sorry in advance) I will have to delete your edits. Bakkedal (talk) 14:55, 28 May 2014 (UTC)

I am sorry to see that you reinserted text that is not helping people because it contains wrong meta information. If you don't understand my text above, you are obviously unable to understand how make works, as my text from above of course explains why Pattern Rules cannot replace Suffix Rules. Hint: the precedence rules that make the first pattern rule dominant and not replacable later are the reason... Schily (talk) 15:10, 28 May 2014 (UTC)

Pattern rules

My recent edits have been done with care. They correct false claims and give references for the correct behavior - e.g. the fact that a % matches zero or more characters in a pattern rule. Please be collaborative and do not reinsert false claims. Read the man page to verify that I am correct. Schily (talk) 15:19, 28 May 2014 (UTC)

From the man page:

Pattern Matching Rules
    A target entry of the form:

      tp%ts:dp%ds
          rule

    is a pattern matching rule, in which tp is a target  prefix,
    ts  is a target suffix, dp is a dependency prefix, and ds is
    a dependency suffix (any of which can be null). The % stands
    for a basename of zero or more characters that is matched in
    the target, and is used to construct the name  of  a  depen-
    dency.  When  make  encounters  a match in its search for an

Schily (talk) 15:28, 28 May 2014 (UTC)

Most of your edits today are based on a false premise (the others, as usual, are "merely" unsourced). The false premise is that "pattern rules" are a standardized term, and that accordingly you are free to apply any source you choose to demonstrating that your opinion is well founded. A close reading of the topic should have cautioned you that it is based on GNU make, that that "pattern rules" description is that of GNU make - and that a loose reading to equate it with a related topic "Pattern matching" will only make matters worse. TEDickey (talk) 19:19, 28 May 2014 (UTC)

Last time I tried Sun make and FreeBSD make, which is 10-15 years ago, they both had pattern rules and called them "pattern rules", so neither their existence nor their name are specific to GNU make. Rp (talk) 19:05, 1 June 2014 (UTC)

As verified before, Sun make introduced pattern rules in Summer 1986 (as I know of no other implementation that came up with this feature earlier, I assume that Sun make was the first to support pattern rules), while gmake was first published in 1988. It is obvious that gmake is not the inventor of this feature and people who know UNIX for a longer time know that in the 1980s, it was extremely important for the g* utilities to be as compatible as possible to the market leader (SunOS). The false interpretations from Mr. Dickey are irrelevant. There was no claim that pattern rules are part of the standard, but as gmake reimplemented a Sun-Pro make feature, we can safely assume that its intention is to be compatible. More important for an encyclopedia however is: mentioning gmake in relation to pattern rules can be seen as unwanted advertizing. Schily (talk) 15:13, 3 June 2014 (UTC)

There was no "verified before". So far, you have not provided any reliable source to discuss. In particular, none of your recent comments can be verified, and your assumptions (which you appear to be using in lieu of reliable sources) can be disregarded TEDickey (talk) 18:38, 3 June 2014 (UTC)

If you carefully read the pointer you provided, you should be able to understand that your claim is not correct.

The SunOS-3.2 man pages have been published by a reliable entity and they are archived, so they perfectly match the requirements for reliable sources. There is no need for a source to be available online. Schily (talk) 12:34, 4 June 2014 (UTC)

Since the information that you want to use the putative source for is unlikely to be in the source, it's necessary to demonstrate that. TEDickey (talk) 22:09, 4 June 2014 (UTC)

??? Just get a SunOS-3.2 make man page and read it.... Schily (talk) 08:33, 5 June 2014 (UTC)

hmm - where do you suppose one might get a copy of something that went end-of-life 25 years ago? TEDickey (talk) 19:26, 5 June 2014 (UTC)

It may be somewhere in the net, it is on one of the SunOS install tapes I have at home and it is in the Sun SCCS source history. Schily (talk) 12:12, 6 June 2014 (UTC)

That sounds like a nice research topic for someone to find sources and "prove" who did what first, but is getting away from the verifiability that I'm requesting. TEDickey (talk) 20:53, 6 June 2014 (UTC)

You seem to missunderstand how things work...

• SunPro Make introduced pattern rules in Summer 1986 - this is sourced with credible pointers (e.g. the man page from Summer 1986). It may be that there is another program that might have introduced this feature earlier, but it this is true, we just have to wait for someone to present a credible pointer. As long as nobody claims that SunPro make invented this feature, nothing is wrong here. As gmake implemented the feature much later, gmake is not expected to be mentioned in an encyclopedic article.
• This is like the invention of the computer. In former times, US scientists claimed the computer was a US invention even though we all know that Konrad Zuse build the first programmable mechanical computer in 1936 and the first electrical computer in 1941. It took some time until the least one accepeted Konrad Zuse, but it happened.
• Netapp still claims they invented the first Copy on Write Filesystem even though they know that they stole the basic ideas from my diploma thesis. All patent claims they presented in their legal attacks against Sun/ZFS, have been invalid as they filed their patent claims in 1993 but these claims are nearly identical to what I invented in 1988 and published in 1991.

Not to forget: If we did use your definitions of a reliable source, we would need to remove more than 50% of the text related to GNU utilities. Is this your intention? Schily (talk) 13:32, 11 June 2014 (UTC)

hmm - not much worth responding to, since you use personal attacks in lieu of civil discussion. I notice that each time, you elaborate with yet another unsourced comment. TEDickey (talk) 19:09, 11 June 2014 (UTC)

Without a verifiable source, all of these comments about theft can only be regarded as hostile - whether they're topical or not TEDickey (talk) 19:29, 11 June 2014 (UTC)

I am not amused to see that you again come up with a false claim of an alleged personal attack. Let me help you to understand: Describing the behavior of another person is not a personal attack. Your behavior cannot be seen as friendly as you apply a double standard where you add unverified text to your puppet projects while (with regards to other articles) at the same claiming that WP requires on-line verificataions for every statement (which does not meet the real WP rules). As said before: we have a verifiable source already, the SunOS-3.2 man pages, they meet all WP requirements of a reliable source. Schily (talk) 09:07, 12 June 2014 (UTC)

If you're the only person with a copy, it's not verifiable. By the way, in an earlier comment, you asserted that your source is "archived". Where's the archive? TEDickey (talk) 19:50, 12 June 2014 (UTC)

Not every person here is a UNIX novice, so there is if course a big chance that there are other people with a copy. As mentioned earlyer, the related text is archived in the Sun SCCS that is now expected to exist inside Oracle. The license of the related text is that you may use it when you bought a Sun license that was delivered together with a Sun machine. This is similar to when you buy a book and there are plenty of pointers to books in the WP. While an ISBN is a unique method to identify a book, "the SunOS-3.2 man pages" is a unique method to identify a specific version of the SunOS man pages. If you like to verify a pointer inside a book, you need to find a way to get access to that book, if you like to verify a pointer in the SunOS-3.2 man pages, you need to find a way to get access to that man pages. If you like to verify that I published the idea and implementation of a Copy-on-Write filesystem years before Netapp, you need to ask the Technical University of Berlin for my Diploma Thesis, because only they can verify you that it was publshed in May 1991. So what? Schily (talk) 10:04, 13 June 2014 (UTC)

Frankly, I'm not sure what this argument is about. Isn't there a wording you can both agree on? It seems pattern rules have been implemented multiple times and the details of the semantics probably vary. Why not use this as a source? Rp (talk) 13:18, 13 June 2014 (UTC)

Great catch! Unfortunately, this is only a year before SunOS-3.2, so I would assume that there was a related published paper that predated both implementations. In any case, you verified my claim that if there is something older, someone will find it and report, so it seems to be safe to mention the oldest known implementation and to wait for corrections. Schily (talk) 13:58, 13 June 2014 (UTC)

If you like to know the reason for the dispute, this is different... Mr Dickey has a special interpretation of reliable sources. It seems that every source not introduced by him is called unrelibale regardless of it's quality. There are many similar disputes with him, so this is a general problem. If someone is willing to come to Berlin and spend me a beer, I am of course able to verify that SunPro make from 1986 was a rewrite of the original make sources and everybody who cares about the background can download the current SunPro make sources from the location I mentioned to see that this is another rewrite, as it is now written in C++. So the "doubious" labels introduced by Mr. Dickey cannot be seen as good faith edits. Schily (talk) 14:11, 13 June 2014 (UTC)

I see that you confirm my comment on each edit. By the way, the "earlier paper" would be the discussion of augmake (which is surprising that you did not mention it before, since it lies within the scope of your claimed expertise). There are several sources dating from 1983. I would have mentioned this before, but you were intent on accusing others of theft and lying, so until RP came back to the thread, there was no one to talk to. Have a nice day. TEDickey (talk) 20:07, 13 June 2014 (UTC)

I am not sure why you again start personal attacks and what you like to tell me here.

I was always interested in getting correct descriptions into the article, while it seems that you tried to bend reality in order to promote gmake.

BTW: Do not request things from others that you in your own edits do not abide. Do well-meant balanced edits only and assume well-meant edits from others as long as this is possible. Your messages typically look as if they have been written by a UNIX novice with few or no knowledge on what happened before y2000. If this is not true, try not to behave as a UNIX novice and you will cause much less disputes on WP than before. Schily (talk) 14:16, 16 June 2014 (UTC)

Let me guess. Now please take the personal comments elsewhere. Thanks. Rp (talk) 15:20, 16 June 2014 (UTC)

Just in case you did not notice: It is not me who repeatedly starts personal attacks. I have no interest in this kind of disputes, but I get involved by him. Maybe I should completely ignore him to avoid such disputes. Schily (talk) 15:56, 16 June 2014 (UTC)

needed to compile OpenSolaris?

The given source flatly contradicts that statement by providing Sparc and x86 executables. Likewise, the source does not provide reliable information regarding when the license change occurred and when the sources were made available. For the latter, there may be a WP:RS. TEDickey (talk) 19:36, 28 May 2014 (UTC)

SunPro considered as a rewrite

Referring to this:

<!-- the first version was a C based rewrite from the original UNIX make
 sources that mostly used the historical file names and included comments that
 point to SVr2 sources, recent versions are another rewrite, now in C++ -->

the appropriate place to discuss maintenance issues is on the talk page -- not to add still further unsourced opinion. The current issues, adding this comment to the list:

• SunPro is presented as a "rewrite". In English, a "rewrite" has a specific meaning, encompassing both change of design and change of the form of expression. A WP:RS is needed to show what that means.
• The comment asserts some specific knowledge of SunPro's source code. That's unsourced.
• The comment asserts that "recent versions" again are known in detail. That's unsourced.

Lacking reliable source for the first, the entire comment can be removed. TEDickey (talk) 19:47, 28 May 2014 (UTC)

That is precisely why it was a comment until someone could find and provide such references. It provided potentially useful information when looking to provide references on the subject but should not be part of the main text until it can be adequately sourced. Comments are meant to be communication only to other editors. See MOS:COMMENT. 50.53.1.33 (talk) 14:29, 6 March 2017 (UTC)

BTW: an expert of course can fetch a historic make source from Stuart Feldman (via the historical UNIX license) and the current SunPro source (via the OpenSolaris license), compare them and verify that the latter is a rewrite. It may be harder to get the Sunos-3.5 source to compare with the first SunPro make version. Schily (talk) 15:50, 6 March 2017 (UTC)

dmake promotional edits

None of the existing links near the edit give corresponding information. If you would like to discuss sources, you could start by providing one that has the information for these edits TEDickey (talk) 14:53, 5 May 2017 (UTC)

If you miss the skills to read sourcecode, you are not the right person to edit this text. Please stop your promotional edits and your edit wars. Schily (talk) 15:20, 5 May 2017 (UTC)

We're looking for quotes, not debuggers. Try that, rather than demonstrating your personality. TEDickey (talk) 20:11, 5 May 2017 (UTC)

Why do you use the majestatis pluralis? It is only you who tries to edit this article even though you miss the needed skills. But thank you for confirming that this was no more than your typical behavior and you have no sustainable argument why you removed a verified and verifiable fact. Schily (talk) 09:45, 8 May 2017 (UTC)

Where are your facts? You haven't presented any. Have you any facts? TEDickey (talk) 20:58, 8 May 2017 (UTC)

You behave as usual: you start an edit war based on false claims, so you are again violating WP rules.

• The facts, you claim to miss, are in the citations mentioned in the article, if you miss the skills to understand them or if you are too lazy to read them, you should stop editing WP articles.

• If you are willing and able to read and to understand a C++ source, you of course did see, that the SunPro Make source published by Sun contains a lot of #ifdef'd code that refers to features not available in the /usr/ccs/bin/make binary on SunOS, but in /opt/SUNWspro/bin/dmake. There are even OSS projects that activated some of the documented and verifiable "dmake"-features (missing in /usr/ccs/bin/make from Sun) because not all of the dmake features are implemented in Closed Source libraries (not published by Sun). What is missing is mainly the libraries that implement the remote execution via a special "rsh" lib or the Sun grid engine. In other words OSS versions of SunPro Make currently cannot add the distributed execution of parallel jobs but they can enable the existing code for parallel execution on the same machine.

• The text you removed against WP rules is definitely well sourced, q.e.d. Schily (talk) 10:36, 9 May 2017 (UTC)

What you're attempting to do is called original research. That in itself is not permitted. But since you're going past what's actually there no one would dignify the effort by the name "research", but more like creative writing. Stick to the documentation and (though there's little of good quality to work with), you'll stay within the guidelines TEDickey (talk) 00:16, 10 May 2017 (UTC)

research is the deduction of non-obvious facts from other facts. Given that the code to enable most features from the "dmake" program is available is in the OSS code, this is an obvious fact and thus not original research. You should stop your anti-OSS activities and become collaborative instead of repeatedly trying to prevent verified facts from appearing at WP. I also wish that you did limit your activities on WP to areas where your skills are sufficient. Schily (talk) 13:07, 10 May 2017 (UTC)

This is Wikipedia, not your place to make definitions, and your (self-serving) redefinition doesn't come close. Sometime you might get around to reading the guidelines. I've reminded you more than once. TEDickey (talk) 01:14, 11 May 2017 (UTC)

This is Wikipedia, not your private shop. In special, this is not a platform to support your private anti-OSS campaign. So far, you have not been able to give any useful argument to support your wishes. So become reasonable or stay quiet. Schily (talk) 12:14, 11 May 2017 (UTC)

Reminding again, these are a few of the guidelines which you ignore: WP:FRINGE, WP:SYNTH, WP:OR, WP:CIVIL, and of course WP:COI. TEDickey (talk) 00:56, 12 May 2017 (UTC)

I am still waiting for facts from you. It is obvious that are are unable to verify your false claims. So finally stop your edit war and undo your revert on the article. Schily (talk) 10:01, 12 May 2017 (UTC)

I have added a link to the build instructions of Apache OpenOffice and it requires both dmake and gmake. This demonstrates how biased Schily is against anything GNU. he apparently is on his personal crusade against anything GNU whatever they done to him. Libreoffice is the alive version of Openoffice after the Oracle f_ckup Apache OO is dead and may be retired soon [1]. Libreoffice apparently builds everything with gmake now. As Schily is so eager about naming examples, I also added Firefox... nothing of importance requires dmake or SunPro (which is as dead as Sun [2]) anymore. Even Illumos, the only alive opensolaris, uses GNU GCC. — Preceding unsigned comment added by 77.176.252.171 (talk) 22:14, 12 May 2017 (UTC)

Excessive code snippets make this article cumbersome and overly technical

In reviewing this article, I feel that there are way too many code snippets, making this less an encyclopedia article and more a coding how-to. For example:

Microsoft's NMAKE has predefined rules that can be omitted from these makefiles, e.g. "c.obj $(CC)$(CFLAGS)"

Is there any precedent for this level of extreme intricate detail? As a point of compatrison, I don't see a single line of code in the Wikipedia article. TimTempleton ^{(talk) (cont)} 23:08, 23 October 2017 (UTC)

what about the algorithm?

Such a long article - but nothing about the algorithmic ideas at the core of Make. The only hint I saw in the text is the sentence

   Make can decide where to start through topological sorting.

It would be great if someone knowledgeable could elaborate this. -- Nsda (talk) —Preceding undated comment added 13:06, 17 April 2018 (UTC)

Proposed merge of Makefile into Make (software)

Covers a lot of the same topics as Make (software). AtlasDuane (talk) 02:56, 19 March 2021 (UTC)

Yes, please! I've been meaning to ask the same thing. Rp (talk) 23:29, 19 March 2021 (UTC)

Makes sense to me. --A D Monroe III^(talk) 03:18, 23 March 2021 (UTC)

Support. Also bear in mind WP:NOTMANUAL, which means there is very little worth keeping in the Makefile article anyway. Adpete (talk) 06:59, 7 April 2021 (UTC)

Done Adpete (talk) 07:11, 7 April 2021 (UTC)

OpenWrt, Buildroot etc. make

These also use make and Makefiles. However, the syntax/structure is completely different from Stuart Feldman's original make described in this Wiki article. Suggest some comment(s)/link(s) are made to OpenWrt's and Buildroot's make, if at least some kind of "see also" reference. 82.21.55.166 (talk) — Preceding undated comment added 12:55, 31 March 2022 (UTC)

Make, C, Unix

I have been part of the software community for fifty years, and I remember something about make that has not been commented upon (or at least I didn't recognize it). Make was part of the C language to build the Unix operating system, and it had the capability to extend the C language with a macro like system that added lexical and syntactic extensions to C. I remember reading code that had been delivered to the military that included some of this sort of C extension and asked the authors how they got the DoD to accept it. Their response was that the make file is part of the C programming environment and therefore this type of language extension was standard C. I do not see anything in this article that could be a C standard extending macro facility. Does anyone remember how this was done? 50.206.176.154 (talk) 23:34, 15 April 2024 (UTC)

You appear to be referring to the C Preprocessor, which has been part of the C toolchain since 1973, but I would be very surprised if at any time it was somehow part of make. Rather, make is a different tool on that chain. Rp (talk) 20:39, 17 April 2024 (UTC)

No. I'm sure it was NOT preprocessor macros. 50.206.176.154 (talk) 17:01, 20 April 2024 (UTC)