Generating Makefile.in's for specific target platforms (os, cpu)

[BRM]

Since no one else is chatting on the subject, I
thought I would go ahead and give my thoughts -
perhaps someone can see and correct them where they
are flawed, especially since I am new to the whole
autotool chainset.

I have a project that will need to be built for
different platforms (Windows, Unix, Linux, etc.) -
which is what autotools is aimed to accomplish (so far
as my understanding). I have autotools working, but
automake isn't cooperating with where I want to go. (I
am limited to the version numbers below because MSYS
won't compile & pass certain important tests for a
newer autoconf, so I can't build a newer automake. Any
how...)

In order to learn the Autotools I have been setting up
'hello world' test projects that demonstrate various
parts of the what I will need in my larger project. At
present, I need to be able to generate Makefiles
specific to the target system - by os and cpu. Thus I
have the following layout:

.
.\os\<os string>
.\arch\<arch string>

For my test project, I have <os string> = { mingw32,
linux } and <arch string> = { i386, i686, ppc }. If
all goes well, it should compile using mingw32 on
i686.  I can get aclocal and autoheaders to run, but
then the process dies on automake when it hits the
line in my configure.ac file (for my third attempt at
this):

AC_CONFIG_FILES([Makefile os/Makefile
os/${target_os}/Makefile arch/Makefile
arch/${target_cpu}/Makefile])

(also if I replace AC_CONFIG_FILES with AC_OUTPUT). 
Automake simply doesn't like having ${target_os} or
${target_cpu} in the path, from what I can tell.
Autoconf doesn't seem to mind except that it will
complain that it can't find the Makefile.in at those
paths. So essentially, I get:

automake - complains and fails without generating the
Makefile.in files at src/arch/${target_cpu} or
src/os/${target_os}.

autoconf - complains that src/arch/i686/Makefile.in
doesn't exist or that src/os/mingw32/Makefile.in
doesn't exist. But otherwise seems okay. This should
be expected in automake didn't complete.

I have Makefile.am's in every directory, along with a
nearly identical (in my test project) source file that
needs to be compiled and linked in to the main
executable. I know I may not have everything quite
right in the Makefile.am to actually get it to build,
but I would think it should at least be making the
Makefile.in's now.

Here's my configure.ac:

AC_INIT([hello_world],[1.2],address@hidden,[hello.tar])
AC_PREREQ(2.56)
AC_COPYRIGHT([(c)2005 to see how it works])
AC_CONONICAL_SYSTEM
AM_INIT_AUTOMAKE([hello_world],[1.2])
AM_CONFIG_HEADER([config.h])
AC_PROC_CC
AC_CHECK_HEADERS([stdio.h])
AC_CONFIG_FILES([Makefile os/Makefile
os/${target_os}/Makefile arch/Makefile
arch/${target_cpu}/Makefile])
AC_OUTPUT
# To overcome a shell script bug in the generated
# Makefile where '; fi' is missing.
if [ test -f Makefile ]; then
    if [ "$target_os" = "mingw32" ]; then
        patch -p1 Makefile Makefile.patch
    fi
fi

The only difference I can tell between MSYS/MSYS DTK
and newer versions is that the MSYS DTK Automake won't
generate any warnings/errors, while Automake 1.9.5
(from Slackware 10.2) will generate the following
error:

configure.ac:9: required file
`os/${target_os}/Makefile.in` not found
configure.ac:9: required file
`os/${target_cpu}/Makefile.in` not found

Now that I think about it - even that error message is
weird since I'm running 'automake' not 'autoconf' so
it should be looking for Makefile.am not Makefile.in.

Does automake understand the AC_CANONICAL_SYSTEM or
the macros that are with it? I get a bunch of
complaints about macros out of order if I put
AC_CANONICAL_SYSTEM _after_ AM_INIT_AUTOMAKE.

Am I doing something wrong in my configure.ac? Is this
even possible with Automake? Are the directories
suppose to be 'optional'? I had thought of that, but I
must have at least one of the directories compile or
the build _will_ fail at the linker at the very least.

Any how...I am at a complete loss at how to solve this
issue. Any help is greatly appreciated.

TIA,

Ben