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

[Johannes Klarenbeek]

hi rob, lol, take an asperrine ;)

 

if i'm not mistaken you do not like windows... and some other platforms. if i'm also not mistaken you like to keep things minimal and simpel. and therefore you moved win32 to a subfolder win32. however may i ask if you would do that for the linux part aswell then? so the code base of tiny cc will be an abstraction of a compiler instead of a linux compiler that builds on win32 (or for the windoze lovers a win32 compiler that runs on linux). i'm sure you will take some brain damage to fix that, but in the end it keeps it simpel and maintainable and better adaptable to other systems... btw maybe a deeper folder structure, something like:

tinycc\

   src\

   src\compiler\tinyil

   src\compiler\c99

   src\platform\win32

   src\platform\linux

   src\platform\vms

   src\platform\ms.net

   src\platform\mono.net

   src\target\tinyil

   src\target\x86-32

   src\target\x86-64

   src\target\arm

   src\target\ia64
 

will do etc.. i hope this sounds reasonable... i know that most people with a c programming background, try to keep it so simpel that they put everything in one directory. so they type less when the include something like:

 

#include "il-opcodes.h"

 

instead of typing a little bit more...

 

#include "target\tinyil\asm.h"

 

i personally have more experience in msx-z80,  java and now c# for over 3 years. what striked me most about these object oriented languages was the introduction of namespaces (or packages in java) and how simpel that was to accomplish; one can just create a folder structure and you have a simpel implementation of namespaces, this would make the huge c sources which i was working with at the time, a lot better to oversee and it did... especially when new programmers came in.

 

btw another way of doing this is by filename convention instead of folder convention

so you type something like

 

#include "target.tinyil.asm.h"

 

sorting the folder gives an instand view on, the arrangement of your code base and all files involved. and you can put the win32 files back in the root :) (so we can all have the benefit not just the linux people)

 

anyway, cheers

johannes

 

 

 

2006/10/9, Rob Landley <address@hidden>:

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.

Rob
--
Never bet against the cheap plastic solution.


_______________________________________________
Tinycc-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tinycc-devel

-- 
met vriendelijke groet,
johannes klarenbeek