system calls
in [Shell]
|
From: Seebs on 25 Mar 2010 20:04 On 2010-03-25, Phred Phungus <Phred(a)example.invalid> wrote: > So I guess I'm to believe there's a make in here: No. > $ cat Make.defines.linux > # Common make definitions, customized for each platform Right. The actual makefile incorporates these definitions in some way. There is not "a make in here". It's just settings. > I ran this and didn't really know what it would do, but I have since > come to realize that it compiled all the .c files in subdirectories into > object files: Pretty much! > [if you do not have the patience to skim or skip through this, I'd > rather that you moved on] It's not a question of patience, but of bandwidth. This "ls *" output does not add any information or utility to the post. > It is absolutely true that I would never have had an executable here > without being informed that I had to link to error.o. I took a second > look at the book and the website, and there was nothing in either. The makefile shows it, but you actually have to read through it some, or just look at the source files. > My question is this. How do I alter this makefile to also compile, > link, and a create an executable for C source in the parent directory? Good question! One way to do that would be to look at the commands that are run when make runs, and see if you can figure out, from what it's already doing, how to do something else. For instance, you might find that something pretty close to: cc -o foo foo.o lib/libapue.a or something similar would combine an object module with the library in question. Of course, I may have the name of the library wrong; you'd have to look at the makefiles to figure that out. But in general, it's surprisingly straightforward. The trick is that you have to look, not for a specific recipe to do a specific thing, but some kind of conception of what the parts of the recipe do. The compiler can, among other things, link multiple hunks of code together. One obvious hunk of code to use would be the library containing the error functions. Another would be the object code you created previously from your source (using cc -c). -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Phred Phungus on 25 Mar 2010 20:29 Lew Pitcher wrote: > Warning: > > Lew Pitcher, who posts to this newsgroup, is a domain thief. > > Read the full story at http://www.lewpitcher.ca > Whatever. -- fred
From: Seebs on 25 Mar 2010 20:48 On 2010-03-26, David Given <dg(a)cowlark.com> wrote: > That's a GNUism, I'm afraid. They don't believe in man pages, only in > texinfo documentation. While I have no problem with texinfo > documentation as is (apart from the command-line texinfo reader itself, > which is appalling), texinfo documentation produces *books*, and as a > result is totally unsuitable for the kind of concise but complete > reference that man pages are normally so good at --- the information's > just not arranged in the right way. I find the fact that they refuse to > provide proper man documentation an utter pain. Seconded. I think it's based on a fundamental misunderstanding about the reason man pages exist. Not all documentation is the same kind of documentation. A while back, I was asked what we needed before we could publish an open source project. One of my answers was: "Man pages." I spent an extra day or so working on the documentation to make sure it was usable before shipping: http://github.com/wrpseudo/pseudo The package doesn't currently install them, but they're there if you need them. ... And I just fixed a formatting bug. > As an aside, make is a pretty ghastly piece of software --- it's grown > and mutated in weird ways for so long the result now no longer resembles > anything like a sensible program. You may wish to bookmark the manual at > http://www.gnu.org/software/make/manual/make.html, although it's not > very easy to find stuff in. It's worth noting that Berkeley make, GNU make, and at least one or two other variants, all have INCOMPATIBLE ways of resolving fundamental things. I've written some fairly crazy GNU make code: $$(foreach i,$$($(1)_LDAT_indexes),@$$(foreach j,$$(wordlist $$(word $$i,$$($(1)_LDAT_starts)),$$(word $$i,$$($(1)_LDAT_ends)),$$($(1)_LDAT_list)),$$(call $(1),$$j) ; )$$(LDAT_nl)) > I got so fed up with it a while back that I actually ended up writing my > own build tool, when facing with a large project that make was > completely failing to handle... (<plug> Prime Mover, > http://primemover.sf.net </plug>). Does it regularly shoot small children? If not, it is probably better than make. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: David Given on 25 Mar 2010 21:15 On 26/03/10 00:48, Seebs wrote: [...] > I've written some fairly crazy GNU make code: > > $$(foreach i,$$($(1)_LDAT_indexes),@$$(foreach j,$$(wordlist $$(word $$i,$$($(1)_LDAT_starts)),$$(word $$i,$$($(1)_LDAT_ends)),$$($(1)_LDAT_list)),$$(call $(1),$$j) ; )$$(LDAT_nl)) I feel your pain. [...] > Does it regularly shoot small children? If not, it is probably better than > make. Well... it *is* evil and twisted. It's Lua-based, but doesn't require you to install a Lua interpreter; it deploys as a self-bootstrapping shell script that invisibly unpacks and compiles the interpreter on demand. Most likely god kills a kitten every time someone runs it, but it *is* effective. You can simply drop the pm executable into a project and distribute and not have to worry about your users having to install stuff (*cough*scons*cough*). Lua's small enough to make this feasible: the whole thing --- Lua interpreter source, Prime Mover script and all --- packs into a single 180kB shell script. But that's really just an implementation detail; I wrote it to support a huge compiler project that wanted to build the same binaries over and over again with slightly different settings, with vast amounts of dynamically generated source (again, produced over and over again with multiple settings). The original build system was a nightmare maze of recursive makefiles and shell scripts building more makefiles, etc. pm deals with this stuff beautifully, and gets all the dependencies right, too. It's not perfect: there are bugs and rough edges, and one major design cockup early on that I'm now not sure how to fix, but it's effective enough that several years on I'm still using it for all my personal projects. Short introduction and example here: http://primemover.sourceforge.net/about.html There's an extensive manual on the website. Er, not in man format. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ } │ --- Conway's Game Of Life, in one line of APL
From: Rainer Weikusat on 26 Mar 2010 08:34
David Given <dg(a)cowlark.com> writes: > On 26/03/10 00:48, Seebs wrote: > [...] >> I've written some fairly crazy GNU make code: >> >> $$(foreach i,$$($(1)_LDAT_indexes),@$$(foreach j,$$(wordlist $$(word $$i,$$($(1)_LDAT_starts)),$$(word $$i,$$($(1)_LDAT_ends)),$$($(1)_LDAT_list)),$$(call $(1),$$j) ; )$$(LDAT_nl)) > > I feel your pain. That some people inevitably reinvent the Gordian knot whenever given enough rope is not something the rope is accountable for. |