[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Generating's for specific target platforms (os, cpu)

From: BRM
Subject: Re: Generating's for specific target platforms (os, cpu)
Date: Mon, 19 Dec 2005 13:06:26 -0800 (PST)

I have put a snapshot of my test project at the
following URL:

Version 1:
Version 2:

Due to Yahoo's filename limitations, I had to add the
'gz' extension. Just drop off the '.gz' and decompress
with tar/bzip2 or "tar -jxf".

I corrected all the stuff to use AM_CONDITIONALs and
do checks to see if what OS or architecture is being
used. However, I am still running into problems. I
also set it up so that if I use @target_os@ it will
fail, since target_os is generally coming out to be
'linux-gnu' and my linux directory is simply named

To help I posted the bzip2'd tarballs above and
included the output of a couple runs of the script.

The "Version 1" is the run of the autotools, and it
won't compile into the subdirectories of the 'os' or
'arch'. However, if you look at their respective
Makefiles (not, you will notice that the
COMPILE_OS variable is completely ignored - commented
out. I don't know why this is - perhaps my
AM_CONDITIONAL and checks aren't working right? If I
uncomment on of the lines, then it compiles into a
sub-directory and I get other errors.

I would really like to be able to compile the object
modules in the sub-directories, and then link them in
in the top-level directory (at least for this project
- the main project will have this happen with several
programs with a top-level directory to all the
programs that won't be doing that; so this is just
representing one of the programs under it). If I add
the 'bin_PROGRAMS' as suggested earlier, then it tries
to completely compile it, but not as an object module;
so I get errors.

I don't mind using stuff like the following to add the
objects in (to a degree):

hello_world_LDADD += os/linux/os.o

However, I would rather that I could do that in the
os/linux directory where I will have a better idea (in
the long run) of what modules need to be added in. (I
guess I could build a static library that doesn't get
distributed, but I would rather not if I didn't have
to - I am planning on having a shared library at some

I know it must be something I'm doing as I am seeing
this across numerous versions. I am primarily using
AutoConf 2.59 now, but have used AutoMake 1.8.1
(msys), 1.8.5 (slackware 10.0), and 1.9.5 (slackware
10.2). Perhaps with the code above, whatever it is I'm
doing wrong can finally be spotted.

I really appreciate the help with learning the
autotools. I hope I'll be able to contribute likewise
in the future once I'm through my own learning curve.



--- Simon Richter <address@hidden> wrote:
> Hi,
> BRM wrote:
> > AC_CONFIG_FILES([Makefile os/Makefile
> > os/${target_os}/Makefile arch/Makefile
> > arch/${target_cpu}/Makefile])
> Indeed, that will not work. These are configure time
> substitutions, 
> however automake runs way before that, and there is
> no way it could know 
> all the possible values.
> What you really want to do is to generate all the
> Makefiles, even those 
> for platforms that you currently don't build, and
> use conditionals to go 
> into these directories only when you are on the
> correct platform.
> AC_CONFIG_FILES([Makefile os/Makefile
> os/linux/Makefile 
> os/mingw32/Makefile ...])
> AM_CONDITIONAL([OS_IS_LINUX], [test ${host_os} =
> "linux"])
> and in os/
> OS_SUBDIRS = linux
> endif
> automake is able to figure out what possible
> combinations for SUBDIRS 
> exist and generates an extra list of subdirectories,
> containing them 
> all, to be used when building a distribution (so
> "make dist" will run 
> through all subdirs, copying stuff into the
> distribution dir; as it only 
> copies but never compiles this will work as long as
> none of your other 
> substitutions break the Makefile syntax on other
> systems).
>     Simon

reply via email to

[Prev in Thread] Current Thread [Next in Thread]