[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Remove cdrtools



On 16-Aug-06, 04:00 (CDT), Gabor Gombas <gombasg@sztaki.hu> wrote: 
> On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
> 
> > And guess what? System tests are actually more reliable, especially
> > when the user tells you what the system is. You can simply flip to
> > compiling foo_linux.c or foo_solaris.c and go on your way.
> 
> This will never work. Real life example from a couple of weeks ago: I
> wrote a program that was running happily on Sarge, then somebody wanted
> to build it on RHEL and failed because the UUID library on RHEL does not
> have uuid_unparse_lower().

So you chose to use a function not reliably available. Sounds like bad
planning to me.

> And RHEL _is_ Linux and it is pretty heavily used in corporate
> environments. So instead of foo_linux.c you need foo_sarge.c,
> foo_etch.c, foo_rhel.c, foo_opensuse.c and probably a dozen more,
> which is just plainly unmanageable.

No, you figure out what the base system requirement is, and write to that.

I can guarantee you that there's a lot more difference between AIX and
"Linux" than there is between RHEL 3.x and Debian sarge, not to even
mention non-Unix platforms. None-the-less, code can be written that runs
on all of them. You figure out where the incompatability points are, and
you write functions to mask them. Of course the functions themselves
have #ifdefs (or some other way of controlling compilation), but you get
it *out* of your main code base.

And yes, you could use autoconf to control those generic functions. But
usually it's overkill. If you actually understand enough about where the
edges of portability are, you don't need autoconf, and if you don't,
autoconf doesn't help, because you waste your time checking for things
that are universally available (memcpy(), string.h) and don't have clue
about variances in signal handling, or why assuming "char" is signed is
a bad idea.

I spend quite a bit of my life working on non-Linux platforms (as well
as a variety of Linux ones). I've built *lots* of free software on these
platforms. My experience is that the ones whose build instructions say
"edit the makefile to pick your platform and compiler" compile and work,
and when they don't, they're easy to fix. The ones that use autoconf
tend to blow up on non-Linux[1], in ways that are hard to debug and damn
near impossible to fix.

Steve

[1] Prior to the widespread adoption of Linux, this was less true;
presumably the developers actually used non-Linux systems.

-- 
Steve Greenland
    The irony is that Bill Gates claims to be making a stable operating
    system and Linus Torvalds claims to be trying to take over the
    world.       -- seen on the net



Reply to: