[Top][All Lists]

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

Re: [Tinycc-devel] Merging patches...

From: Rob Landley
Subject: Re: [Tinycc-devel] Merging patches...
Date: Sun, 8 Oct 2006 23:49:53 -0400
User-agent: KMail/1.9.1

On Sunday 08 October 2006 5:41 am, Romain Francoise wrote:
> Rob Landley <address@hidden> writes:
> > But the great thing about mercurial is _anybody_ can put up a tree,
> > and the people managing various trees can pull from each other just
> > like git.  So maybe if I collect together a bit somebody will fork off
> > a better one.
> Neat.  The Debian package carries a number of "upstream" patches, you
> might want to merge them.  See http://people.debian.org/~rfrancoise/tcc/
> or just
>  hg incoming static-http://people.debian.org/~rfrancoise/tcc/tinycc-debian

Alas, I merged two of them by hand (because I had open tabs with the patches 
in 'em) before I went back to this message and went "oh yeah, you put up a 
mercurial repository".  Lost opportunity to learn how to make a 
cherry-picking pull actually work. :(

On the other hand, the reason I'm doing it that way right now is getting my 
hands dirty helps me learn the code.  (For example, when I added the 
float->boolean typecasting fix I also added a test to tcctests.c for it.)

The other thing I'm noticing is that I would be a _horrible_ maintainer for 
this project (don't mistake what I'm doing for "maintaining" anything), 
because there are a number of things about which I _actively_ don't care.

Namely, I actively don't care about freebsd, kfreebsd, or windows, and clutter 
to support that is something I'd ideally want remove from the tree entirely, 
in the name of minimalism and simplicity.  However, I see that a lot of 
effort's gone into it, meaning other people do care, so I suppose moving it 
to a subdirectory is better.

I'm pondering how it might be possible to apply the "platform.h" technique I 
inflicted upon BusyBox in this new context; moving all that stuff to a 
ghetto.  For the moment, I'm just ignoring it.

Also pondering putting *.h in an "includes" subdirectory.  (Well, the 
installed ones, anyway.)  Of course the .h files for windows are under the 
win32 directory.  Wheee.

Would someone please explain to me why stdarg.h says the va_args macros 
are "only correct for i386", but we have an arm eabi patch pending that 
doesn't touch this file?  Which is wrong?

My brain hurts.

Never bet against the cheap plastic solution.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]