On Tue, Mar 16, 2010 at 08:31:40AM +0100, Johannes Sixt wrote:
> 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.
> > 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!
> > + 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@xxxxxxxxxxxxxxxxxx)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html