MESSAGE
| DATE | 2015-09-18 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [LIU Comp Sci] Fwd: Re: "Know Your Language: C Rules Everything Around Me (Part
|
From owner-learn-outgoing-at-mrbrklyn.com Fri Sep 18 11:49:18 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 7C9BC161154; Fri, 18 Sep 2015 11:49:18 -0400 (EDT)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 6D230161161; Fri, 18 Sep 2015 11:49:18 -0400 (EDT)
Delivered-To: learn-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id BDCD0161154
for ; Fri, 18 Sep 2015 11:48:53 -0400 (EDT)
Received: from [10.0.0.19] (www.mrbrklyn.com [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTPSA id 8D2C317C36
for ; Fri, 18 Sep 2015 11:48:52 -0400 (EDT)
Message-ID: <55FC3263.3030305-at-panix.com>
Date: Fri, 18 Sep 2015 11:48:51 -0400
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: learn-at-nylxs.com
Subject: [LIU Comp Sci] Fwd: Re: "Know Your Language: C Rules Everything Around Me (Part
One)"
References:
In-Reply-To:
X-Forwarded-Message-Id:
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: owner-learn-at-mrbrklyn.com
Precedence: bulk
Reply-To: learn-at-mrbrklyn.com
-------- Forwarded Message --------
Subject: Re: "Know Your Language: C Rules Everything Around Me (Part One)"
Date: Fri, 11 Sep 2015 23:58:03 +0000 (UTC)
From: Michael Forsythe
Organization: A noiseless patient Spider
Newsgroups: comp.lang.c,comp.unix.programmer
Followup-To: comp.unix.programmer
References:
<87a8svluqc.fsf-at-bsb.me.uk>
<2e35514d-e711-4a6e-a72a-93f852e2bcc5-at-googlegroups.com>
<40a9707d-5824-4502-a2a3-469c03bdf058-at-googlegroups.com>
<030adb8f-1d5a-4ab3-a66f-64ab0a131d4f-at-googlegroups.com>
<55f16897.3768328-at-news.xs4all.nl>
<9a2de3ac-eb1f-4cbc-956c-dd5f0fc71e80-at-googlegroups.com>
<78fec807-5aa4-463b-8855-d062e03c4d57-at-googlegroups.com>
Bartc wrote:
[snip]
> Sometimes a build process can be awkward
> but does it really require invoking Sed with its own pattern matching
> language, using macros, using templates, using Makefiles with /its/ own
> special language and syntax, and now everyone is using Bash as yet
> another special language, in which to /create/ those makefiles? And
> apparently even Bash scripts are now created with autoconf!
>
> It seems to have gotten a little out of hand. How complex are these
> projects of yours exactly? Maybe it's time to step back and take a long
> look at them.
>
> One thing I grudgingly admire about C is that the source modules can be
> compiled in any order. So, you compile a bunch of C modules into object
> files, and submit those object files to a linker. That's the way it
> usually works. What is it that Unix does to people's minds that makes
> them need to add all those extra layers of complexity?
[snip]
I will attempt to show, using a not-unreasonable example, that
shipping software involves far, far more than just compiling all
object files, linking them, and handing off the binary. However, I
will also attempt to show that the problems that arise can be handled
with something simpler than autotools.
Suppose I have a pile of .c and .h files sitting right here. If you
want the GTK version of the project, you'll also need to link against
GTK and set CONFIG_WITH_GTK. If you want the Athena version, you'll
need to link against Athena and set CONFIG_WITH_ATHENA. Hardly anybody
wants both.
Suppose I am the author of this code, and I now want to distribute
it. First, I decide to just compile binaries and put them up on a web
page for people to download. But then, one day, I get an email:
Hey, I downloaded your software, but it doesn't work. I think
it's because you compiled for i686, but my CPU only supports the
i586 instruction set. Could you compile a version for me? I want
GTK, but I don't care about Athena.
After about 10 emails like that, or after my list of download links
starts taking more than one screenful of my web browser, I decide to
stop. Instead, I give people a README file that says something like
If you want the GTK version, run `gcc -DCONFIG_WITH_GTK *.c -o foo
-lX11 -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0
-lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0
-lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype'.
If you want the Athena version, run `gcc -DCONFIG_WITH_ATHENA
*.c -o foo -lXaw7 -lXt -lX11'.
Then, one day, I get an email:
Hey, I downloaded your software, but it doesn't build. I think
it's becacuse I use $OBSCURE_OS and they put the headers for X11
in /opt/, which isn't in the compiler's search path, although it's
fully documented in the .pc files.
So I amend my README to add a special case for users on $OBSCURE_OS.
Well, two special cases: one for the users who want GTK, and one for
the users who want Athena.
Then, one day, I get another email:
Hey, I want Athena AND GTK. But your software takes three hours
to compile on my machine, so I really don't want to run both
commands. Can't you just make one command for both? Also, my GTK
headers aren't in /usr/include, they're all in /usr/local/include.
So I add another line to my README. Wait, make that two lines, since
I want to support users of $OBSCURE_OS as well.
Let's skip a few `one day's. I have a README file with hundreds of
commands in it, the cartesian product of options and other options and
obscure platforms and other obscure platforms. And then I upgrade my
software from using GTK2 to using GTK3. While I'm halfway through
changing those massive -l... blocks, I get an email:
Hey, I downloaded your software, but it doesn't build. I think it's
because my distribution only offers libfoobarw.so, not
libfoobar.so, and your build process doesn't take that into
account. Nobody else's software has a problem, why yours?
And before I've even started to work on that, I get another email:
ur software sucks y do i have to read liek 4000 options 2 find out
how 2 buid it evry1 else just uses ./configure && make && make
install lol.
I think it's safe to say that at this point, I have a problem with
distributing my software.
The point is: people in *nix-land have a lot of choices, and they have
an irritating habit of not getting together and universally agreeing
on one answer. Supporting those choices is a difficult task, and
cannot be accomplished by saying `Just compile all the .c files.'.
With that said, you have another point, which is that autotools is
insane. This is something I also agree with. Historical statements
aside, it is not necessary to use autotools to support `almost
everything'.
Nothing in the scenario I described above could not be handled with,
say, 50 lines of hand-written make and some use of `pkg-config`. No
sed is involved. Certainly not a script that outputs other scripts
that output other scripts. I have tarred, xz-compressed, and base64'd
a simple demo of this, which may be recovered and uncompressed by
running:
curl http://sprunge.us/TXHC | base64 -d | tar xJ
(or whatever your equivalent for those commands is). Typing `make
clean foo-gtk' with GNU make will get you the foo-gtk binary, `make
clean foo-cli foo-athena' will get you the foo-cli and foo-athena
binaries, etc. Typing `gcc -o foo -Isome -Ipaths -lfoo -lbar -lbaz
*.c' will not get you any binaries at all, for a perfectly
understandable reason which I will leave for interested parties to
discover, and which should hardly be considered a special case of
software projects.
In conclusion, a problem exists that your approach does not address
sufficiently. There are, however, ways of solving this problem that
you may not find offensive. I have presented one using GNU make.
(Followup-To'd comp.unix.programmer, as this thread has quickly lost
relevance for c.l.c.)
|
|
