On Tue, Jun 27, 2006 at 04:04:05PM -0500, Mike McCarty wrote:
>
> Amusingly, there appeared a message just now over on the Debian Linux
> e-mail group from a fellow who is doing cross-compiles of Linux for
> other architectures, who is desperately trying to eliminate all the
> default rules, because they are hampering his ability to build
> simultaneously for more than one target architecture with one make
> file.

Years ago I built custom versions of FreeBSD for an embedded x86
application but needed a few special tweaks, such as everything was
linked against shared libraries to share space and CPU memory.

FreeBSD's source is structured so as one can use a host to build a
different target. Once I had created a directory tree of my desired
target I chroot'ed into it to build the accessories such as Apache and
Perl, so that these could only find the tools I intended the target to
have rather than the tools and environment I was using to build them.

Just now for kicks I launched the following on my PII-450 FreeBSD
machine: "make TARGET_ARCH=sparc64 buildworld" and it seems to be
happily building the GNU toolchain for sparc64.

--
David Kelly N4HHE, d...@HiWAAY.net
=======================================================================Whom computers would destroy, they must first drive mad.

Paul B. Webster VK2BZC wrote:
> On Tue, 2006-06-27 at 16:04 -0500, Mike McCarty wrote:
>>But the FSF has pushed so hard for making everything they do so
>>overburdened with extraneous trash, and have become so influential,
>>that I eventually gave up.
> Are you suggesting that the FSF has in fact, paradoxically fallen into
> the trap of assuming that there is no architecture other than i86?
>

No, not at all. But their tools gradually become more and more
rococo until they are nearly unusable. The introduction of "default
rules" happened in UNIX, and is not the fault of the FSF, except
in so far as they followed along.

In fact, GNU make has an option (-r) which turns off the default
rules.

But please tell me why a TEXT EDITOR needs to be larger than 4 MB?

$ ls -l /usr/bin/emacs
-rwxr-xr-x 2 root root 4408492 Feb 4 2005 /usr/bin/emacs

This is getting severely off-topic.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

On Tue, 2006-06-27 at 16:04 -0500, Mike McCarty wrote:

> But the FSF has pushed so hard for making everything they do so
> overburdened with extraneous trash, and have become so influential,
> that I eventually gave up.

Are you suggesting that the FSF has in fact, paradoxically fallen into
the trap of assuming that there is no architecture other than i86?

--
Cheers,
Paul B.

David Kelly wrote:
> On Tue, Jun 27, 2006 at 02:11:43PM -0500, Mike McCarty wrote:
>
>>David Kelly wrote:
>>
>>>Not useless, but you should know that they exist and that you have
>>>to override them.
>>
>>At first, I thought you actually meant what you wrote, and started to
>>send you an indignant response, but I suppose you mean "one should
>>know" rather than meaning to indicate that you think *I* don't know
>>that.
> Yes, my choice of words was imprecise. Didn't intend a specific person
> but the all-encompassing anonymous "one".

[snip]

Amusingly, there appeared a message just now over on the Debian
Linux e-mail group from a fellow who is doing cross-compiles of
Linux for other architectures, who is desperately trying to eliminate
all the default rules, because they are hampering his ability to
build simultaneously for more than one target architecture with one
make file.

I've always thought that having the "default rules" put into make
was a bad idea. I remember using make when those rules didn't exist,
and for a while I kept source for a make which didn't have them.
But the FSF has pushed so hard for making everything they do so
overburdened with extraneous trash, and have become so influential,
that I eventually gave up. I still do use a grep on my MSDOS machines
which is not burdened by the FSF junk.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

On Tue, Jun 27, 2006 at 02:11:43PM -0500, Mike McCarty wrote:
> David Kelly wrote:
> >
> > Not useless, but you should know that they exist and that you have
> > to override them.
>
> At first, I thought you actually meant what you wrote, and started to
> send you an indignant response, but I suppose you mean "one should
> know" rather than meaning to indicate that you think *I* don't know
> that.

Yes, my choice of words was imprecise. Didn't intend a specific person
but the all-encompassing anonymous "one".

In the case of avr-gcc I use the following:

#
#$Id: Makefile,v 1.39 2006/03/13 21:30:44 dkelly Exp $
#
CC= avr-gcc
MCU=atmega64
CFLAGS= -O -gdwarf-2 -Wall -ffreestanding -mmcu=$(MCU)

# .eeprom section start must match here and in _eeprom.hex rule:
LDFLAGS= -Wl,-Map,$@.map -Wl,--section-start=.eeprom=0x00810001 \
-Wl,--section-start=.eemeter=0x008105ef

.SUFFIXES:
.SUFFIXES: .c .o .bin .elf .hex .srec .cof .list

# the rule to convert .c's into .o's
.c.o:
$(CC) $(CFLAGS) -c $<

[...]

The first .SUFFIXES: nukes the existing default rules. The second
defines my own list. Had the first not been listed the 2nd would have
only expanded the default suffixes.

This sort of thing applies no matter what target CPU or compiler one
uses. As I said earlier I much prefer a Makefile over hidden details in
a binary config file. One reason is that CVS can efficiently deal with
changes in a Makefile for possible future merges, and that one can
understand what changed by looking at diffs.

Most all of this project's special config details are contained in the
CFLAGS and LDFLAGS lines. Only thing remaining is the list of source
files.

--
David Kelly N4HHE, d...@HiWAAY.net
=======================================================================Whom computers would destroy, they must first drive mad.

David Kelly wrote:

>>I was just trying to give him a quick intro to make. The context is
>>that of cross-compiles to MC68HC11, in which case default rules are
>>useless.
> Not useless, but you should know that they exist and that you have to
> override them. As for the originator of this thread, IMO he's in over
> his head as apparently didn't understand that the output of a C compiler
> differs depending on what target the code is to run on.

At first, I thought you actually meant what you wrote, and started
to send you an indignant response, but I suppose you mean "one should
know" rather than meaning to indicate that you think *I* don't know
that. I deliberately omitted discussion of default build rules
which modern makes have, because I thought that the response I wrote was
already beginning to edge into overburden for a newbie.

Everyone has to start somewhere. Everyone starts in over his head.
I think having some idea of what make does is better than having
none. I just drew the line a little further back than you would have.

In the meantime, I wonder where the OP is and how he's doing.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

On Mon, Jun 26, 2006 at 11:27:38AM -0500, Mike McCarty wrote:
> David Kelly wrote:
> >
> > Yes, but make goes farther than that in a properly configured system
> > make has default rules for how to convert a .c file into a .o file, and
>
> [snip]
>
> I was just trying to give him a quick intro to make. The context is
> that of cross-compiles to MC68HC11, in which case default rules are
> useless.

Not useless, but you should know that they exist and that you have to
override them. As for the originator of this thread, IMO he's in over
his head as apparently didn't understand that the output of a C compiler
differs depending on what target the code is to run on.

--
David Kelly N4HHE, d...@HiWAAY.net
=======================================================================Whom computers would destroy, they must first drive mad.

David Kelly wrote:
>
> Yes, but make goes farther than that in a properly configured system
> make has default rules for how to convert a .c file into a .o file, and

[snip]

I was just trying to give him a quick intro to make. The context is
that of cross-compiles to MC68HC11, in which case default rules are
useless.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

On Mon, Jun 26, 2006 at 08:24:30AM -0500, Mike McCarty wrote:
>
> Typical dependency rules (more jargon there) for a C program
> for Windows might be this:
>
> myprog.exe: myprog.obj mylib.obj
> cc -o myprog.exe myprog.obj mylib.obj
>
> myprog.obj: myprog.c myprog.h mylib.h
> cc -c -o myprog.obj myprog.c
>
> mylib.obj: mylib.c mylib.h
> cc -c -o mylib.o mylib.c
>
> These rules specify that myprog.exe depends on (is made from)
> myprog.obj and mylib.obj, and if either of these two files
> changes, then the program must be relinked. It further specifies
> that myprog.obj depends on myprog.c, myprog.h, and mylib.h,
> and if any of these changes, then myprog.obj must be rebuilt,
> and shows how to do that.

Yes, but make goes farther than that in a properly configured system
make has default rules for how to convert a .c file into a .o file, and
how to turn a .o file into a dot-nothing file. And without being told
explicitly will find that multi-step route if asked to convert a .c file
into a dot-nothing (or .exe in the Microsoft case).

Many don't realize for simple cases a Makefile is not necessary. Create
a hello.c file and simply type "make hello" and magic happens.

A Makefile is necessary when the output depends on multiple output
files, or when one wishes to use other than the system defaults. This is
clearly the case when using the gcc tool chain to cross-compile C for a
target other than the host computer. Or in simpler terms, when one uses
a compiler running on x86 to create code that will run on 68hc11. The
Makefile has to know *which* compiler to use and what options to give
it.

This is what I really like about WinAVR and the gcc tool chain over
Metrowerks. That the whole project configuration is contained in a
humanly readable text Makefile and not hidden/scattered in undocumented
binary project file(s) viewable only in the specific GUI application,
and only if one knows all the menus and sub menus to view.

This is also how I ran Introl C-11, from a Makefile. Under Apple's MPW.
Yes, on a Macintosh. With a command line.

--
David Kelly N4HHE, d...@HiWAAY.net
=======================================================================Whom computers would destroy, they must first drive mad.

r0807s wrote:
> I looked up WinAVR and downloaded it. it looks pretty good but i cant
> figure out how to use it. i wrote out a simple hello world program in
> the programers notebook, but now i dont know how to compile or make the
> file (i am not quite sure what making and make files are).

The "make" utility is a program developed under UNIX and now available
for just about any system you can name. It takes as input a special file
which describes how to make an object, which file is called a "make
file". The make file lists derived files, and the source files from
which they are derived. After that, it lists the commands necessary
to build the derived files. When one uses the make program, it reads
the make file, and checks whether the source files are newer than
the derived files. If so, then it performs the commands.

For example, suppose you have some text processing program which
processes some specially formatted input and produces a nicely
formatted output. Then the make file might have an entry like this:

prettyout.txt: prettyin.txt prettyrules.txt
preprocess prettyin.txt prettyrules.txt > prettytmp.txt
prettyprint prettyout.txt

If you use this make file, then it looks to see if prettyout.txt
exists. If not, or if it does exist, but it is older than
either prettyin.txt or prettyrules.txt, then it does the two
commands listed under the dependency.

Typical dependency rules (more jargon there) for a C program
for Windows might be this:

myprog.exe: myprog.obj mylib.obj
cc -o myprog.exe myprog.obj mylib.obj

myprog.obj: myprog.c myprog.h mylib.h
cc -c -o myprog.obj myprog.c

mylib.obj: mylib.c mylib.h
cc -c -o mylib.o mylib.c

These rules specify that myprog.exe depends on (is made from)
myprog.obj and mylib.obj, and if either of these two files
changes, then the program must be relinked. It further specifies
that myprog.obj depends on myprog.c, myprog.h, and mylib.h,
and if any of these changes, then myprog.obj must be rebuilt,
and shows how to do that.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!