Re: [patch 02/15] const-expr.patch

From: Gary V. Vaughan <git@mlists.thewrittenword.com>
Date: Mar 16, 2010, 08:23 UTC
Message-ID: <20100316082321.GA26540@thor.il.thewrittenword.com>
In-Reply-To: <4B9F33DC.3030309@viscovery.net>

On Tue, Mar 16, 2010 at 08:31:40AM +0100, Johannes Sixt wrote:

Show 10 quoted lines

> Gary V. Vaughan schrieb:
> > Unfortunately, there are still plenty of production systems with
> > vendor compilers that choke unless all compound declarations can be
> > determined statically at compile time, for example hpux10.20 (I can
> > provide a comprehensive list of our supported platforms that exhibit
> > this problem if necessary).
> 
> Yes, a comprehensive list would be appreciated. This change is an
> uglification that I personally would prefer to stay out of the code base
> unless many consumers of git are hurt.

Portable code is rarely pretty... just take a look at the output of autoconf or automake.

Of the various architectures we support, the latest vendor compilers for IRIX 6.5 and older, and for HP-UX 10.20 and older do not compile dynamic compound declarations, throwing errors such as:

cc-1028 cc: ERROR File = const-expr.c, Line = 6
  The expression used must have a constant value.

      const char *array[2] = { str, NULL };
                               ^

1 error detected in the compilation of "const-expr.c".

> The problem with this non-feature is that it is all too easy that new code
> introduces new incompatibilities.

Do you mean that new code may prevent the code from compiling on those machines again? Well, that's kinda the same problem you have when you wish to support any architecture that you don't have access to... the beauty of free software is that if it bites any significant number of people you will get bug reports, and probably patches for as long as people want to use the software on those machines.

Show 6 quoted lines

> > Index: b/ll-merge.c
> > ===================================================================
> > --- a/ll-merge.c
> > +++ b/ll-merge.c
> 
> BTW, did you notice that git is a version control system that hosts itself? ;)

I did... but we use the SCM neutral quilt package to manage our local stack of per-package patches. I'm not particularly fluent with git yet, and it took only a couple of minutes to get quilt to submit a message threaded set of patch emails to the list in a git-like format.

Does git absolutely require that you clone the entire project history to your local disk? For the thousands of ports we maintain, that would fast become a giant chunk of disk!

Show 7 quoted lines

> > +	dict[0].placeholder = "O"; dict[0].value = temp[0];
> > +	dict[1].placeholder = "A"; dict[1].value = temp[1];
> > +	dict[2].placeholder = "B"; dict[2].value = temp[2];
> > +	dict[3].placeholder = "L"; dict[3].value = temp[3];
> > +	dict[3].placeholder = NULL; dict[3].value = NULL;
> 
> 	dict[4]...

Oops.  Nice catch, thanks.

Cheers,

-- 
Gary V. Vaughan (gary@thewrittenword.com)