From: Seebs on
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
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
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
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.

--
┌─── dg@cowlark.com ───── 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
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.