$(CC.HOSTTYPE) contains the host type as printed by
bin/package
(with no arguments)
you can do something like this to manage src lists
SRCS = srcs common to all host types
if CC.HOSTTYPE == "sol*.*"
SRCS += srcs for sol*.*
elif CC.HOSTTYPE == "linux*.*"
SRCS += srcs for linux*.*
else
error 3 $(CC.HOSTTYPE): architecture not supported
end
cmd :: $(SRCS)
if you look at the ast makefiles though the preference is to compile
all *.c and use feature-specific #ifdefs based on iffe generated macros
this way common actions like
make tgz
make list.manifest
will work on all architectures
also, the code is geared towards features rather than host types
why might this be better?
different host types might migrate towards common standards and
feature based coding may have a better chance of eliminating duplicate
coding vs. coding against host types
the one place ast makefiles do key off host type is to disable optimization for
specific files on specific architectures to work around cc implementation bugs
examples form the libast makefile:
:NOOPTIMIZE: spawnveg.c
"ibm.risc" :NOOPTIMIZE: regcomp.c
"sol*.*" :NOOPTIMIZE: sfrd.c sfvprintf.c tmxfmt.c
"win32*" :NOOPTIMIZE: fastfind.c mc.c
On Wed, 7 Jan 2009 15:17:40 -0500 Lee, Sang wrote:
> Most of our C++ applications compiled both Linux RHEL 5.2 and Solaris 8
> platforms. But some applications only need to be compiled either Linux
> or Solaris only.
> Since our source code repository is mounted both Lunix and Solaris via
> NFS and use same Nmakefile to compile both platform binaries, We are
> getting unnecessary errors.
> Please let me know if there is a flag to specify target compilation
> platform or ways to tell nmake to ether ignore or precede to build
> targets.
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers