3 Oct
2012
3 Oct
'12
3:36 a.m.
On Wed, 3 Oct 2012, Alexey Toptygin wrote:
On Tue, 2 Oct 2012, Tothwolf wrote:
>> 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.
So, a programmer has gotten good enough at C to want
to make their code
portable. This was a lot of work. Now let's say they know how to write
portable sh scripts. That's even harder (more arcane) than learning how
to program C well, but let's argue that it has applications outside
autotools and let's assume that they put in this huge effort as well.
Now you say they need to learn M4, which is even more arcane than sh
scripting, and is not widely used anywhere but autotools and sendmail,
where (sendmail) it is the #1 thing driving people to adopt other MTAs
with other configuration systems (ones not relying on M4)? No. No no no.
M4 in this context is not a solution, it is a problem. It is the cure
that is worse than the disease.
Wow, talk about a paragraph full of fallacies.
So you don't like shell script and also dislike M4. Let me guess, you
don't believe in learning awk or sed either? Ah, I get it, you must be a
Perl coder.
Portable shell scripting isn't any more difficult than C. It is
/different/ than C, but once you learn /how/ to write portable shell
script, you never forget it. The same goes for M4. M4 itself isn't
difficult, however writing reusable, proper, autoconf macros is not a
simple task. Much like awk and sed, once you know how to use M4, you find
all sorts of uses for it.
As for sendmail, any "seasoned sysadmin" who can't build a sendmail config
file isn't a seasoned sysadmin. No, the reason people are switching to
other MTAs such as Exim is sendmail's root UID requirements and aging
codebase.
In most cases, autoconf, libtool, etc provide everything a basic build
system will need, however if you have sufficient need for a special case
test, you are probably (hopefully?) going to also spend the time to
properly implement the autoconf macro(s). If someone isn't willing to
spend the time on it to do it right, and/or if someone is too lazy to
learn autotools/autoconf to properly implement a build system using them,
then IMO they shouldn't attempt to use autoconf, etc, to begin with,
period.
I'd further argue that someone who is unable and/or *unwilling* to learn
something as basic as portable shell scripting and M4 probably isn't all
that great of C programmer to begin with. I'll even take that a step
further and state that anyone who would argue otherwise probably isn't a
veteran UNIX programmer, much less one who knows the ins and outs of
writing portable C code. [Anyone can take a C programming class and learn
some theory, but writing truly portable code is something that is learned
hands-on and not so much in the classroom.]
You got good at autotools? Good for you. I think
it's unreasonable to
require a majority of C programmers to do so. All we need is some header
files that tell us what libraries / features are on the target system,
and some make macros that tell us what tools are on the host system.
There is absolutely no reason that that should require learning 2 other
programming languages.
"All we need is some header files that tell us what libraries / features
are on the target system, and some make macros that tell us what tools are
on the host system."
Header files? Oh yeah, sure...that'll work. BSD? SysV? POSIX? C? Which C?
ANSI C? Pfft.
What do you think autoconf actually /does/? Why do you think autoconf (and
similar build tools) ever came to exist? Sure...let's just check header
files and test for a few tools...sure :)
Better still, hit the books and learn something.
http://cm.bell-labs.com/cm/cs/tpop/
http://www.amazon.com/Practice-Programming-Addison-Wesley-Professional-Comp…
http://sources.redhat.com/autobook/
http://www.amazon.com/Autoconf-Automake-Libtool-Gary-Vaughn/dp/1578701902