platform_build/tools/acp
Ying Wang 6feb6d5607 Support host multilib build
This change basically ported our target multilib to the host side.
It supports 2 host build modes: x86 and x86_64 multilib build.
For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64
multilib build. Later we'll default to x86_64 build and have a flag
to force 32-bit only build, which may be needed by SDK build.

In host module definition, like in target ones, you can use the
following
LOCAL variables to set up multilib configuration:
LOCAL_MULTILIB: can be "both", "first", "32" or "64".
It also supports the same set of arch or 32-vs-64 specific LOCAL
variables.
By default, it builds only for the first arch.

To keep path compatibility, in x86_64 build files are still output to
out/host/linux-x86; Both 32-bit and 64-bit executables are in
out/host/linux-86/bin;
In x86_64 build 32-bit shared libraries are installed to
out/host/linux-x86/lib32
and 64-bit shared libraries are installed to out/host/linux-x86/lib;
32-bit object files are output to out/host/linux-x86/obj32 and 64-bit
object files
are output to out/host/linux-x86/obj.

Bug: 13751317
Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-05-14 16:55:04 -07:00
..
Android.mk Support host multilib build 2014-05-14 16:55:04 -07:00
README auto import from //depot/cupcake/@135843 2009-03-03 19:28:42 -08:00
acp.c auto import from //depot/cupcake/@135843 2009-03-03 19:28:42 -08:00

README

README for Android "acp" Command

The "cp" command was judged and found wanting.  The issues are:

Mac OS X:
 - Uses the BSD cp, not the fancy GNU cp.  It lacks the "-u" flag, which
   only copies files if they are newer than the destination.  This can
   slow the build when copying lots of content.
 - Doesn't take the "-d" flag, which causes symlinks to be copied as
   links.  This is the default behavior, so it's not all bad, but it
   complains if you supply "-d".

MinGW/Cygwin:
 - Gets really weird when copying a file called "foo.exe", failing with
   "cp: skipping file 'foo.exe', as it was replaced while being copied".
   This only seems to happen when the source file is on an NFS/Samba
   volume.  "cp" works okay copying from local disk.

Linux:
 - On some systems it's possible to have microsecond-accurate timestamps
   on an NFS volume, and non-microsecond timestamps on a local volume.
   If you copy from NFS to local disk, your NFS files will always be
   newer, because the local disk time stamp is truncated rather than
   rounded up.  This foils the "-u" flag if you also supply the "-p" flag
   to preserve timestamps.
 - The Darwin linker insists that ranlib be current.  If you copy the
   library, the time stamp no longer matches.  Preserving the time
   stamp is essential, so simply turning the "-p" flag off doesn't work.

Futzing around these in make with GNU make functions is awkward at best.
It's easier and more reliable to write a cp command that works properly.


The "acp" command takes most of the standard flags, following the GNU
conventions.  It adds a "-e" flag, used when copying executables around.
On most systems it is ignored, but on MinGW/Cygwin it allows "cp foo bar"
to work when what is actually meant is "cp foo.exe bar.exe".  Unlike the
default Cygwin cp, "acp foo bar" will not find foo.exe unless you add
the "-e" flag, avoiding potential ambiguity.