2 Oct
2012
2 Oct
'12
4:50 p.m.
On Tue, 2 Oct 2012, Jochen Kunz wrote:
On Tue, 2 Oct 2012, Cameron Kaiser wrote:
Why would you expect a configure for that system
to cross-compile?
Because I am building an embedded device and a 8-core 2.5 GHz, 16 GB RAM
desktop computer has considerably more horse power then our 800 MHz, 256
MB RAM target? Because it is a PITA to set up the target to be a compile
host? (I am talking about $WORK here.)
I can't stand GNU autoconf / automake. But it handels this kind of stuff
pretty well, if the autoconf scripts are well written...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the key, right here. Most software developers who are really good
at C do not have enough experience with autotools.
There are a number things I learned while working with autotools that are
key to making this stuff work /right/.
1. Everything will be processed through M4, so make sure you quote and
escape stuff properly. If you don't know M4 you probably shouldn't be
writing autoconf tests. Go write sendmail configuration files for awhile.
2. Never ever assume /bin/sh is GNU Bash. Unless you are using Linux based
system, it probably isn't, and even then /bin/sh might actually be some
form of Ash.
3. Many /bin/sh Bourne shells are broken, especially with quoting, use
explicit means for testing for such things as empty strings. Use 'if test
"x$foo" != x', NOT 'if test "$foo" != ""'. The
same goes for comparing
variable that might be empty, 'if test "x$foo" == "x$bar"',
NOT 'if test
"$foo" == "$bar"'. ...also use 'test', not [].
4. Test your code on all of your target platforms. Most developers never
bother to do this. "It works on Linux, it must be right..." It is a pain
in the ass, and is the very reason I've actively hunted for older UNIX
workstations.