Subject: Re: makefile(.abi) vs. autoconf/automake/libtool/etc.
From: Paul Rohr (paul@abisource.com)
Date: Fri Feb 16 2001 - 11:43:17 CST
At 08:58 AM 2/16/01 -0600, Sam TH wrote:
>What it says is that there are some platforms where that argument to
>iconv is a const char *, and some where it's just a char *. And that
>there isn't any rhyme or reason to which one is which. [1]
Yeah. One of those two equivalence classes of iconv is, by definition,
broken. My usual preference when faced with such brokenness is to pick one
of two solutions:
1. put hacks into the code to allow people to use the broken one (per
platform), or else
2. require the "proper" one on all platforms -- even if you have to build
it from source yourself.
My worry about autoconf is that its tolerance encourages the continuing
existence of such brokenness, instead of putting evolutionary pressure on
the bad variants to help make them obsolete.
>The one that you think of as "reasonable" is just the one that's
>right on my platform, which is why it's the default. But for every
>new platform, that has to be checked, and if it isn't like the
>default, another ifdef has to be used.
To be clear ... is it the default because it's your platform, or because
it's right for technical reasons? Most of the platforms explicitly
mentioned are using libiconv, and if that's really broken (for technical
reasons) -- just fix it!
We should set up those #defines to explicitly mention broken platforms by
name, along with a comment saying so. Consider it a hall of shame entry if
your platform has to be mentioned in a #define in XP code for such a reason.
Requiring broken platforms to explicitly add themselves to such an ifdef to
build is a *very* appropriate step.
>Really, you're missing out. :-) Actually, since I am trying to get
>these sorts of things working on Win32 platforms, I hope I can
>persuade one of our win32 developers to install some more
>sophisticated Unix tools. But that doesn't have to be you, Paul.
What tools do you have in mind? Large hunks of the original core code for
AbiWord were written in emacs. (Jeff got infected with that particular
virus before Windows existed, and has propogated it to every platform he's
ever supported.)
Others of us don't mind using the VC IDE for more than an excellent
debugger. :-)
>> What? You mean the rest of you don't keep the dependencies in your head?
>>
>> Silly me. Jeff and I were the ones who originally decided which headers
>> should be exposed outside of the relevant modules, which is where the
>> capital vs. lowercase prefix originated.
>
>I always wondered what that was about. :)
Sorry. I thought we wrote that down in an email or coding standards
document somewhere. It definitely belongs in Doxygen somewhere.
>Well, the proliferation of different and incompatible changes in basic
>libraries on Unix was unfortunate. But I still think you're
>short-changing the autotools. They can be used to conditionally
>compile extra libraries that you provide in case the system doesn't
>have what you need. They can be used to test what kind of XML library
>you have on your system, or whether your C++ compiler accepts the
>-Werror option.
Nope. We simply come from different paradigms. In the Unix world,
proliferation of many similar-but-slightly-incompatible tools and libraries
is seen as a Good Thing.
Like Thomas and others on the list, I tend to view these kinds of random
proliferation as a distraction. When producing a single standard product,
supporting unnecessary variation is to be avoided. Pick the best available
option and try to standardize on it for use everywhere. When needed, do just
enough porting work in the right places to make the standard stuff work.
It's a different balancing act, and not something I'm confident we'll ever
agree on totally. Fortunately, though, we don't have to agree on this any
more than we already have.
>I think that you're used to a world where there's only one toolchain
>vendor, and only one library vendor, and where the basic system never
>really differs that much. And from that perspective, autoconf doesn't
>make sense. It would be crazy of a single vendor to require that
>amount of work to compile on different system versions.
Yes, I do come from a world where people pick winners to standardize on.
Products built with that attitude have really dominated when it comes to
mass market adoption. If that's your goal, and you have a limited number of
person hours available, which would you rather have your most talented
people spend time developing, testing, and supporting?
- cool new features everyone can use
- support for lots of low-level variation that users never see
To be clear -- this *is* an Open Source project, so anyone interested in
working at any of these levels should have only one criterion:
What do I want to work on today?
One of the major strengths of well-run Open Source projects is that they
achieve much broader compatibility than any commercial project ever will.
As I've said on many occasions, it only takes one programmer somewhere on
the planet to decide to make something happen, and eventually it does.
To sum up, consider the XML library example. I personally fall very
strongly in the "pick one excellent library and use it everywhere" camp --
in this case, expat, written by XML expert James Clark. I also strongly
support Aaron's right to insist on hacking in support for another XML
library, even though I never intend to use or support it until the day we
use it to replace expat on all our platforms.
What I'm *not* interested in is doing a lot of work to make it *easy* for
anyone to start thinking of these experimental variants as anything other
than optional.
>My observation was only based on the fact that the Win32 build breaks
>more often for makefile-related reasons than other builds.
Is that just because people have gotten sloppy about updating *all* the
required platform makefiles in abi/src? Or are you referring to the
(unavoidable) difficulties of getting Unix-only libraries to start building
cleanly on other platforms?
The two are different problems, with different solutions.
>Well, these files are basically just:
>
>include $(top_srcdir)/includes.mk
>
>INCLUDES= $(AF_INCLUDES) $(WP_INCLUDES) $(TEXT_INCLUDES) \
> $(OTHER_INCLUDES)
>
>noinst_LTLIBRARIES = libWpAp_xp.la
>
>libWpAp_xp_la_SOURCES= <lots of files here>
>
>and then the cdump stuff at the end. Still significantly less
>(although less noticeable, cause of all the .cpp lines).
Actually, that sounds very very similar. There may be a few less lines, but
the incremental effort to add another source file here seems identical.
Paul
This archive was generated by hypermail 2b25 : Fri Feb 16 2001 - 15:23:24 CST